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

David Mandelberg <david@mandelberg.org> Fri, 15 September 2017 15:56 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 59AAB126BF3 for <secdir@ietfa.amsl.com>; Fri, 15 Sep 2017 08:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 c8Y2AKglnYcV for <secdir@ietfa.amsl.com>; Fri, 15 Sep 2017 08:56:35 -0700 (PDT)
Received: from nm16-vm4.access.bullet.mail.gq1.yahoo.com (nm16-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.104]) (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 7CBF313352B for <secdir@ietf.org>; Fri, 15 Sep 2017 08:56:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1505490992; bh=wqjLCJEwpHTzryDg7RAU1kFcoMKPc98xrEtgoqfd2Is=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=sc+SK1GfbtTSrW9ucxp6S1yQ2hECpU6IMX5PeGywL2aiP3lF5aQAoQwh3aSi5u9LxJhV8BBPTja/vFQWWvzKSCttB5FT5pxE4iktymZpPA2lY4HpiV3HgpNomwImtScBhHYvrSp6c/G3jWe+Ngl1vdfB6qwxOegs8f4SSNl75m/kK78C5M2fB+wavvsx/v71fMCqwzqrPyWyl+3Q1Jt6oTU176L7N4wborngrqhGJ904nLY/nRFek9V3uMnWhVwceZ52F6vo0VS3tOl6ZLzJztWEiX7WoK0jW+df155SnIoTuxTDgrNGV1cSUFpPxM0inO8nYWzuI981UVtq4wrVRQ==
Received: from [216.39.60.166] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Sep 2017 15:56:32 -0000
Received: from [98.138.226.244] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Sep 2017 15:56:32 -0000
Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 15 Sep 2017 15:56:32 -0000
X-Yahoo-Newman-Id: 555356.25303.bm@smtp115.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: UuolanEVM1nZrsnvw42HiXvmPQ6qLIWZXPXgMWAXb9KhK8g 8gOifUGocJWM8phEbxvqxdna.R01g8yFh1dqXCMx63GzzncfKYZeOGnvQlPZ FU15a6eC_sImwxQBXtL1fMNR8Ti0XeYt7IsyEnZ5X2cBSA8l0sSL4ulrG60F VgZBD6qZtrTsEGwNo6A3Zyaxxr8HbwyU8ekyaaO5UM9ABWWSMqYEiByZ.LWD pqIqzEmKpYeFnOakEUriHVentn2PIwVgTq65CWW7roRzx37ErtjuoULTHGlN wpdBcYZrUuyrIWnmyi8y8eB34VjtsDa8Dh1KYtYS4ym89JccCC2AjaCMo0A6 rjNJKZQ5UhI3aqmzVKUIyMpOpbEl.JGjC8IMIETJu5Nq27udUkRHReEZZ9ms sR53AmQJ.ipeMQA6VXwnGvNt4p42ZlsJhIiIq03K04lMkXeJhrQZdMRxuGuA vOScvnliuVj.FfydAd.L4ixz_2mqcA8M-
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 59DCD1C60AB; Fri, 15 Sep 2017 11:56:31 -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> <ae79dc6a-488a-2772-eca4-c325ea462a5f@mandelberg.org> <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@mandelberg.org>
Date: Fri, 15 Sep 2017 11:56:29 -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: <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/zufMM9ki-YttIz26bM2gh6nWzDc>
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: Fri, 15 Sep 2017 15:56:36 -0000

On 09/15/2017 03:31 AM, bruno.decraene@orange.com wrote:
> Hi David,
> 
>> From: David Mandelberg [mailto:david@mandelberg.org]
>   > 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.)
> 
> Regarding confidentiality, I can think of 3 things:
> a) This extension can introduce packet encapsulation. This does not affect whether encapsulated packet was encrypted or whether the transport infrastructure provide encryption (e.g. MACSEC)
> b) Although this is not currently the case, this extension could be extended to advertise tunnel with encryption capability. In this case, the attacker could change the tunnel properties to remove the encryption
> c) Specific tunnels could be advertised in order to route packet over a specific link that an attacker is monitoring.
> 
> Do you think that some of these points would be worse mentioning? If so I could write some text to cover those.

I don't think (a) affects security at all, and I think (b) is probably 
out of scope for this document. For (b), I think the hypothetical 
document describing the encryption capability would have some work to do 
explaining how it's secure, but I don't see any reason to do that work 
in this document.

(c) is the one that I think is worth looking into. E.g., does this new 
extension make it easier for an attacker to route a packet across AS 
boundaries, by setting a tunnel endpoint outside of the OSPF-routed network?

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