Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt)
Acee Lindem <acee@REDBACK.COM> Fri, 05 December 2003 23:20 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 SAA02845 for <ospf-archive@LISTS.IETF.ORG>; Fri, 5 Dec 2003 18:20:07 -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 <14.00C68157@cherry.ease.lsoft.com>; Fri, 5 Dec 2003 18:20:18 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 63226035 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Dec 2003 18:20:19 -0500
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Dec 2003 18:20:19 -0500
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D5EE5740071 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 5 Dec 2003 15:20:15 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12045-03 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 5 Dec 2003 15:20:15 -0800 (PST)
Received: from redback.com (unknown [155.53.6.32]) by prattle.redback.com (Postfix) with ESMTP id 2A4A574006E for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 5 Dec 2003 15:20:15 -0800 (PST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <8D260779A766FB4A9C1739A476F84FA401546FF1@daebe009.americas.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at redback.com
Message-ID: <3FD1129A.2090604@redback.com>
Date: Fri, 05 Dec 2003 18:19:54 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Changing keys in OSPFv3 (draft-ietf-ospf-ospfv3-auth-03.txt)
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401546FF1@daebe009.americas.nokia.com>
Precedence: list
Content-Transfer-Encoding: 7bit
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