Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06

David Mandelberg <david@mandelberg.org> Thu, 14 September 2017 20:22 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042E2132335 for <secdir@ietfa.amsl.com>; Thu, 14 Sep 2017 13:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 strVFeXzs4Hg for <secdir@ietfa.amsl.com>; Thu, 14 Sep 2017 13:22:37 -0700 (PDT)
Received: from nm19-vm2.access.bullet.mail.bf1.yahoo.com (nm19-vm2.access.bullet.mail.bf1.yahoo.com [216.109.115.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFF1132E2A for <secdir@ietf.org>; Thu, 14 Sep 2017 13:22:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1505420555; bh=Mg3sfP0T66EvJ9qxuVJKriPBXLGQJBE4z1YDM/xkpnA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=aSrg/JCvkvVfyWF/x+8sX2+Crxq2UHnu7SSUV9wG0av+rp4oVBlZF3h6N9dPc92tzWfGfOUZPmMRxtr1SdJ07IJp7cfjd2RVMJuB5RgKLcmoOhKzrxUEDhdEjkhLWd7EDz3sU0zLCHzPv8geurnh1Y6iOD6Kssd8+u93xFD9YvWTj4uRpk/y3aX/oAzeIwVrcVJ8Jy91Y6ez6QBrp7RWRLIulQuFFPG2wJ4QrYjCr9ON7P2A14Q8SR0DmLI/uo+/raZTPFj2cC8M4FeZlGlIp4iEf3ObAr6MYqZ0CYJZhU0btsxH9/gu3DRE5c6pYz0NVSOPbPAsyWEI7N0toZ0TLg==
Received: from [66.196.81.165] by nm19.access.bullet.mail.bf1.yahoo.com with NNFMP; 14 Sep 2017 20:22:35 -0000
Received: from [98.138.226.243] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 14 Sep 2017 20:22:35 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 14 Sep 2017 20:22:35 -0000
X-Yahoo-Newman-Id: 250458.86989.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: lHPsJhAVM1nLcDCdg3BBpnCP.OxJaB8C6_EU1E1e_DKLgzE ZYiYus4e8UO.nvpNa6XvyOl25npq.KdKIhW6A99DsD2l2eNspP0Hy3s8psoE LZ3ECs84B22j3Jt1fQ2NHmeqdjbUXePgbfJnqAePhoPqV3G_yJu34Y1Errje bTCYOQdw9PY03_k30svNMLnWL_Eh4mQ8DazSpfoXjQo4BZ2T5xx2KwEmXpLs bf8pyoFJa25rZ.EEEsUQHQzwBAWhBBvMaVSf6PI6QlnU__bjUimXu8VbFZ1B BivDA97R3UbZnNwmhaCRskwg3Wy8kp7Ro5VHKmi5_GQFsWQI0RUANQUqsIhl isrhlnzksBl6VMrt8LrhzJwrbgrFpqlTGeblQVYXF8yMX67H3IIHfbDl7wJc OsOBUTYTST2Ysxpi6xvbpcKeabd5O.teg_ZSZRMGvBrij2y74_SRqqJaYra7 .PTZc9WHjIl7DwCrclp2bWHSnPHdCvUNJqoy.uJMHYHzid9AXSM_ULSRx5oh 9PIMNDzg-
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id D81F11C609C; Thu, 14 Sep 2017 16:22:33 -0400 (EDT)
To: bruno.decraene@orange.com
Cc: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ospf-encapsulation-cap.all@ietf.org" <draft-ietf-ospf-encapsulation-cap.all@ietf.org>
References: <475c78dc-c872-8795-2d99-81b28df97aed@mandelberg.org> <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <ae79dc6a-488a-2772-eca4-c325ea462a5f@mandelberg.org>
Date: Thu, 14 Sep 2017 16:22:31 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/CC45jE39Sw35i7EimHzsygo4Jxg>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 20:22:39 -0000

On 09/14/2017 02:04 PM, bruno.decraene@orange.com wrote:
> Hi David,
> 
> Thanks for your review.
> 
>> From: David Mandelberg [mailto:david@mandelberg.org]
>   > Sent: Saturday, August 26, 2017 8:49 PM
>>
>   > I have reviewed this document as part of the security directorate's
>   > ongoing effort to review all IETF documents being processed by the
>   > IESG.  These comments were written primarily for the benefit of the
>   > security area directors.  Document editors and WG chairs should treat
>   > these comments just like any other last call comments.
>   >
>   > The summary of the review is Ready with nits.
>   >
>   > This document extends OSPF for use with tunnels. As mentioned in the
>   > security considerations, an attacker who can modify routing information
>   > can cause packets to be misdirected or dropped. However, that seems to
>   > be the general nature of routing attacks. I don't know if this document
>   > makes such attacks any more likely or more severe, but it would be nice
>   > to see a bit more discussion of that in the security considerations.
>   > E.g., are OSPF attacks without tunneling less severe because of some
>   > limitation on where packets can be forwarded, while tunneling makes it
>   > easier to forward packets to anywhere on the Internet? Or is that not
>   > the case? (I'm not very familiar with OSPF or with the environments it's
>   > typically used in.)
> 
> OSPF is routing internal to a routing operator. Information received from internal OSPF routers are supposed to be trusted. Personally, I would find unacceptable if an attacker could modify such routing information. I don't think that this extension make it any more likely. In term of severity, I don't think that this is more severe than modifying routing information. e.g. link bandwidth in TE advertisement. Not to mention changing the network topology/graph which currently creates micro-forwarding loops in the network. The only additional consequence that I could think of, is advertising (more) tunneling instructions when the decapsulator is not capable of decapsulating the tunnel at line rate. This would overload its decapsulation processing. This is already identified in the security section of RFC5565 that we are citing. In addition, assuming that the node would not crash because of bugs, that would merely create packet drops, while there is so many ways to create ones if an attacker could modify routing information. Starting with a whole network meltdown.
> In short, I don't think that this protocol extension significantly change the OSPF security considerations.

Your points are all about how this extension does not affect security 
considerations around the availability of the network, and I agree. 
However, what about confidentiality? Does the extension make it easier 
for an attacker to read packets they wouldn't otherwise be able to read? 
(I'm not at all convinced the extension does have a problem there. I 
just think it's plausible enough that it would nice to see an 
explanation of why it's not a problem.)

-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/