Re: [OSPF] AD review of draft-ietf-ospf-security-extension-manual-keying-08

"Acee Lindem (acee)" <> Fri, 03 October 2014 20:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D38F61A0012 for <>; Fri, 3 Oct 2014 13:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.686
X-Spam-Status: No, score=-14.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cm_tOqiUdv9D for <>; Fri, 3 Oct 2014 13:34:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78FE91A0004 for <>; Fri, 3 Oct 2014 13:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10897; q=dns/txt; s=iport; t=1412368449; x=1413578049; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PaA4FBUiE9AOmV1nFLH0Ym5YOFPmV2ZIrOEM+5bitjI=; b=gsXOKW/DXIgP8SN9MP/jn7WNebZ/OnEzwj3ASg5NfcjlTZa4GtT/qKXf D7bqGuZdmc4XfQqpNENngjvlInnRS1LVD7pXDVyFKaQYOpOtvBdfzoq8t p9BooXz4SlLl61yJ/bnb9tqXCE9NOrcUPq7Fw2fa64A1Q50OX5pL/hSsd A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.04,650,1406592000"; d="scan'208,217"; a="83888680"
Received: from ([]) by with ESMTP; 03 Oct 2014 20:34:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s93KY6hn028715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 20:34:06 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 15:34:06 -0500
From: "Acee Lindem (acee)" <>
To: Alia Atlas <>, Ospf Chairs <>, "" <>, "Vishwas Manral" <>, OSPF List <>
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-security-extension-manual-keying-08
Thread-Index: AQHP30lfKFDEyZBSYkWERtEYXy7zBg==
Date: Fri, 3 Oct 2014 20:34:05 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D0547BDF4208aceeciscocom_"
MIME-Version: 1.0
Subject: Re: [OSPF] AD review of draft-ietf-ospf-security-extension-manual-keying-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Oct 2014 20:34:10 -0000

Hi Alia,
Thanks for the review. See inline.

From: Alia Atlas <<>>
Date: Friday, October 3, 2014 at 3:52 PM
To: Ospf Chairs <<>>, "<>" <<>>, Vishwas Manral <<>>, OSPF WG List <<>>
Subject: [OSPF] AD review of draft-ietf-ospf-security-extension-manual-keying-08

As I do with all drafts that are ready to progress, I have done my AD review of this
draft-ietf-ospf-security-extension-manual-keying-08.  In this case, I apologize for it taking so long.

The draft is very clear and well-written.  I do have a few comments, but I have sent it to IETF Last Call for review while we discuss.  Assuming that goes smoothly and comments (including mine below) are taken into account, I expect the draft to go to IESG telechat for Oct 30.

Major Comment:

My one concern is that in Section 3, it says:

"Additionally, the 64-bit sequence number is moved to the first 64-bits following the OSPFv2 packet and is protected by the authentication digest."

but I do not see any other place where RFC 5709 is updated to include that sequence number.  In Sec 3.3, RFC 5709 says:

   First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet))

and I think it would be most excellent for this draft to clearly

update that to be (OSPFv2 Packet + Sequence Number).

With this draft, we attempted to avoid Stephen Farrell’s ire by not repeating the authentication algorithm as we have done when apply SHAx-HMAC authentication to each routing protocol. Note that RFC 5709 includes the statement:

  Implementation Notes:

          Note that the First-Hash above includes the Authentication
          Trailer containing the Apad value, as well as the OSPF packet,
          as per RFC 2328, Section D.4.3.

In section 5, we wukk add:

                          The 64-bit sequence number will be included in the First-Hash along with the Authentication
                           Trailer and OSPF packet (Refer to Section 3.3 in RFC 5709).

Minor Comments:

Should the meta-data and header indicate that this updated RFC 5709?  It certainly looks like it.

I don’t feel strongly on this. However, this is a new type of OSPFv2 cryptographic authentication and RFC 5709 authentication will continue to be supported by implementations that support it. So, one could argue that it updates RFC 2328 rather than RFC 5709. The whole issue of when to use the “Updates” would be a good topic for WG chair discussion.


Thanks for the hard work on a good draft to make routing more secure!