Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06
David Mandelberg <david@mandelberg.org> Tue, 10 October 2017 02:46 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 5F7C113431D for <secdir@ietfa.amsl.com>; Mon, 9 Oct 2017 19:46:39 -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=ham 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 x9PYYMxbKPab for <secdir@ietfa.amsl.com>; Mon, 9 Oct 2017 19:46:36 -0700 (PDT)
Received: from sonic304-37.consmr.mail.gq1.yahoo.com (sonic304-37.consmr.mail.gq1.yahoo.com [98.137.68.218]) (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 9DB4A132153 for <secdir@ietf.org>; Mon, 9 Oct 2017 19:46:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1507603596; bh=W1Wu5J2041JGpgRN/jql1WFvLa122yoCA88p29N0gBg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=s4RH5+CfFvykayHr0xvB+UZDs5THHWgETs2DdelxfydgC6V3t/GcNL8jDrO9Cuz60l/tQFTAjbraPCe3ITLjErGKiTuIPWZ29wj18YL5hdKgriEAN++M2tYcqFDuZBvnKbY70ZPk6sQXzHyLSypCrt8/HRJEIVD6RgUeNs/32C/MDIw+f6/T3+R2oQN4hTny19TI05QbACbJwky+debJwZo4IMz5D1j1L3DTwh2H19l5H95O4BBrbchm4FI6tYLePjL31PtglEWFg4exrfdcOuul7h/K5IoLuoVODtjjiiBqjlBzvxObzsV2EJSjBdeYArtRfC3gwIlZVQYp6eBaMg==
X-YMail-OSG: vHNQ5IAVM1lK7xx1pi5aNQeFFDVzhgAqKHxRgkVshYgQJW78ePnctynOFHlxgwM yfjZP.erK.QCGkUyzBwfVuRdkQsOTgqLLsAincG8Bcxi_8GYhw7mO8kKafYP.HzLJe54c7.fUJRU ZC13ZSGi9qzrT5VAmXbnv76E2c95c2UCfao2H7X79VzzU6pMxS0INdbLj33wJH6t4wIKmLkBMxSK UMDysYzsJqnoZVw1zL1bAWt2.x8WhaTg1qYAV9.3JNhffqxLG0UNwYqRMhlp427yH9dKDScFJndm sdFtptVW3M235MnFaM0hpvpzgme1kLZ2LHMPtmtCC.I3EahoTDD1H0v9UhEPsoHf7ixhX1FYTomv PkIboVSc7wHV4q_rHjWVc4.thgWyta4lCyLn3TJKip2UXPoFskZCSOX5ebo9mRn2dt_.nuWAoEnx U65xzehm_4wjfiDaYmukzlu557pVB4juFY8YbLvKNKl7HDX6b1hq1SLcG8Rdb3TPAB.zsO7xiyMB T7WqVQ5LB_rJGu_k-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 Oct 2017 02:46:36 +0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 10 Oct 2017 02:46:32 -0000
X-Yahoo-Newman-Id: 24816.31996.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: vHNQ5IAVM1lK7xx1pi5aNQeFFDVzhgAqKHxRgkVshYgQJW7 8ePnctynOFHlxgwMyfjZP.erK.QCGkUyzBwfVuRdkQsOTgqLLsAincG8Bcxi _8GYhw7mO8kKafYP.HzLJe54c7.fUJRUZC13ZSGi9qzrT5VAmXbnv76E2c95 c2UCfao2H7X79VzzU6pMxS0INdbLj33wJH6t4wIKmLkBMxSKUMDysYzsJqno ZVw1zL1bAWt2.x8WhaTg1qYAV9.3JNhffqxLG0UNwYqRMhlp427yH9dKDScF JndmsdFtptVW3M235MnFaM0hpvpzgme1kLZ2LHMPtmtCC.I3EahoTDD1H0v9 UhEPsoHf7ixhX1FYTomvPkIboVSc7wHV4q_rHjWVc4.thgWyta4lCyLn3TJK ip2UXPoFskZCSOX5ebo9mRn2dt_.nuWAoEnxU65xzehm_4wjfiDaYmukzlu5 57pVB4juFY8YbLvKNKl7HDX6b1hq1SLcG8Rdb3TPAB.zsO7xiyMBT7WqVQ5L B_rJGu_k-
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 CA0A31C608F; Mon, 9 Oct 2017 22:46:30 -0400 (EDT)
To: bruno.decraene@orange.com
Cc: "draft-ietf-ospf-encapsulation-cap.all@ietf.org" <draft-ietf-ospf-encapsulation-cap.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Alia Atlas <akatlas@gmail.com>
References: <475c78dc-c872-8795-2d99-81b28df97aed@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> <b9e0dfcf-d2db-a96a-a389-41336fcd209b@mandelberg.org> <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <c5a9a4fc-ecab-b471-0cf8-a044419303c1@mandelberg.org>
Date: Mon, 09 Oct 2017 22:46:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup>
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/LBuX1akYMb2dGOXjUNjwpFzc9ec>
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, 10 Oct 2017 02:46:39 -0000
Thanks for checking, that looks good. On 10/09/2017 11:53 AM, bruno.decraene@orange.com wrote: > [removing the iesg to limit spamming, adding Alia (responsible AD)] > > Hi David, > > Sorry to come back on this draft 3 weeks after our latest email, but a > late comment is likely to change a sentence in the draft. > > As we had discussed that sentence during your secdir review, I feel that > it would be honest to come back to you to report that change, even if I > don’t feel the change is problematic. > > Proposed 2 changes are the following: > > § Operation > > OLD: > > 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. > > NEW: > > 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 in the same OSPF domain. > > == > > The reason is that in multi-area OSPF deployments, the Tunnel Sub-TLV > may be flooded domain-wide while the IP prefix may not. Hence both > advertisements would not come from the same router. > > == > > §security > > OLD: It prohibits a destination outside of the OSPF domain and also to > other routers within the domain. > > NEW: It prohibits a destination outside of the OSPF domain. > > === > > As a consequence, this slightly increases the capabilities and hence the > security implications. However, this still restricts the use of tunnel > whose destination is within the OSPF domain (i.e. not Internet wide) > which was your original concern. Plus IMO, assuming that an attacker can > control the OSPF advertisement is already a significant assumption. > > === > > Bottom line, I believe the change is quite small from a security > standpoint, but wanted to double check with you. > > Thanks, > > Best regards, > > --Bruno > >> -----Original Message----- > > > From: David Mandelberg [mailto:david@mandelberg.org] > > > Sent: Tuesday, September 19, 2017 6:24 PM > > > To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN; Robert Raszuk > > > Cc: iesg@ietf.org; draft-ietf-ospf-encapsulation-cap.all@ietf.org; > secdir@ietf.org > > > Subject: Re: secdir review of draft-ietf-ospf-encapsulation-cap-06 > > > > > > 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 > <mailto:robert@raszuk.net%20%3cmailto:robert@raszuk.net>>> > > > > Cc: The IESG <iesg@ietf.org <mailto:iesg@ietf.org > <mailto:iesg@ietf.org%20%3cmailto:iesg@ietf.org>>>, David Mandelberg > > > > <david@mandelberg.org <mailto:david@mandelberg.org > <mailto:david@mandelberg.org%20%3cmailto: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> > <mailto:secdir@ietf.org%20%3cmailto:secdir@ietf.org%3e>" <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 > <mailto:alias-bounces@ietf.org%20%3cmailto:alias-bounces@ietf.org>>> > > > > Resent-To: Xiaohu Xu <xuxiaohu@huawei.com > <mailto:xuxiaohu@huawei.com > <mailto:xuxiaohu@huawei.com%20%3cmailto: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 > <mailto:luay.jalil@verizon.com%20%3cmailto:luay.jalil@verizon.com>>>, > Acee Lindem > > > > <acee@cisco.com <mailto:acee@cisco.com > <mailto:acee@cisco.com%20%3cmailto:acee@cisco.com>>>, <akr@cisco.com > > > > <mailto:akr@cisco.com>>, <aretana@cisco.com > <mailto:aretana@cisco.com > <mailto:aretana@cisco.com%20%3cmailto:aretana@cisco.com>>>, > > > > Deborah Brungard <db3546@att.com <mailto:db3546@att.com > <mailto:db3546@att.com%20%3cmailto:db3546@att.com>>>, Alia Atlas > > > > <akatlas@gmail.com <mailto:akatlas@gmail.com > <mailto:akatlas@gmail.com%20%3cmailto:akatlas@gmail.com>>>, Acee Lindem > > > > <acee@cisco.com <mailto:acee@cisco.com > <mailto:acee@cisco.com%20%3cmailto: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> > <mailto:david@mandelberg.org%20%3cmailto:david@mandelberg.org%3e>] > > > > > Sent: Monday, September 18, 2017 9:30 PM > > > > > > > > > > On 09/18/2017 05:08 AM, bruno.decraene@orange.com > <mailto: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/ > > _________________________________________________________________________________________________________________________ > > 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/
- [secdir] secdir review of draft-ietf-ospf-encapsu… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… Robert Raszuk
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… Robert Raszuk
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-enc… Robert Raszuk
- Re: [secdir] secdir review of draft-ietf-ospf-enc… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-enc… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-ospf-enc… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-enc… David Mandelberg