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

David Mandelberg <david@mandelberg.org> Fri, 15 September 2017 16:36 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 42A0013209C for <secdir@ietfa.amsl.com>; Fri, 15 Sep 2017 09:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 a_-tFp2k9_yS for <secdir@ietfa.amsl.com>; Fri, 15 Sep 2017 09:36:25 -0700 (PDT)
Received: from nm1.access.bullet.mail.bf1.yahoo.com (nm1.access.bullet.mail.bf1.yahoo.com [216.109.114.32]) (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 125AE132FA7 for <secdir@ietf.org>; Fri, 15 Sep 2017 09:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1505493383; bh=wIsoNPj4jEnLIxo0OCZUW/3tCAsQJvbPHdauwknoG04=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=CuesdtP6ECRm1Wamil8IdqGSwXb7O/via1K7xF6rdh589ppiLnUKOUif1cX/WC2pmdPAZce9Ol208qYhQmUgHJ1QlCYH9NmSIWJaiyfW5YhDAUVC4Ya/sxpqnfBnQCjuRA+kAs9V3QMYe/99zUCxsb2r/J65qjq4cXlc93dN+jY317swbt6PuCtY/wTQqq7PL7SErK/951pxZDN6WV454QdWVreG+Sx1y3DEgXf7pCVGNBkhr/byc6+Uz3nwgGvRhigg3tCBkQTzGE1Oibl6P3zCjkx37qQ5vFQ3QB5Gbvu1crxltRF8fPM0rXXnsgHwAX5zbGzrR4PCgZvQ/zNbrg==
Received: from [66.196.81.155] by nm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2017 16:36:23 -0000
Received: from [98.138.226.244] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2017 16:36:23 -0000
Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 15 Sep 2017 16:36:23 -0000
X-Yahoo-Newman-Id: 285673.35798.bm@smtp115.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: Jw3iZXYVM1n3XIwzGkjVh9zo_laEWhVZk7HLpfN1LJlLGKI XTZlLH61wvb44cjqC2CzMxoYij5_LLWylNQdFjblgl_.9NvWU8t0LKCwyn88 m5i6lI_KdxRzFPGQkjHekmfnT0eIyUXLBX.VUR8tiTt5TmfrVh_57C39i9fA nexgFwh25cCU9eKG6UJzy59eMqnZYQJa_Y3m03AxytCEbFDHLqO0NjXBmJo. YqJLNvTtd4FfimoHDx9uM6MIQCzKbArFJ3I0OXV99UG_2MNszmHoGr6A3czr RRJBstrtwXHNgom_rsc_f.6cftg2l8wfwUS_T.t.Wj.TrVLb.CK618IA9VES JTAed3eR74Xv_IT168g9s4wwCBj6sAxtN6nsx7Gc_nsvC0O9HsHmNfeeQ5Ae 5gZcKagy7hQrqcbL6kvnqhdvFe9npVwB3VhAL0ggi1qraksjVR76m.imfzDU 0_GVGjlvz_0OBJnHuj3bsL85kFZho9rYxnH.ib98r_bFL2NGj9TzIJg--
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 45FA41C60AB; Fri, 15 Sep 2017 12:36:22 -0400 (EDT)
To: Robert Raszuk <robert@raszuk.net>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "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> <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@mandelberg.org> <CA+b+ERmxR8z1nCfhQwfj9U9jBxuP63XjLMD_kCsySUxoQvGgQg@mail.gmail.com> <a922cb18-93f0-94ef-fa9a-59d7565fc836@mandelberg.org> <CA+b+ER=OfhDrEbCr2ewn8PVNcgbOJEJPkOYv4bPsw5WpGLZNjg@mail.gmail.com>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <8fdd20ef-15ae-a735-778f-f087bbc2f63f@mandelberg.org>
Date: Fri, 15 Sep 2017 12:36:20 -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: <CA+b+ER=OfhDrEbCr2ewn8PVNcgbOJEJPkOYv4bPsw5WpGLZNjg@mail.gmail.com>
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/1y3eyEDg0ZEwzuVCpAjzQ_P1sFA>
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 16:36:27 -0000

Thanks!

On 09/15/2017 12:28 PM, Robert Raszuk wrote:
> Hi David,
> 
> This draft inherits RFC 5565 security considerations so I was hoping 
> this would be sufficient. However I have no objection to add extra text 
> directly to this section 8 to recommend filtering/policy when flooded 
> information is passed to data plane explicitly listing the allowed range 
> of encapsulation destinations.
> 
> Thx,
> R.
> 
> 
> On Fri, Sep 15, 2017 at 6:17 PM, David Mandelberg <david@mandelberg.org 
> <mailto:david@mandelberg.org>> wrote:
> 
>     On 09/15/2017 12:02 PM, Robert Raszuk wrote:
> 
>         David,
> 
>         But how would an external attacker inject this information into
>         OSPF ?
> 
> 
>     By (partially) compromising a router, for example. I know an
>     attacker with that capability can already do a lot of bad stuff, but
>     it's not clear to me whether or not this extension gives them any
>     additional capabilities.
> 
> 
>         Also note that this information is opaque to OSPF itself and it
>         is highly recommended that set of policy rules (protecting from
>         misuse or even accidental mistakes) to be applied on it when
>         reaching the destination code (here encapsulation and forwarding
>         subsystem).
> 
> 
>     That sounds like a simple and secure way to address my concerns. If
>     the document already contains text recommending that local policy be
>     used to prevent forwarding outside of the authorized network, then
>     apologies for missing/forgetting it. If not, would you mind adding
>     something to the security considerations about it?
> 
> 
> 
>     -- 
>     Freelance cyber security consultant, software developer, and more
>     https://david.mandelberg.org/
> 
> 


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