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

David Mandelberg <david@mandelberg.org> Tue, 19 September 2017 16:24 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 70D6F133342 for <secdir@ietfa.amsl.com>; Tue, 19 Sep 2017 09:24: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 AZlmfmt1xx9M for <secdir@ietfa.amsl.com>; Tue, 19 Sep 2017 09:24:25 -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 39204134294 for <secdir@ietf.org>; Tue, 19 Sep 2017 09:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1505838261; bh=dZfYNvuXZO9my4rMwT7ZmDDeFxXglfh7WgdBlY27JaU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=KosgS1JwnW5MWKNaa36Z3hvsV+xxHjBDEOQ+ZclYqV8mLjeBATVjdGnh9Hg7pZey7eqsUmRkYitr1qPkNnmnvO9n+5RWA0SHNDkWl82p75FhdOEjgGNVYg3sIl2SDWFXwx29gcm74gjaylo8SAQ0tszSZhmeqj9ysd/MgBheJQ9DhQ6YDlQpKdYJopEL+IkYY3oaB5dlbETf7Bii9v8XEVIfjoN/PBM1UwpsTB4gE7OuXb1jZhJWSK2JfyeNCKM7UmUec/ItFWDBWJItMjNi9HyZXGSHHQ8Y5aEhKjZ+FZ3vUREVEt80szW+mMOO1xew/vl3dUBTLkgsYQnq0EOURQ==
Received: from [66.196.81.158] by nm19.access.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2017 16:24:21 -0000
Received: from [98.138.39.78] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2017 16:24:21 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 19 Sep 2017 16:24:21 -0000
X-Yahoo-Newman-Id: 532349.44326.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: qCrzKsEVM1lJCyEOuoTOHrwiDld_EGrS7Trq9efZBaM5YJ_ SHwfjH8lyuN20Qt2JSYmFNMFvFxfPriI_zNV.5Kyw69yHDvH8Hv9EeS43Ua4 .esRzRxlWru.dlZGFABYi5NWjAK0XlwQ_isbDNIVVSttiqeHUMaTO.KecXxV oyix4KlP_LJsV2wO0f9QLUEZUihFIyXqkxxS6tNLSR8PkM_0JNSXsCSF2HWr iuUdFLaPBcejBzjQ7YuUCTL.XP2YK4xCGOay1YeoEXWDWSrzObfGwAmjD8If 3kOrBXK87aDKpCRfUQfuAL2aY6YpGFJ9lRhOrPIrx0v2kQ6oFWuWpg3c8W0L 4154lYOYuWBrYp5GpxnIU017I1K9AkKI2SaENTd.R6kYQK2AgWSHoijNnYd8 FMSTvaKgfnqeoIwPrEUSWVBC6JjfUrXNp8pVaWadejY1deTw55ICZe5MuTzZ TeaIeRUkmrWzhSGH8Dp7d3qPM9DzGiA--
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 BC3DC1C6066; Tue, 19 Sep 2017 12:24:19 -0400 (EDT)
To: "Acee Lindem (acee)" <acee@cisco.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Robert Raszuk <robert@raszuk.net>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ospf-encapsulation-cap.all@ietf.org" <draft-ietf-ospf-encapsulation-cap.all@ietf.org>, "secdir@ietf.org" <secdir@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> <12465_1505725711_59BF8D0F_12465_296_1_53C29892C857584299CBF5D05346208A478787B1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <5ee2e3cf-4034-f9e6-4fca-92ceb57a65c5@mandelberg.org> <11040_1505805523_59C0C4D3_11040_226_4_53C29892C857584299CBF5D05346208A4787AC94@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CA+b+ERneJBn_jJgDYZ+dQbb6CaLP_3xy14w4hhBWYKHkSBHnGA@mail.gmail.com> <27250_1505808909_59C0D20D_27250_468_2_53C29892C857584299CBF5D05346208A4787AEEC@OPEXCLILM21.corporate.adroot.infra.ftgroup> <D5E66FC2.C878E%acee@cisco.com>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <b9e0dfcf-d2db-a96a-a389-41336fcd209b@mandelberg.org>
Date: Tue, 19 Sep 2017 12:24:17 -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: <D5E66FC2.C878E%acee@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/vQ-waklUsmWeFjb1xOsmTlxBM_Q>
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: Tue, 19 Sep 2017 16:24:27 -0000

Looks good to me too.

On 09/19/2017 07:01 AM, Acee Lindem (acee) wrote:
> Hi Bruno, Robert,
> 
> Sounds good to me. One nit – replace “e.g. “ with “, e.g., “ in the 
> added text.
> Thanks,
> Acee
> 
> From: Bruno Decraene <bruno.decraene@orange.com 
> <mailto:bruno.decraene@orange.com>>
> Date: Tuesday, September 19, 2017 at 4:15 AM
> To: Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> Cc: The IESG <iesg@ietf.org <mailto:iesg@ietf.org>>, David Mandelberg 
> <david@mandelberg.org <mailto:david@mandelberg.org>>, 
> "draft-ietf-ospf-encapsulation-cap.all@ietf.org 
> <mailto:draft-ietf-ospf-encapsulation-cap.all@ietf.org>" 
> <draft-ietf-ospf-encapsulation-cap.all@ietf.org 
> <mailto:draft-ietf-ospf-encapsulation-cap.all@ietf.org>>, 
> "secdir@ietf.org <mailto:secdir@ietf.org>" <secdir@ietf.org 
> <mailto:secdir@ietf.org>>
> Subject: RE: secdir review of draft-ietf-ospf-encapsulation-cap-06
> Resent-From: <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org>>
> Resent-To: Xiaohu Xu <xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com>>, 
> Bruno Decraene <bruno.decraene@orange.com 
> <mailto:bruno.decraene@orange.com>>, Robert Raszuk <robert@raszuk.net 
> <mailto:robert@raszuk.net>>, Luis Contreras 
> <luismiguel.contrerasmurillo@telefonica.com 
> <mailto:luismiguel.contrerasmurillo@telefonica.com>>, Luay Jalil 
> <luay.jalil@verizon.com <mailto:luay.jalil@verizon.com>>, Acee Lindem 
> <acee@cisco.com <mailto:acee@cisco.com>>, <akr@cisco.com 
> <mailto:akr@cisco.com>>, <aretana@cisco.com <mailto:aretana@cisco.com>>, 
> Deborah Brungard <db3546@att.com <mailto:db3546@att.com>>, Alia Atlas 
> <akatlas@gmail.com <mailto:akatlas@gmail.com>>, Acee Lindem 
> <acee@cisco.com <mailto:acee@cisco.com>>
> Resent-Date: Tuesday, September 19, 2017 at 4:15 AM
> 
>     *From:*rraszuk@gmail.com <mailto:rraszuk@gmail.com>
>     [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk
> 
>     Please replace AS with Administrative Domain.
> 
>     [Bruno] I replaced AS with “OSPF domain” as indeed, AS is a BGP term
>     rather than an OSPF one. And as you note, in some cases, the AS and
>     the IGP domain may be different. Thanks.
> 
>     If I have three ASes there should be no artificial limits
>     prohibiting encap to my central collector.
> 
>     [Bruno]
> 
>     If your central collector is part of the OSPF domain of the
>     encapsulator, there is no problem.
> 
>     Otherwise, if the route to your central collector is advertised in
>     OSPF by the decapsulator, there is no problem.
> 
>     Otherwise, if the route to your central collector is advertised in
>     BGP, then draft-ietf-idr-tunnel-encaps is probably the right tool.
> 
>     --Bruno
> 
>     Thx
> 
>     R
> 
>     On Sep 19, 2017 08:18, <bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>> wrote:
> 
>     > From: David Mandelberg [mailto:david@mandelberg.org <mailto:david@mandelberg.org>]
>       > Sent: Monday, September 18, 2017 9:30 PM
>     >
>       > On 09/18/2017 05:08 AM, bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com> wrote:
>       > >   > (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?
>       > >
>       > > No. The following text already prohibits even more than this:
>       > >
>       > > "  A tunnel MUST NOT be
>       > >        used if there is no route toward the IP address
>     specified in the
>       > >        Endpoint Sub-TLV (See <xref target="EndpointTLV"/>) or
>     if the route is
>       > >        not advertised by the router advertising this Tunnel
>     Sub-TLV."
>       > >
>       > > - By definition, this Tunnel Sub-TLV is advertised in OSPF
>     i.e. from within the AS.
>       > > - The text also prohibits setting a tunnel endpoint to another
>     router within the AS.
>       > >
>       > >
>       > > That being said, within the AS, the point "c" still applies.
>       > > However, thinking twice, the probability is even more limited.
>     Indeed, one can only advertise a
>       > tunnel to itself. Assuming that the third party can't control
>     the whole routing topology (i.e. routing
>       > advertisement from most core routers), it cannot control the
>     path followed by the tunnel. Hence it
>       > would need to have monitoring capabilities on specific links
>     that it cannot choose. (the link on
>       > the path to itself).
>       > > Plus this risk is not new, as the third party could already
>     advertise the destination IP address of
>       > the packets (or of the BGP Next-hop of the BGP route matching
>     the packet destination), without
>       > using any tunnel.
>       > > In conclusion, although I could be wrong, I'm not seeing such
>     new risk. (again, assuming that
>       > a third party can modify the OSPF routing is a big assumption).
>       > >
>       > > But the discussion was useful, thanks for the comments.
>       >
>       > That explanation is great, thank you. I hadn't realized the
>     implications
>       > of the paragraph you quoted, when I initially read it. I'm convinced
>       > that there isn't a security issue here, but it would be nice to
>     see your
>       > explanation in the document itself, if it's not already obvious to
>       > anybody who knows OSPF better than I do.
> 
>     I've just added the following text in the security section of my
>     local version:
>     "We note that the last paragraph of <xref target="Operation"/>
>     forbid the establishment of a tunnel toward arbitrary destinations.
>     It prohibits a destination outside of the Autonomous System and also
>     to other routers within the AS. This avoid that a third-party
>     gaining access to an OSPF router be able to send the traffic to
>     other destinations, for e.g. inspection purposes. "
> 
>     Feel free to comment/propose other text.
> 
>     Since I've just published -08 a few hours ago, I'll probably delay
>     the upload of this new update.
> 
>     --Bruno
> 
> 
>       > --
>       > Freelance cyber security consultant, software developer, and more
>       > https://david.mandelberg.org/
> 
>     _________________________________________________________________________________________________________________________
> 
>     Ce message et ses pieces jointes peuvent contenir des informations
>     confidentielles ou privilegiees et ne doivent donc
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous
>     avez recu ce message par erreur, veuillez le signaler
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les
>     messages electroniques etant susceptibles d'alteration,
>     Orange decline toute responsabilite si ce message a ete altere,
>     deforme ou falsifie. Merci.
> 
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>     they should not be distributed, used or copied without authorisation.
>     If you have received this email in error, please notify the sender
>     and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.
>     Thank you.
> 
>     _________________________________________________________________________________________________________________________
> 
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>     they should not be distributed, used or copied without authorisation.
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>     Thank you.
> 


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