Subject: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 May 2013 21:13:54 +0100

All,

I am attaching Danny's routing directorate review of your draft. Please read his note below.

As IETF last call has completed, you do not need to heed these comments in the same way as you might for comments coming during IETF last call.

However, the ADs will be sifting through what Danny has written and potentially adding issues he raises to our Discusses/Comments. In view of that, you may feel it wise to read what he has written and see whether you are moved to answer his questions and maybe update the text.

Thanks,
Adrian

> -----Original Message-----
> From: Danny McPherson [mailto:[email-masked]]
> Sent: 12 May 2013 20:57
> To: BRUNGARD, DEBORAH A
> Cc: [email-masked]; [email-masked]; Dan Li
> ([email-masked])
> Subject: Re: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table
> 
> Review attached, apologies for the latency.  Also, I'm sending this
> without a full review of the review so if anything seems abrasive it
> wasn't meant to be..
> 
> Thanks,
> 
> -danny

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 08:27:51 -0400

Danny, it sounds like you care a lot more about the time sync issue than
people who have discussed in in the WG. Would you be willing to write
some text discussing NTP and providing a way forward on your concern
here?

I will need to discuss several issues you raise with the WG.
In addition, I'll want to address many of the specific comments you
raise.

However there are a couple points raised that I can respond to now.  So
I'll do that and get that discussion started.

With regard to the generic comments.
i don't believe expanding the scope to cover SIDR, or public-keys would
be within the scope of KARP or of the tharter item leading to this
document.  I think it would be a fairly bad idea.

I think the WG has consensus on the current scope and so I believe item
1 would not be appropriate here.

Similarly, I think expanding the scope as suggested by 6 after IETF last
call is inappropriate.

With regard ti item 7: yes most routing protocols use small integers to
identify keys over the wire.
The only protocols contemplated that use names come from outside the
IETF; you'll need to talk to Russ and Tim about how that works.

However, the administrative key name--the name that the operator
uses--is not restricted and can be whatever the operator likes.

---

From: Danny McPherson <[email-masked]>
Date: Tue, 21 May 2013 09:37:19 -0600

> some text discussing NTP and providing a way forward on your concern

The reason I care a lot more is that there's less point in investing in 
deployment of these capabilities if we're going to be overly loose on 
timing issues, expiry, etc.  I think if I wrote text it would simply 
state that there needs to be reasonable synchronization and that 
implementations should not assume some considerable skew (e.g., greater 
than a few minutes).  It's arguably not as bad for p2p sessions but for 
system wide functions (e.g., LSA, LSP, etc..) it could be more 
problematic in practice.  Highlighting and not marginalizing these 
dependencies is key.  IF you want me to write something up I can, but 
it's simply could to be a lot more prescriptive than what's there today, 
with an exclamation point in the deployment considerations section.

> In addition, I'll want to address many of the specific comments you

Understood.

> document.  I think it would be a fairly bad idea.

As an operator I now have multiple mechanisms to manage that are 
completely different architectures and terminology, etc.  If we want 
folks to use this there needs to be incentives, more complexity upon 
completion is not an incentive.  Can you explain why it's a bad idea?

> Similarly, I think expanding the scope as suggested by 6 after IETF 

Duly noted, however, my concern remains.

> IETF; you'll need to talk to Russ and Tim about how that works.

Do you have a reference or pointer to support this?  And the point 
about names was in my router/switch configurations today - that's how 
they're referenced (your "admin key name" point below).  Not binding to 
this in some manner means it's going to have to be done outside of the 
specification - or am I missing something?

> uses--is not restricted and can be whatever the operator likes.

Right, and that needs to be tied to DB in some manner, no?  Or do you 
see that as purely an implementation issue?  E.g., if an operator wanted 
to dump the db to debug something, they'd need to tie it back to the 
admin names, no?

Thanks Sam,

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 21 May 2013 09:47:16 -0600

On 2013-05-21 09:39, Sam Hartman wrote:
> OK. Then let's take a step back.
> why is having large skew bad?
> The working group has been assuming hours or days of permitted skew 
> is
> OK.
>
> what are we missing?

If we're going to support automated rollover, for example, then systems 
need to know when to begin/stop using a key to either sign with or for 
validation.  If they're out of synch this can cause validation failure 
(e.g., I'm signing with something that you think is expired or hasn't 
become valid yet) and perhaps impact message validation 
non-deterministically across the network.  The only way they know what a 
remote system is going to validate based upon is the assumption they 
have the right key(s) that are valid within that timeframe.

-danny

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 11:39:26 -0400

OK. Then let's take a step back.
why is having large skew bad?
The working group has been assuming hours or days of permitted skew is
OK.

what are we missing?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 11:46:22 -0400

Hi.
I think I better understand our confusion regarding key names.

The draft is wrong:-)

There's supposed to be an administrative key name field that is how the
operator refers to the key.  The local and peer key names are used to
construct the wire formats.  As an example the base OSPF spec has an
integer format for that wire key name.

however, the conceptual database in the draft seems to be missing the
administrative key name.  You're completely right that without that,
operators are going to have significant trouble.

I'm not sure how that fell through the cracks, but I'll confirm with the
WG and fix.  Thanks for the catch!

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 May 2013 16:05:30 +0000

Hi Danny, 

On May 21, 2013, at 11:47 AM, Danny McPherson wrote:

> If we're going to support automated rollover, for example, then systems need to know when to begin/stop using a key to either sign with or for validation.  If they're out of synch this can cause validation failure (e.g., I'm signing with something that you think is expired or hasn't become valid yet) and perhaps impact message validation non-deterministically across the network.  The only way they know what a remote system is going to validate based upon is the assumption they have the right key(s) that are valid within that timeframe.

For rollover to be successful, an implementation needs to send or sign with the most recent key (e.g. latest SendLifetimeStart) and accept all current keys (i.e., the current time falls between AcceptLifetimeStart and AcceptLifetimeEnd). This is what I recommend today with my implementation of OSPF authentication and key-chains. 

Although I've never been in the acknowledgements section, I've reviewed this document several times and am responsible for getting the terminology aligned with industry standard key-chains. 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 May 2013 16:14:29 +0000

Sam, 
I think is very confusing to have a LocalKeyName, PeerKeyName, and AdminKeyName. Hell, LocalKeyName and PeerKeyName are already confusing. Could we replace the key used for wire formats with a single SecurityAssociationID? If there is any justice in the universe, the local system and peer system will agree. 
Thanks,
Acee

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 May 2013 16:39:42 +0000

Is it not given that NTP will always be running in any decent sized deployment to sync the clocks? How else would admins make sense of the logs/traps coming from different routers if the time stamps are not synced? Given this, why would the clock for accepting keys ever drift beyond a few secs/mins?

Cheers, Manav

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Danny McPherson
> Sent: Tuesday, May 21, 2013 9:07 PM
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review 
> for draft-ietf-karp-crypto-key-table
> 
> > Danny, it sounds like you care a lot more about the time sync issue 
> > than people who have discussed in in the WG. Would you be 
> willing to 
> > write some text discussing NTP and providing a way forward on your 
> > concern here?
> 
> The reason I care a lot more is that there's less point in 
> investing in deployment of these capabilities if we're going 
> to be overly loose on timing issues, expiry, etc.  I think if 
> I wrote text it would simply state that there needs to be 
> reasonable synchronization and that implementations should 
> not assume some considerable skew (e.g., greater than a few 
> minutes).  It's arguably not as bad for p2p sessions but for 
> system wide functions (e.g., LSA, LSP, etc..) it could be 
> more problematic in practice.  Highlighting and not 
> marginalizing these dependencies is key.  IF you want me to 
> write something up I can, but it's simply could to be a lot 
> more prescriptive than what's there today, with an 
> exclamation point in the deployment considerations section.
> 
> > However there are a couple points raised that I can respond 
> to now.  
> > So
> > i don't believe expanding the scope to cover SIDR, or public-keys 
> > would be within the scope of KARP or of the tharter item leading to 
> > this document.  I think it would be a fairly bad idea.
> 
> As an operator I now have multiple mechanisms to manage that 
> are completely different architectures and terminology, etc.  
> If we want folks to use this there needs to be incentives, 
> more complexity upon completion is not an incentive.  Can you 
> explain why it's a bad idea?
> 
> > Similarly, I think expanding the scope as suggested by 6 after IETF 
> > last call is inappropriate.
> 
> > With regard ti item 7: yes most routing protocols use small 
> integers 
> > to identify keys over the wire.
> Do you have a reference or pointer to support this?  And the 
> point about names was in my router/switch configurations 
> today - that's how they're referenced (your "admin key name" 
> point below).  Not binding to this in some manner means it's 
> going to have to be done outside of the specification - or am 
> I missing something?
> 
> Right, and that needs to be tied to DB in some manner, no?  
> Or do you see that as purely an implementation issue?  E.g., 
> if an operator wanted to dump the db to debug something, 
> they'd need to tie it back to the admin names, no?
> 
> Thanks Sam,
> 
> -danny
> 
>

---

From: Danny McPherson <[email-masked]>
Date: Tue, 21 May 2013 11:25:53 -0600

On 2013-05-21 10:05, Acee Lindem wrote:

> For rollover to be successful, an implementation needs to send or
> sign with the most recent key (e.g. latest SendLifetimeStart) and
> accept all current keys (i.e., the current time falls between
> AcceptLifetimeStart and AcceptLifetimeEnd). This is what I recommend
> today with my implementation of OSPF authentication and key-chains.

So this is precisely my point.  If you and I have a different idea of 
when AcceptLifetimeEnd is and it's so different that you're signing 
messages with a key that I believe has exceeded AcceptLifetimeEnd then 
that's a problem.  If we're going to use time-based expiry then they 
ought to be reasonable precise in today's networks.

> Although I've never been in the acknowledgements section, I've
> reviewed this document several times and am responsible for getting
> the terminology aligned with industry standard key-chains.

Ack! (no pun there :-)

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 21 May 2013 11:27:30 -0600

On 2013-05-21 10:39, Bhatia, Manav (Manav) wrote:
> Is it not given that NTP will always be running in any decent sized
> deployment to sync the clocks? How else would admins make sense of 
> the
> logs/traps coming from different routers if the time stamps are not
> synced? Given this, why would the clock for accepting keys ever drift
> beyond a few secs/mins?

Indeed my point...

-danny

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 May 2013 17:32:23 +0000

In that case associating a life time with the keys should work as long as the protocols provide a reasonable window for the key transition.

Will it help if text is added which basically says that NTP or some timing protocol should be running that keeps all clocks pretty much synchronized so that all routers have a consistent view of the time.

Cheers, Manav

> Sent: Tuesday, May 21, 2013 10:58 PM
> To: Bhatia, Manav (Manav)
> Cc: Sam Hartman; [email-masked]; [email-masked]; 
> Subject: RE: [RTG-DIR] FW: Routing Area Directorate Review 
> > deployment to sync the clocks? How else would admins make 
> sense of the

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 May 2013 17:43:37 +0000

In my examples, I normally use a 30 day transition period. 
Thanks,
Acee

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 May 2013 18:21:36 +0000

I also expect the transition period to be shorter. 30 days seems like eternity ..

In any decent sized network the routers are synced using NTP. Given this, why does the transition period need to be this large?

Cheers, Manav

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Tuesday, May 21, 2013 11:38 PM
> To: Acee Lindem
> Cc: Bhatia, Manav (Manav); Danny McPherson; 
> [email-masked]; 
> [email-masked]; [email-masked]
> >>>>> "Acee" == Acee Lindem <[email-masked]> writes:
> 
>     Acee> In my examples, I normally use a 30 day transition period.
>     Acee> Thanks, Acee
> 
> 
> Accee, my point exactly.  Danny has asserted a couple of 
> times that the transition period should be short, but I don't 
> understand why that's true.
> 
> --Sam
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 May 2013 18:33:25 +0000

I'm not forcing any period. I'm just making the point that there is no sense to try and synchronize all your keys between 12:00 AM and 12:01 AM on January 1st. You should use an interval that satisfies your network administration model for the domain to which the key is scoped. Given that there is a major concern that network providers do not change keys periodically, a liberal transition window is preferable to not changing the keys at all. 
Thanks,
Acee

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 May 2013 14:51:18 -0400

I see no reason not to add a key name that is intended fro human recognition.

Suggestion:

      AdminKeyName
         The AdminKeyName field contains a string identifying the key
         by humans.  The same string can be used on the local system
         and peer systems, but this is not required.  Protocols do not
         make use of this string; protocols use the LocalKeyName and
         the PeerKeyName.

Russ

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 May 2013 18:51:38 +0000

> It doesn't.
> Why does it need to be short?
> 

Once instance of when you might want to change the key is when the person who had access to the keys leaves the organization (based on what we heard from the operators in KARP when doing karp design guide). By giving a transition period of 30 days, you leave your network vulnerable for that long.

You change the key on all routers using your favorite provisioning tool. Now since all routers are in sync, you can actually give a transition period in O(hours) or the amount of time that it takes you to reconfigure all your routers in your network. Once that's over, all your routers have moved over to the new Key.

BTW, discussing the length of the transition period in the context of this draft looks like a daft digression! :)

I think it would be useful to add some text about assuming that the clocks on all routers will be pretty much in sync - specifically since you are recommending key life times in the draft. 

Cheers, Manav

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 May 2013 14:56:19 -0400

Acee:

If the parties can agree to use the same identifier, that is fine, they can populate the field with the same value.

However, the complexity really is needed.  If I tell you that I'm going to call the key 48, and you already have a key with that identifier, then one of us needs to rearrange things or we have to find an identifier without a collision.  Since some of the routing protocols have a 16-bit identifier, this seems like a significant coordination activity.

Russ

---

From: Danny McPherson <[email-masked]>
Date: Tue, 21 May 2013 13:44:02 -0600

> Why does it need to be short?

I agree with Manav's example (we're doing some of this ourselves 
currently).

Say for example we have a critical server that distributes an important 
file and needs availability of t per an SLA unless in a change 
management/maintenance window.  Assume that server is reachable because 
LSPs are validated and processed.  I don't want that key to rollover at 
some period in a 30 day window that I don't have staff on hand to deal 
with any issues that may result.  The same applies for BGP where I may 
want to have a peer for a critical transit link to have their operations 
folks on the phone during key rollovers so that if problems occur we can 
address them - say I have 10 or 20 or 50 of these to do in one night.

If we were going to use such a capability we need it to be precise.

-danny

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 14:08:01 -0400

Accee, my point exactly.  Danny has asserted a couple of times that the
transition period should be short, but I don't understand why that's
true.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 14:23:30 -0400

>>>>> "Bhatia," == Bhatia, Manav (Manav) <[email-masked]> writes:

    Bhatia,> I also expect the transition period to be shorter. 30 days
    Bhatia,> seems like eternity ..  In any decent sized network the
    Bhatia,> routers are synced using NTP. Given this, why does the
    Bhatia,> transition period need to be this large?

It doesn't.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 14:47:19 -0400

>>>>> "Acee" == Acee Lindem <[email-masked]> writes:

    Acee> Sam, I think is very confusing to have a LocalKeyName,
    Acee> PeerKeyName, and AdminKeyName. Hell, LocalKeyName and
    Acee> PeerKeyName are already confusing. Could we replace the key
    Acee> used for wire formats with a single SecurityAssociationID? If
    Acee> there is any justice in the universe, the local system and
    Acee> peer system will agree.  Thanks, Acee

As an individual I don't support this change.

here are some reasons;

1) we want the key table to be able to represent all the things that the
protocols can represent.

2) Coordinating things like this between organizations ends up being
tricky.  Since there's no technical requirement to require such
coordination I'd prefer not to add one here.

as a matter of process, I think proposing this change after IETF last
call has concluded is too late.
The reason i think introducing the admin  key name may still be
appropriate is that we had told the WG at multiple points we would do
that and I believe the WG had consensus to do so.
obviously, determining that is up to the KARP chairs.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 May 2013 20:58:32 -0400

Let me try to rephrase the discussion of time, and make a point about 
context.  In reverse order.

In terms of context, this document defines the time windows.  As this 
corresponds to current practice, it would be very strange not to have 
the fields needed to support the current practice.
And this document is NOT the deployment guide.  This document can not 
require or expect NTP.  that is not its job.

Now, in terms of behavior, when you want to change keys, there are many 
approaches.  But an obvious approach that copes with the problems is:
1) Select time T1 that you expect to have the keys configured
2) Select times t2 and t3 for the systems to start using the new key. 
Make it enough later than t1 that clock skew is a non-issue.  Pick a 
time that suits your maintenance practices
3) Select a time t4, enough after t2 and t3 that clock skew is a non 
issue, to stop accepting oldkey.
4) Now configure to start accepting newkey at T1, start generating 
newkey on each system at t2 and T3, and to stop accepting oldkey at T4.

If you pick times that match your operational practices and comfort, you 
have a nice safe transition.  If those times ar 1 minute appart because 
you have NTP and trust it, 5 minutes apart because you are confident of 
behavior, or days apart because that is the way you work is entirely 
your business.
And again, none of that belongs in this document.

Yours,
Joel

PS: SIDR (origin or path) is out of scope for the working group.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 24 May 2013 21:14:53 +0000

Hi Russ,
Sorry for the delayed response - I had a high priority day job preemption.
I must say that I disagree with you here. Once you add the AdminKeyName to
the crypto table, that is the  unique identifier for table entries and
there is not reason to worry about conflicts for other fields. Also, if
you are using the same key, there is no reason not to use the same
Security Association ID (SA ID). If the keys are asymmetric, then they are
separate keys and SA IDs. I'd be interested in Danny's and other routing
directorate member's view on this.
Thanks,
Acee 

On 5/21/13 11:56 AM, "Russ Housley" <[email-masked]> wrote:

>Acee:
>
>If the parties can agree to use the same identifier, that is fine, they
>can populate the field with the same value.
>
>However, the complexity really is needed.  If I tell you that I'm going
>to call the key 48, and you already have a key with that identifier, then
>one of us needs to rearrange things or we have to find an identifier
>without a collision.  Since some of the routing protocols have a 16-bit
>identifier, this seems like a significant coordination activity.
>
>Russ
>
>
>
>> I think is very confusing to have a LocalKeyName, PeerKeyName, and
>>AdminKeyName. Hell, LocalKeyName and PeerKeyName are already confusing.
>>Could we replace the key used for wire formats with a single
>>SecurityAssociationID? If there is any justice in the universe, the
>>local system and peer system will agree.
>> Thanks,
>> Acee 
>>