Re: [OSPF] Automated group keying for OSPFv3

Curtis Villamizar <> Fri, 20 October 2006 16:56 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GaxfL-000591-Jt; Fri, 20 Oct 2006 12:56:15 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GaxfK-00058w-U8 for; Fri, 20 Oct 2006 12:56:14 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GaxfJ-0001rY-Je for; Fri, 20 Oct 2006 12:56:14 -0400
Received: from (localhost []) by (8.13.4/8.13.4) with ESMTP id k9KGth71001457; Fri, 20 Oct 2006 12:55:44 -0400 (EDT) (envelope-from
Message-Id: <>
To: Liu Ya <>
Subject: Re: [OSPF] Automated group keying for OSPFv3
In-reply-to: Your message of "Fri, 20 Oct 2006 15:17:29 +0800." <00a401c6f417$cdd373d0$>
Date: Fri, 20 Oct 2006 12:55:43 -0400
From: Curtis Villamizar <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

In message <00a401c6f417$cdd373d0$>
Liu Ya writes:
> Hi all,
> RFC4552 provides authentication/confidentiality to OSPFv3 using
> AH/ESP. Manual keying is recommended as default keying method. That
> method is not scalable. Script configuration tools can improve that
> problem. However, they must be used together with additional secure
> mechanisms (e.g. IPsec encryption tunnels) to prevent from passing
> plaintext keys from configuration server to devices. Furthermore,
> manual intervention can not be completely avoided in such cases as
> router crashing and rebooting, route flapping, etc. 
> Therefore, an automated, scalable and secure group keying method is
> necessary for OSPFv3. Standard group key management protocols have
> been defined by MSEC WG. They can be used here to serve the group
> keying purpose. 
> Comments are welcome.
> Regards,
> Liu Ya

The typical provider solution is to automate the distribution of keys
but use a secure means of accessing either a CLI interface or other
interface provided by the router.

In practice, this is a very small problem and it is a solved problem.
The interface (CLI, MIB?, XML?, or other, usually CLI), the means to
access that interface securely, and the method of automating (can be
as simple as a perl program using the 'expect' interface to the CLI)
are all out of scope for the protocol definition.  "Manual" does not
mean human fingers in this contect, but through some means outside the
protocol itself, of which human fingers on the keyboard is one.

Another issue is that export restrictions on cryptography in some
countries and restrictions on use of cryptography in others would
prevent standardizing the "means to access that interface securely".
The least common denominator would be unacceptable in many
circumstances and the stronger methods would be illegal in others.
The key itself is used for authentication and is therefore legal in
places where the best means to avoid sending the key "in the clear"
might not be legal.


OSPF mailing list