Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 31 May 2019 13:00 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EDD1200B7; Fri, 31 May 2019 06:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 header.b=EAcwIb2K; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tfOlPj0s
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 iMuslXR-gCM8; Fri, 31 May 2019 06:00:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5A91200B4; Fri, 31 May 2019 06:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10600; q=dns/txt; s=iport; t=1559307642; x=1560517242; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+MBCrgNBLnsDnyynCfnng0doCu0oDEcmmTP+ToY9J8U=; b=EAcwIb2KjjQfvUawhcZgZgjjHZjLewGrqPBivHvhfC18d4x6t2+I1WKo 3TtOz5qCcge4b9wxvXFZ+/JVoqHZtpXEMyBeznfna5UQt82ESsST3Qpgg Dtb6cUANS5nrdisOU1RSv63BAn2Gxql6v4jnWvAQ+ggLhlUaWkSNrC5gH 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ahati9xDkI8xTMTM7XsrzUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuL/P2ZiomNM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAA1JPFc/5xdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPSQsA2lVIAQLKAqECoNHA4RSiiCCV36IRI1?= =?us-ascii?q?tgS4UgRADVAkBAQEMAQElCAIBAYRAAheCbSM0CQ4BAwEBBAEBAgEEbRwMhUo?= =?us-ascii?q?BAQEDARIRBA0MAQE3AQQHBAIBCA4DAQMBAQECAiYCAgIfERUCAwMIAgQOBQg?= =?us-ascii?q?agwGBagMODwEOnyMCgTiIX3F8M4J5AQEFgUZBgn0NC4IPAwaBDCgBi1UXgUA?= =?us-ascii?q?/gRFGghc1PoIaRwEBAQEBAYEqAQsHASGDCDKCJos7Eg6CDS2NFYxmJj4JAoI?= =?us-ascii?q?Nhj2JBwSDf4IhhnCMDYFGgx2QZYFfjS4CBAIEBQIOAQEFgU84RCNYEQhwFYM?= =?us-ascii?q?ngg8MFxSDOYUUhT4BcgGBKIsBDxeBCwGBIAEB?=
X-IronPort-AV: E=Sophos;i="5.60,535,1549929600"; d="scan'208";a="565827555"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 May 2019 13:00:40 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4VD0eZB023416 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 May 2019 13:00:40 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 May 2019 08:00:40 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 May 2019 08:00:39 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 May 2019 09:00:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+MBCrgNBLnsDnyynCfnng0doCu0oDEcmmTP+ToY9J8U=; b=tfOlPj0sVx/JDOuvdAPzcK97tcd4JNlCaGKC1uTCEflusvHEj7XtGTQDLt75GpsRUhMZSvSgUva2wY/0p8nWXRPdnyM5dVUQhjBimtKVqDgmdRq3EodL6ku3nc2riCqO3PpNgUsXHFAwOFimJQ8Jc5KMkhNofdfizqF5vz3qaq4=
Received: from DM5PR11MB2027.namprd11.prod.outlook.com (10.168.103.22) by DM5PR11MB1596.namprd11.prod.outlook.com (10.172.37.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.18; Fri, 31 May 2019 13:00:36 +0000
Received: from DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::1487:6a62:8e05:d2c4]) by DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::1487:6a62:8e05:d2c4%2]) with mapi id 15.20.1922.021; Fri, 31 May 2019 13:00:36 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org>, Susan Hares <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dC0xNTogKHdpdGggQ09N?= =?utf-8?Q?MENT)?=
Thread-Index: AQHVF5X22go988fAYUe/ihOetoND8KaFAdowgAAlLgCAAALKgA==
Date: Fri, 31 May 2019 13:00:36 +0000
Message-ID: <DM5PR11MB202746677BE08698B2F20A40C1190@DM5PR11MB2027.namprd11.prod.outlook.com>
References: <155929607688.6602.7399415179534572381.idtracker@ietfa.amsl.com> <DM5PR11MB2027F604F6C948C2A0A23B3FC1190@DM5PR11MB2027.namprd11.prod.outlook.com> <B32E5FE0-6B9D-4DCD-BF05-72025495972C@kuehlewind.net>
In-Reply-To: <B32E5FE0-6B9D-4DCD-BF05-72025495972C@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [72.163.220.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1562b491-48ce-409e-a9c4-08d6e5c7f9ac
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR11MB1596;
x-ms-traffictypediagnostic: DM5PR11MB1596:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR11MB1596050762EABF9F6A450DFEC1190@DM5PR11MB1596.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00540983E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(346002)(366004)(376002)(13464003)(199004)(189003)(446003)(33656002)(76176011)(224303003)(74316002)(3846002)(305945005)(316002)(102836004)(26005)(6116002)(53546011)(81166006)(11346002)(86362001)(476003)(486006)(7696005)(186003)(6506007)(66066001)(99286004)(256004)(14454004)(54906003)(6916009)(68736007)(2906002)(71190400001)(7736002)(53936002)(14444005)(66476007)(6246003)(73956011)(4326008)(9686003)(52536014)(66556008)(6306002)(71200400001)(478600001)(55016002)(25786009)(5660300002)(76116006)(229853002)(966005)(6436002)(81156014)(8936002)(66574012)(64756008)(66946007)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1596; H:DM5PR11MB2027.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cxZ5WynHRkft6dPn58MRHT9GozxMBN+98goEcF/6Ic0gr4TBgP1O1Qt8gluytrUxh0vKDiNB3J0ix9MwpIB8JS/r/HnmffQQ2QYJyg5kyIq3sLYnUuCTEeTck90smO5hkTfjlm7VQeS3SXkn2xJYFu4f8cSguw7ibH7DIV2B5WFyKNBBBTpMLkE7z0jjDJssiimnYt63HgXMtJen7NbiZfMDOuIUcfquT/oS99SDMgGYEkiHAC1QQyhMQQN5fE8tZNxnJVGzhLGY/u2tFH8k4imrIOwwU3Pc+xul6AUnnOHZ41tW1VVgkv7zSbwYpcyWfWxGk/DqqUU/7iSQOo+ZUt6TQJe3a8g0eAkrY9qBx7m6eFhxkCma3VDr4OgclrhnaHhQGRarX8uIfCzcTRI70BxroD047chK9XgTdA1j8Fs=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1562b491-48ce-409e-a9c4-08d6e5c7f9ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2019 13:00:36.7767 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ketant@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1596
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sT9Dxl3D73LI1Gz4a3R8MaAB_BY>
Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-idr-bgp-ls-segment-routing-ext-15=3A_=28with_COMMENT=29?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2019 13:00:46 -0000

Hi Mirja,

Please check inline below.

-----Original Message-----
From: Mirja Kuehlewind <ietf@kuehlewind.net> 
Sent: 31 May 2019 17:50
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org; Susan Hares <shares@ndzh.com>; aretana.ietf@gmail.com; idr-chairs@ietf.org; idr@ietf.org
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Hi Ketan,

There are two points that I think could be made more clear in the introduction: 

a) that the use case is e.g. "between multiple AS/domains within a single provider network” -> Talk about the need of trust between these domain would be good.

[KT] This document refers to RFC8402 for the SR Domain term (https://tools.ietf.org/html/rfc8402#section-2). The need for trust is also described in RFC8402 which we borrow (https://tools.ietf.org/html/rfc8402#section-8) by reference. However, RFC8402 goes more into the details of the high level architecture and more specific the data plane details. Hence, we've introduced the additional text in the Security Consideration sections of this document to extend it so as to cover BGP since BGP sessions are likely to be formed outside of this "single provide network". How about the following change to the last sentence in the Introduction section 1?

OLD
The SR domain may be comprised of a single AS or multiple ASes.
/OLD

NEW
SR operates within a trusted domain consisting of a single or multiple ASes managed by the same administrative entity e.g. within a single provider network.
/NEW

b) A warning about the consequences if these information lease the trusted domain.

[KT] Since the SR information that we are talking about is actually a subset of the IGP link-state information, the implications for it leaving the trusted domain are the same as explained in RFC7752 Security Considerations. Specifically, it has the following text that applies to this BGP-LS extensions as well (indicated by reference to RFC7752 in the Securities Consideration section 5).


   Additionally, it may be considered that the export of link-state and
   TE information as described in this document constitutes a risk to
   confidentiality of mission-critical or commercially sensitive
   information about the network.  


Hence, I didn't think of repeating the same.  How about if we change the following text in the Security Considerations section 5 though to make this more clear?

OLD
Therefore, precaution is necessary to ensure that the SR information advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain.
/OLD

NEW
Therefore, precaution is necessary to ensure that the link-state information (including SR information) advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain. 
/NEW

Thanks!
Mirja



> On 31. May 2019, at 12:35, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> 
> Hi Mirja,
> 
> Thanks for your review and your comments. 
> 
> Regarding your first comment, we have the following text in the Introduction section that describes the use-case/applicability that you are referring to in the Security Considerations.
> 
>   Segment Routing (SR) allows advertisement of single or multi-hop
>   paths.  The flooding scope for the IGP extensions for Segment routing
>   is IGP area-wide.  Consequently, the contents of a Link State
>   Database (LSDB) or a Traffic Engineering Database (TED) has the scope
>   of an IGP area and therefore, by using the IGP alone it is not enough
>   to construct segments across multiple IGP Area or AS boundaries.
> 
>   The flooding scope for the IGP extensions for Segment routing
>   is IGP area-wide.  Consequently, the contents of a Link State
>   Database (LSDB) or a Traffic Engineering Database (TED) has the scope
>   of an IGP area and therefore, by using the IGP alone it is not enough
>   to construct segments across multiple IGP Area or AS boundaries.
> 
>   This document describes extensions to BGP-LS to advertise the SR
>   information.  An external component (e.g., a controller) can collect
>   SR information from across an SR domain (as described in [RFC8402])
>   and construct the end-to-end path (with its associated SIDs) that
>   need to be applied to an incoming packet to achieve the desired end-
>   to-end forwarding.  The SR domain may be comprised of a single AS or
>   multiple ASes.
> 
> Please let know any suggestions for the same or anything that needs further elaboration.
> 
> I will let Sue clarify on the shepherd's report. My impression was that many of the concerns raised were not specific to this particular BGP-LS extension but in general on BGP-LS itself. There has been a lot of discussions in the WG on this topic and work is ongoing to address some of those challenges based on our experience with BGP-LS deployments. One such effort is draft-ketant-idr-rfc7752bis. That said, all concerns raised specifically on this BGP-LS extension during the WGLC and follow-on reviews have been addressed AFAIK to achieve consensus.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Mirja Kühlewind via Datatracker <noreply@ietf.org> 
> Sent: 31 May 2019 15:18
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org; Susan Hares <shares@ndzh.com>; aretana.ietf@gmail.com; idr-chairs@ietf.org; shares@ndzh.com; idr@ietf.org
> Subject: Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-idr-bgp-ls-segment-routing-ext-15: No Objection
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> There is the following statement on the applicability of this approach in the security consideration section:
> 
> “The SR traffic engineering
>   policies using the SIDs advertised via BGP-LS are expected to be used
>   entirely within this trusted SR domain (e.g. between multiple AS/
>   domains within a single provider network).  Therefore, precaution is
>   necessary to ensure that the SR information advertised via BGP-LS
>   sessions is limited to consumers in a secure manner within this
>   trusted SR domain.”
> 
> As this is every essential to the scope of the document I would like to see this earlier in the document, e.g. in the intro, and own applicability section, or even in the abstract.
> 
> One additional comment on the shepherd write-up:
> I find the write-up a bit confusing but I assume that this document has wg consensus, even though it might be rough. There is a request to the IESG to make a judgment if this approach should be taken forward in general. However, if there are no technical or security concerns here and there is wg consensus, I don’t think I understand this request; expect this is not seen as covered by the charter, however, I don’t think this is indicated in the shepherd write-up.
> 
>