Subject: Re: [karp] Please take a look at draft-hartman-karp-ospf-analysis

From: "Michael Barnes" <[email-masked]>
Date: Fri, 18 Jun 2010 18:19:21 -0700

> By intra connection rekeying I had meant changing the authentication keys
once all the sessions are up, without bouncing the adjacencies. OSPF uses the
KeyID that it receives in the protocol packets for authentication. If it does
not find that Key ID or if that Key ID does not yield the right result then it
will drop the protocol packets. So, for rekeying the admin needs to do the
following within the RouterDeadInterval:
> 
> o Move to new Key ID that maps to a different security parameters.
> 
> OR
> 
> o Associate a different key/security parameters with the existing Key ID
> 
> However, this has to be done before the RouterDeadInterval on *all* links as
otherwise OSPF will flap. This becomes extremely complicated and onerous with
routers having lower RouterDeadIntervals.
> 
> One workaround and a possible input to the design team could be to have a
set of acceptable Key IDs that OSPF on the receiving side could use in case
the Key ID in the incoming packet isn't the active one.

FYI some implementations currently do provide a key-rollover mechanism that
allows a new key to be configured while the old key is still in use. Only
after all routers are configured with the new key will they start sending the
new key. During the rollover time the routers will accept either old or new
key. So there is no concern about making the change during a dead-interval.

Regards,
Michael

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 19 Jun 2010 08:55:48 +0530

Most implementations have also found a workaround for the packet prioritization problem that I had mentioned in my earlier post! :) I understand that there are lot of things that implementations do, and its precisely this that differentiates one from the other. However, I would still like us to come out with a clean (read standard) way to get around this problem.
 
> new key. During the rollover time the routers will accept 

How will the routers know that all the routers have been configured with a new key? 

I think what implementations at the receiving end do is to check for all Keys in the Key Chain and accept the packet if the incoming hash matches with the hash generated by any of the keys configured.

Cheers, Manav

> either old or new

---

From: Minto Jeyananth <[email-masked]>
Date: Mon, 21 Jun 2010 23:36:20 -0700

Manav, 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of
|Bhatia, Manav (Manav)
|Subject: Re: [karp] Please take a look at draft-hartman-karp-ospf-analysis
|
|Most implementations have also found a workaround for the packet
|prioritization problem that I had mentioned in my earlier post! :) I
|understand that there are lot of things that implementations do, and its
|precisely this that differentiates one from the other. However, I would
|still like us to come out with a clean (read standard) way to get around
|this problem.
|
|>
|> FYI some implementations currently do provide a key-rollover
|> mechanism that
|> allows a new key to be configured while the old key is still
|> in use. Only
|> after all routers are configured with the new key will they
|> start sending the
|> new key. During the rollover time the routers will accept
|
|How will the routers know that all the routers have been configured with a
|new key?
|
|I think what implementations at the receiving end do is to check for all
|Keys in the Key Chain and accept the packet if the incoming hash matches
|with the hash generated by any of the keys configured.
|

 RFC 2328 section D.4.3 defines which key OSPF should use when send packet out. In other words in OSPF it's already specified in standard way. And OSPF has key-id in packets implementation only check key-id not all the configured keys in the keychain. 

-minto  

|Cheers, Manav
|
|> either old or new
|> key. So there is no concern about making the change during a
|> dead-interval.
|>
|> Regards,
|> Michael
|>
|>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Jun 2010 12:12:49 +0530

Minto,
 
>  RFC 2328 section D.4.3 defines which key OSPF should use 
> when send packet out. In other words in OSPF it's already 
> specified in standard way. And OSPF has key-id in packets 
> implementation only check key-id not all the configured keys 
> in the keychain. 

I don't see how this precludes an implementation from implementing a scheme wherein an incoming OSPF packet is checked against all the keys present in the key-chain. Vendors are free to do things that are not specified in the RFC as long as it does not cause an inter-op issue.

Cheers, Manav

---

From: Minto Jeyananth <[email-masked]>
Date: Mon, 21 Jun 2010 23:54:47 -0700

Manav, 

 Hmmm... Why does an implementation need to validate against all keys it when key-id is present in packets? Scan through all keys are only required if packet does not contain the key-id.

-minto 

|-----Original Message-----
|From: Bhatia, Manav (Manav) [mailto:[email-masked]]
|Sent: Monday, June 21, 2010 11:43 PM
|To: Minto Jeyananth
|Cc: [email-masked]
|Subject: RE: [karp] Please take a look at draft-hartman-karp-ospf-analysis
|
|Minto,
|
|>  RFC 2328 section D.4.3 defines which key OSPF should use
|> when send packet out. In other words in OSPF it's already
|> specified in standard way. And OSPF has key-id in packets
|> implementation only check key-id not all the configured keys
|> in the keychain.
|
|I don't see how this precludes an implementation from implementing a scheme
|wherein an incoming OSPF packet is checked against all the keys present in
|the key-chain. Vendors are free to do things that are not specified in the
|RFC as long as it does not cause an inter-op issue.
|
|Cheers, Manav
|
|

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Jun 2010 13:00:41 +0530

Minto,

You might want to look at Michael's email dated 6/19 to see how this discussion started. 

Cheers, Manav 

> -----Original Message-----
> From: Minto Jeyananth [mailto:[email-masked]] 
> Sent: Tuesday, June 22, 2010 12.25 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: RE: [karp] Please take a look at 
> draft-hartman-karp-ospf-analysis
> 
> Manav, 
> 
>  Hmmm... Why does an implementation need to validate against 
> all keys it when key-id is present in packets? Scan through 
> all keys are only required if packet does not contain the key-id.
>  
>   
> -minto 
>   
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Jun 2010 13:11:21 +0530

BTW you might also want to look at RFC 5709 on the additional parameters (specifically the ones related to what keys need to be used) that have been defined for an OSPF security association.

As I mentioned earlier, its an implementation specific issue.

Cheers, Manav