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 <gnakibly@yahoo.com> Tue, 29 April 2014 13:18 UTC

Return-Path: <gnakibly@yahoo.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8251A08DC for <ospf@ietfa.amsl.com>; Tue, 29 Apr 2014 06:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alhGNi-Gvdal for <ospf@ietfa.amsl.com>; Tue, 29 Apr 2014 06:18:30 -0700 (PDT)
Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF5F1A08C6 for <ospf@ietf.org>; Tue, 29 Apr 2014 06:18:30 -0700 (PDT)
Received: from [98.139.212.151] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 13:18:29 -0000
Received: from [98.139.212.201] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 13:18:28 -0000
Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 13:18:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 860167.39416.bm@omp1010.mail.bf1.yahoo.com
Received: (qmail 16906 invoked by uid 60001); 29 Apr 2014 13:18:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398777508; bh=ZxbwuSJjoo35zB6ZDeel77hckvjfAQtjpmtEeSsVYa8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BKZOBoMkeKe/o3+KxnE5ltfIxmhxSwtMB5yyG1DrkmqRdfe9BO6d3gTTuAAx9MaFsnSaw2ZxfEDj9jhph6KFGwNtAmsO1WJXUqu4IfnCC6kZ1WRicpXyok2IV2oxOr7l/HjAuqLg9fgaFWAYEv4gtbLAqF40quK7BkMve9CGHBo=
X-YMail-OSG: z8fwK1oVM1mz3w0Y2M7MF2kI_aaib.BlBK3o_83yHHvB74z FDsXcpW8TlP0_ZBbpVafWImMVcW4pW7_Bao1nKoGGLKXW.S8mrY4g4GCIpwY S9cNoIFqx1Hd3.FDuQRe6n1Ts2jjd._Kg4Q0toP8Jj0oAqG3InzlG.aKsXl0 tvqKp4dAJKEL2exqVtNvUXS7ikatl6FHkYhI.0cBwD8fnwkVhHfysx9hdtGl wuDNRQobyBwMdQzl1WJgZqvo_SGlTKaXohAciUzBrqdRoWPtU68Lm8yDP6X0 kVImGyQEgZ0oioN.6MiUpJpoz8T_1W3ynqvc8SHVA8aK2B0UabVanrRbXEPE 0k9Ssnga0m7sMsPIVZTgg53fCFkys9TcCPL8ghZw50E2BkvxpmPjiaIFo3Ia ZdYk85nIkD3zosiZEXEosvhz40K86M4Ke.kZLui01CIOpfShTAFkDnigjcEL QKmnlFqWlqCD3ax5bTi0NT9uhzqbVyFHEnLOOEYCSTfbJQQKLpT3gRgsSQru mrPUctknreuIuAQFDACldPTnzzi2LyMOidulwRkHLLjFoQ0DSdfo-
Received: from [109.186.61.54] by web165006.mail.bf1.yahoo.com via HTTP; Tue, 29 Apr 2014 06:18:28 PDT
X-Rocket-MIMEInfo: 002.001, SGkgQWNlZSwKVGhhbmtzIGZvciB0aGUgcmVwbHkuCkp1c3QgdG8gY2xhcmlmeSBteSB0aG91Z2h0cywgSSBiZWxpZXZlIHRoYXQgdGhlIHVzZSBvZiBhIHNpbmdsZSBzZXF1ZW5jZSBudW1iZXIgc3BhY2UgcGVyIHJvdXRlciBkb2VzIG5vdCBwcmV2ZW50IHRoZSBhdHRhY2suIEhlcmUgaXMgYW4gZXhhbXBsZS4gTGV0J3Mgc2F5IGEgcm91dGVyIGlzIGF0dGFjaGVkIHRvIHR3byBsaW5rcyAoQSBhbmQgQikgd2hpbGUgdXNpbmcgdGhlIHNhbWUgSVAgYWRkcmVzcy4gTGV0J3Mgc2F5IHRoZSBhdHRhY2tlciBoYXMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.185.657
References: <53478C07.1020006@cisco.com> <1398321540.26301.YahooMailNeo@web165005.mail.bf1.yahoo.com> <481A10B2-4F1F-478C-A7A9-DFA780005D7A@ericsson.com>
Message-ID: <1398777508.12837.YahooMailNeo@web165006.mail.bf1.yahoo.com>
Date: Tue, 29 Apr 2014 06:18:28 -0700 (PDT)
From: Gabi Nakibly <gnakibly@yahoo.com>
To: Acee Lindem <acee.lindem@ericsson.com>
In-Reply-To: <481A10B2-4F1F-478C-A7A9-DFA780005D7A@ericsson.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="235176295-301273287-1398777508=:12837"
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/NNZfrCvNZSmD0t4-GqM2HPLFUSQ
Cc: OSPF List <ospf@ietf.org>
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-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Gabi Nakibly <gnakibly@yahoo.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: Tue, 29 Apr 2014 13:18:33 -0000

Hi Acee,
Thanks for the reply.
Just to clarify my thoughts, I believe that the use of a single sequence number space per router does not prevent the attack. Here is an example. Let's say a router is attached to two links (A and B) while using the same IP address. Let's say the attacker has recorded an Hello message the router just sent on link A. When the router sends this message its SN is higher than any other packet sent on any other link by that router. The attacker would now be able successfully replay the recorded Hello message on link B as long as it does so before the router sends another OSPF message on link B. Such an attack will probably bring down all adjacencies of the router on link B.

I think it would be good to document this type of attacks as many network operators configure the same key on different links. It would be good to bring to their attention the consequences of such configurations. If you wish, I can assist in writing this.

Gabi


>________________________________
> From: Acee Lindem <acee.lindem@ericsson.com>;
>To: Gabi Nakibly <gnakibly@yahoo.com>; 
>Cc: Abhay Roy <akr@cisco.com>;; OSPF List <ospf@ietf.org>; 
>Sent: Monday, April 28, 2014 6:06 PM
>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
> 
>
>
>Hi Gabi,  
>Thanks much for your review and comment.
>
>
>On Apr 24, 2014, at 2:39 AM, Gabi Nakibly <gnakibly@yahoo.com>; wrote:
>
>Hi,
>>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.
>
>
>Note that in section 2 we are recommending one sequence number space for the OSPF router as opposed to one per interface. Hence, this would have to be a replayed packet received from another router with the same source address since the OSPF Router ID in the OSPF header would be protected by the authentication hash. I would consider this to be a misconfiguration. 
>
>
>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.
>
>
>RFC 2328 does mandate source subnet checking on multi-access networks but not P2P networks. On P2P networks, this could be a problem but would require the attacker to have an active tap on both the P2P interface and another interface using the same key.  Again, this would have to be a replayed packet received from another router due to the OSPF router’s use a single sequence number space. There really isn’t a good solution for this problem on P2P links since the routers don’t share any common identifier for the P2P link. They have an ifIndex but this is a locally unique interface identifier. We can document the problem and recommend use of different keys if the possibility of active taps on P2P interfaces exists. 
>
>
>Thanks,
>Acee
>
>
>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.
>>
>>
>>Gabi
>>
>>
>>
>>
>>>________________________________
>>> From: Abhay Roy <akr@cisco.com>;
>>>To: "ospf@ietf.org"; <ospf@ietf.org>; 
>>>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
>>>
>>>
>>>All,
>>>
>>>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 
>>>deadline.
>>>
>>>Regards,
>>>-Abhay
>>>
>>>_______________________________________________
>>>OSPF mailing list
>>>OSPF@ietf.org
>>>https://www.ietf.org/mailman/listinfo/ospf
>>>
>>>
>>>
_______________________________________________
>>OSPF mailing list
>>OSPF@ietf.org
>>https://www.ietf.org/mailman/listinfo/ospf
>>
>
>
>
>