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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 19 September 2017 11:01 UTC

Return-Path: <acee@cisco.com>
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 3EFE11320CF; Tue, 19 Sep 2017 04:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4n4g3yq9b6tx; Tue, 19 Sep 2017 04:01:47 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30DB132055; Tue, 19 Sep 2017 04:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30471; q=dns/txt; s=iport; t=1505818906; x=1507028506; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l3RkUWC6dU4GQvGOapYG+T4I21HJa7eyQ1Zg/P9RcXE=; b=QWGOKXtFmBqo2y04vKQjlCpHXBGuc7BJlEHCgo1oZMe5/0A3DchqEIUq A/t3F/mZT5Qptzo7KaZp3RGY34A678gUa3/vIWoYTd/Snn2i5AhdYvez4 EgWlPxt+G6M0LBZ3+TOGpg1iNFRgKeCyAlfejitcD6CwFtlaRL/Ukf9l9 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAQAV+MBZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG4nB4NunAt5h0KNeIIECh+BYoM6AhqEO0MUAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQMBIwo/DQULAgEIEQMBAQEBJwMCAgIfERQJCAIEAQ0FiU9MAw0Iq?= =?us-ascii?q?XmCJ4c8DYNfAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDK4ICgzOCG1g1gliBbQE?= =?us-ascii?q?LBwE2CQwKgl2CYAWgTzwCh1qIA4R3ghOFaoN+hn6KAIJciC4CERkBgTgBNiGBA?= =?us-ascii?q?gt3FYViHIFndoYaDxeBDIEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208,217";a="300237085"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Sep 2017 11:01:45 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8JB1igr002335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 11:01:45 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 07:01:44 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 07:01:44 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Robert Raszuk <robert@raszuk.net>
CC: "iesg@ietf.org" <iesg@ietf.org>, David Mandelberg <david@mandelberg.org>, "draft-ietf-ospf-encapsulation-cap.all@ietf.org" <draft-ietf-ospf-encapsulation-cap.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTHpv/cOgvm+rnt0qxeBuvpFWeWaK0xaZggAAJ/YCAANdoUIAFhL03gADEpyCAAE2vAIAABocA///rcYA=
Date: Tue, 19 Sep 2017 11:01:43 +0000
Message-ID: <D5E66FC2.C878E%acee@cisco.com>
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>
In-Reply-To: <27250_1505808909_59C0D20D_27250_468_2_53C29892C857584299CBF5D05346208A4787AEEC@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_D5E66FC2C878Eaceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/b4uVGNYB8kdcZ6jj3RjmFxrmcME>
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 11:01:52 -0000

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.