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

From: [email-masked]
Date: Wed, 12 Nov 2003 14:06:31 -0600

Paul,

I understand you point and agree with you that we should have a 
mechanism that works without depending on these real-time 
restrictions. We will try to come up with something and will post
it to the list for review soon.

If you have given it a thought and it is easier for you to come
up with the text for the draft, we would be more than happy to 
review it and add it to the draft.

I heard that Cisco has implemented the draft. I would like to hear
more about the implementation experience and would like to explore
the possibility of testing our implementation with yours.

Regards
Mukesh

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of ext
> Paul Wells
> Sent: Wednesday, November 12, 2003 11:47 AM
> To: [email-masked]
> Subject: Re: Comment on rekeying in draft-ietf-ospf-ospfv3-auth-03
> 
> 
> 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
> 
> [email-masked] wrote:
> > 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
> >>
>