Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt)

Mukesh.Gupta@NOKIA.COM Fri, 05 December 2003 23:26 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03028 for <ospf-archive@LISTS.IETF.ORG>; Fri, 5 Dec 2003 18:26:14 -0500 (EST)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C682DF@cherry.ease.lsoft.com>; Fri, 5 Dec 2003 18:26:28 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63226239 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Dec 2003 18:26:29 -0500
Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Dec 2003 18:26:29 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB5NQP119823 for <OSPF@peach.ease.lsoft.com>; Sat, 6 Dec 2003 01:26:25 +0200 (EET)
Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T66558d425bac158f23111@esvir03nok.nokia.com> for <OSPF@peach.ease.lsoft.com>; Sat, 6 Dec 2003 01:26:25 +0200
Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 15:26:22 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt)
Thread-Index: AcO7hlx1uXUmWzPoQOy9PWAmRphmogAAKivg
X-OriginalArrivalTime: 05 Dec 2003 23:26:22.0339 (UTC) FILETIME=[3195DD30:01C3BB87]
Message-ID: <8D260779A766FB4A9C1739A476F84FA401546FF9@daebe009.americas.nokia.com>
Date: Fri, 05 Dec 2003 17:26:22 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukesh.Gupta@NOKIA.COM
Subject: Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt)
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Sounds reasonable Acee. I will use "One way to control.."
when I add the text to the draft.

> -----Original Message-----
> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext
> Acee Lindem
> Sent: Friday, December 05, 2003 3:20 PM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: Re: Changing keys in OSPFv3
> (draft-ietf-ospf-ospfv3-auth-03.txt)
> 
> 
> Hi Mukesh,
> 
> I like it except it almost implies that KeyRollloverInterval is a
> protocol constant. Maybe
> it just because I implement the concept of key lifetime (similar to
> another vendor). Perhaps
> you could replace the statement "To control the progression from one
> step to the next" with
> "One way to control the progression  from on step to the next is for
> each router on the link
> to have...".
> 
> All,
> 
> We are ready to last call this document. Please take a look at it. We
> recently changed
> the source address selection algorithm for virtual links.
> 
> 
> Thanks,
> Acee
> 
> Mukesh.Gupta@NOKIA.COM wrote:
> 
> >Group,
> >
> >As we had decided to add a section on changing OSPFv3 keys without
> >breaking adjacencies, here is the text Me, Paul and Suresh came up
> >with.
> >
> >Comments are welcome. I will wait for the comments till Monday and
> >then I will add this in the draft.
> >
> >Regards
> >Mukesh
> >
> >===================================================================
> >X. Changing Keys
> >
> >To maintain the security of a link, it may be desirable to change the
> >key values from time to time.  The following three step procedure MAY
> >be provided to rekey the routers on a link without dropping OSPFv3
> >protocol packets or disrupting the adjacency.
> >
> >1. For every router on the link, create an additional input SA for
> >the interface being rekeyed using a new SPI and the new key.
> >
> >2. For every router on the link, replace the original output 
> SA with one
> >using the the new SPI and key values.  The SA replacement operation
> >should be atomic with respect to sending OSPFv3 packets on 
> the link so
> >that no OSPFv3 packets are sent without authentication/encryption.
> >
> >3. For every router on the link, remove the original input SA.
> >
> >Note that all the routers on the link must complete step 1 before any
> >begin step 2.  Likewise, all the routers on the link must 
> complete step
> >2 before any begin step 3.
> >
> >To control the progression from one step to the next, each 
> router has a
> >configurable time constant KeyRolloverInterval.  After the 
> router begins
> >step 1 on a given link, it waits for this interval and then moves to
> >step 2.  Likewise, after moving to step 2, it waits for this interval
> >and then moves to step 3.
> >
> >In order to achieve smooth key transition, all the routers on a link
> >should use the same value for KeyRolloverInterval, and 
> should initiate
> >the key rollover process within this time period.
> >
> >At the end of this procedure, all the routers will have a 
> single input
> >and output SA for OSPFv3 on the link with the new SPI and key values.
> >=====================================================================
> >
> >
> >
>