Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03

From: [email-masked]
Date: Tue, 11 Nov 2003 22:34:39 -0600

Paul,

I am happy to receive some comments on the draft :)

I am just wondering about why you think that re-keying will
always break the adjacency ?

As the whole authentication process is transparent to OSPF,
the only thing that OSPF will see is some missing packets 
(hello packets in a stable situation). If the keys are changed
within say 1 minute on all the routers that are on a common
link (how many ospf routers are gonna be there on a common
link ??), the adjacency won't break. Right ?

Moreover, if a customer wants to change the keys periodically,
he/she might not choose to do it manaully everytime. And if 
they do it with some automated way, 1 minute should be more 
than enough to change keys on all the routers.

So why do you think that it will break the adjacency ??

Regards
Mukesh

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of ext
> Paul Wells
> Sent: Tuesday, November 11, 2003 1:20 PM
> To: [email-masked]
> Subject: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03
> 
> 
> A concern I have with the current version of 
> draft-ietf-ospf-ospfv3-auth is
> that it does not specify a method for rekeying an 
> authenticated OSPFv3 link
> without breaking the adjacency.  In practice, I think such a 
> mechanism will
> be needed for the following reasons:
> 
> 1. The security provided by a static key decreases with time.  The
> experience of 802.11 static WEP keys is one example of this.
> 
> 2. Our customers aren't going to like a solution that 
> requires even brief
> outages for periodic rekeying.
> 
> Non-disruptive re-keying of a link should be possible by 
> establishing an
> additional input SA with the new key.  Once all the routers 
> on a link have
> done this, the transmit SAs can be moved over.  Finally, once all the
> routers have moved to the new key, the old input SAs can be 
> removed.  The
> trick will be in reliably controlling and synchronizing this sequence.
> 
> If this is a problem that we're going to solve, I'd suggest 
> that putting it
> into the draft, at least as a "SHOULD", will make it more likely that
> implementations will interoperate.
> 
> Thanks.
> 
> - Paul Wells
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 11 Nov 2003 23:52:35 -0500

>link ??), the adjacency won't break. Right ?
I believe it is configured dead interval (which can be as small as 2
seconds using base
OSPF or 1 second using some tricks).

---

From: Paul Wells <[email-masked]>
Date: Wed, 12 Nov 2003 11:46:35 -0600

Mukesh,

You are correct that successfully rekeying all the routers on a link
within the router dead interval will preserve the adjacencies.  So, I
guess I overstated the problem by implying that the draft provides *no*
way to do this.

However, from an operational perspective, I am uncomfortable with a
scheme that puts this sort of real-time constraint on the rekeying
process.

Since we don't define a key distribution/rekeying protocol, rekeying
will be done by "out of band" configuration changes, either manually or
via some vendor or user developed automated process.  Should these not
succeed within the dead interval, the adjacency will be lost.  Further,
the loss of the adjacency may impair management access to one or more of
the routers on that link, making a second try more difficult.

Also, as Acee has pointed out, the trend among some users is to shorter
hello/dead intervals which will make the time constraint that much
harder to meet.

So, what I am suggesting is that we specify an *additional* rekeying
mechanism that works no matter how long it takes.

Regards,

- Paul