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. > >===================================================================== > > > > > > >
- Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-a… Mukesh.Gupta
- Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospf… Acee Lindem
- Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospf… Mukesh.Gupta