Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols
Curtis Villamizar <curtis@occnc.com> Fri, 15 April 2011 20:39 UTC
Return-Path: <curtis@occnc.com>
X-Original-To: ospf@ietfc.amsl.com
Delivered-To: ospf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3234AE0682 for <ospf@ietfc.amsl.com>; Fri, 15 Apr 2011 13:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level:
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFAh8-3BktYS for <ospf@ietfc.amsl.com>; Fri, 15 Apr 2011 13:39:15 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 4F423E067F for <ospf@ietf.org>; Fri, 15 Apr 2011 13:39:15 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FKd8U9075368; Fri, 15 Apr 2011 16:39:08 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201104152039.p3FKd8U9075368@harbor.orleans.occnc.com>
To: Manav Bhatia <manav.bhatia@alcatel-lucent.com>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Thu, 14 Apr 2011 10:40:26 +0530." <4DA681C2.5070108@alcatel-lucent.com>
Date: Fri, 15 Apr 2011 16:39:08 -0400
Sender: curtis@occnc.com
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@occnc.com
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 20:39:16 -0000
In message <4DA681C2.5070108@alcatel-lucent.com> Manav Bhatia writes: > > Hi Curtis, > > > > > You might want to say "for doing *session* key rollovers". The > > persistant key rollover would need a different mechanism. > > > > I had actually meant a persistant key rollover. Why would this mechanism > not work there? > > Assume A and B are speaking to each other and A now wants to move to a > different key. All it needs to do is to generate a new Nonce that will > be fed into the KDF that B will use to generate the new traffic key. > > Also note that the keys used in this proposal will not be symmetrical. > > Cheers, Manav The common practice as I understand it is to maintain at least two keys, one is used to build authentication headers and one or either of the two can be used to check authentication headers. During a cutover, there is an interim period during which one end is more up to date than the other. First the second key is added as an alternate key to check authentication headers. Then when the provider (or software) has verified that this key is available where it needs to be, the new key is used to build authentication headers. Finally the old key is disabled and the process can be repeated later. The same applies to assymmetrical key pairs. The new public key needs to be on the recieve side before the sender starts using the new private key (assuming that sort of key pair). There should be no requirement for the persistant key to be symmetrical and it is perfectly valid to have different shared session keys for each direction, though perhaps there is very if any little benefit. The session keys would be unique to a pair of routers, would be transient in nature, and there is no need for the NOC (network operation center) to know what session keys are in use at any given time. Only the persistant keys would be maintained by the NOC and held in non-volitile memory so as to remain persistant over reboots. Curtis
- [OSPF] FW: Using dynamically derived Traffic Keys… Bhatia, Manav (Manav)
- Re: [OSPF] FW: Using dynamically derived Traffic … Curtis Villamizar
- Re: [OSPF] FW: Using dynamically derived Traffic … Manav Bhatia
- Re: [OSPF] FW: Using dynamically derived Traffic … Curtis Villamizar
- Re: [OSPF] FW: Using dynamically derived Traffic … Manav Bhatia
- Re: [OSPF] FW: Using dynamically derived Traffic … Curtis Villamizar
- Re: [OSPF] FW: Using dynamically derived Traffic … Bhatia, Manav (Manav)