Re: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07

Gabi Nakibly <> Thu, 24 April 2014 06:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C08A1A07B5 for <>; Wed, 23 Apr 2014 23:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.429
X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UF9JswnItp1I for <>; Wed, 23 Apr 2014 23:39:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1A12D1A07B2 for <>; Wed, 23 Apr 2014 23:39:07 -0700 (PDT)
Received: from [] by with NNFMP; 24 Apr 2014 06:39:01 -0000
Received: from [] by with NNFMP; 24 Apr 2014 06:39:00 -0000
Received: from [] by with NNFMP; 24 Apr 2014 06:39:00 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 26600 invoked by uid 60001); 24 Apr 2014 06:39:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1398321540; bh=Uiujm7qXMZ7j4tDmzYa1GN59HHMxcBbiS2EDatekMkk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5svpTkH6b815lZxBoSEJZ3T8eRHGBifjpWxJ7szS13fJ1kMMKl6aykn0p4lri36iOqjOatXz75pyfD+1EIqLADh4bMvJaKM1Nqkmtly1HqBY1Om1Z7GKWrcszfM75Y41d6pyoycL0SOAkZXE2ckklyDlZgcy5lsDZYggOeFz6qg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2nHWGbL5AiSDiX78qyMoOQgIQllG9jEIjqJTcpPlVplO9hk0irAU11w/ap3sCrx3djV3GB1R/NB/d2MBG09vulyuP87bByDpfg3e7gKKrpS7qo31iy8X58f+jjjX8sFJjrQArAx6GJmjyUCpHdH8gfeVeyOf21YxDULfX/OXeag=;
X-YMail-OSG: x6jiYGMVM1kULRQsJdOhhtU7TfxlzTqm304NUY6Rmi0lROj xjiI4aSy0mDIuxxmt7u2Bfs7o3fyEuc9CgcBE6KRB1NVqngFwDShwOK.iUw2 .nQ5DHJ_8Cp6CeDHuaBUlR_67WGUC4d8dGce93Gyre7PbSix5XkeV918TgKT lhuAW5mSerxZUzI2LiNBTPgtREQ8k1OfY9aD0TZB1ylgfwiLjIBpipjPItQb y3uY0iFBAqfjULstDlQYezrX7w6QcVdelxN1NONd.bEx6LelqjIzXbyHlOQw 4NEkfTTMl6dfXLfxLPRrbng11HCnjG3zAVajG5TRVExNdKdoHWnUAD7nWRDp mtwjqBOBIHsARC.RUa0qBaqZXmWwyjGhkcs9NO24akrGOdXZr_21SffMlKy9 eSMLRm_kfvdTDiEsO2_gM3VvOmFSI4jGQgNfjry1ZS.MmSoWOZGRsv.QTiCW YewgIH2LT32VWYMLhfQxKx1huUES8Lp9.wklV.2b0Au8G.edH.YV78jLqvq7 r0vWi70RyIR4w5l_FVYUDUH6NbieuXsUFNpqTWJVMvoZvOe4CU6Q-
Received: from [] by via HTTP; Wed, 23 Apr 2014 23:39:00 PDT
X-Rocket-MIMEInfo: 002.001, SGksCkkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyBhIHNpZ25pZmljYW50IHN0ZXAgZm9yd2FyZCBmb3IgdGhlIHNlY3VyaXR5IG9mIE9TUEYuIEkgZG8gaGF2ZSBvbmUgY29tbWVudCwgdGhvdWdoLsKgSXQgaXMgY29uY2VybmVkIHdpdGggdGhlIGNhc2UgaW4gd2hpY2ggdGhlIHNhbWUga2V5IGlzIGNvbmZpZ3VyZWQgb24gZGlmZmVyZW50IGxpbmtzLiBJZiBzdWNoIGEgc2l0dWF0aW9uIG9jY3VycyB0aGVuIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gcmVjb3JkIGFuIE9TUEYgbWVzc2FnZSBvbiBvbmUBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <>
Message-ID: <>
Date: Wed, 23 Apr 2014 23:39:00 -0700 (PDT)
From: Gabi Nakibly <>
To: Abhay Roy <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="571662966-391532315-1398321540=:26301"
Subject: Re: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Gabi Nakibly <>
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Apr 2014 06:39:09 -0000

I think this document is a significant step forward for the security of OSPF. I do have one comment, though. It is concerned with the case in which the same key is configured on different links. If such a situation occurs then an attacker might be able to record an OSPF message on one link and replay it on another. This is particularly relevant for cases where one router uses the same source address in multiple links (e.g. a virtual link and a physical link). So the attacker can record a packet sent by that router on one of the links and replay it over the other as if it was sent by the router itself. This may allow an attacker to cause an adjacency to be brought down.
Moreover, a recorded Hello message may be replayed on arbitrary links (even those that do not share a router using the same source address). If I am not mistaken, RFC2328 does not mandate to discard an Hello message having a source address that is not part of the subnet of the interface on which the message was received. Therefore, the recipient of the replayed message would allocate a new neighbor entry, thus giving rise to a DoS attack.

I know that the OSPF standard allows to configure different keys for different links, nonetheless in most of the OSPF deployments I have seen the same key is configured for all links in the AS (or area). I do not know if this is representative of OSPF deployments worldwide, but it might be prudent to analyse the security of the proposed extensions in the context of such cases as well.


> From: Abhay Roy <>;
>To: ""; <>; 
>Sent: Friday, April 11, 2014 9:30 AM
>Subject: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07
>We are starting a WG LC on the subject document. Document has been 
>stable for a while, and Manav was kind enough to present it one last 
>time in IETF89 (London). LC will end at 9am PST on 25th April 2014.
>Please review the document and send any final comments prior to the LC 
>OSPF mailing list