Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

John Scudder <jgs@juniper.net> Fri, 11 December 2020 15:43 UTC

Return-Path: <jgs@juniper.net>
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 1DE8E3A0E0E; Fri, 11 Dec 2020 07:43:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=KTkxVnJb; dkim=pass (1024-bit key) header.d=juniper.net header.b=U60Z3s0B
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 bnY0k5_1bCIm; Fri, 11 Dec 2020 07:43:56 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665B13A0E5B; Fri, 11 Dec 2020 07:43:40 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BBFa714017420; Fri, 11 Dec 2020 07:43:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=y/rrYygZm3Y4nO7uVX5cZ+m71lRX1uP7yZD8M/961Fk=; b=KTkxVnJbx6VrERT4feMoS+ptFgzf2L3LKQkpxefTmZltOddRtF3uESIeW/Fl+efpmm6K CvarrBiv6ZpiCbxSYlWtry2mclSJgtpZhnlTKjsdwDL9YQvlcso+E4SenBuaDIglqddB I+wyCQ8OPd3FOotVAX3/aZSvrFVAC3N8pb9fvZsPa6xSJ188aYDE0sdBYw0DW3MK1cIA KgsWPVHQZOQBOXMQks5oZ8PvNOVmzlYQaYfavzF3MNE8wSlOHzqvYZWB1vIWKtpU1vc7 IW+K5WEJCZ/NhXKMSo/+azLK1VE3ASqb7BQP5kECgLIvKcMKlLGTNysfIDLsWUmJgeHY gA==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2107.outbound.protection.outlook.com [104.47.58.107]) by mx0a-00273201.pphosted.com with ESMTP id 35axtt4ed6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 07:43:39 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PBhPslJvWLObaGbls77erqanab/0xR0T+o/Xx3L2DiAd3/QPZUjBST0G78udk4euO/6DomsMp9KflxvFFdot5ULbqvqGeV1kdVnGH/TcT627IeBZrphE494kqQ1n6oMvvZsf1M7lkVzuvy0WODZf1Kn06LgLg+oG34amHLaxgIYo3u5b6U7CIY52n9bV5FM0+Ha/UaCbkxEFrK33fhOColG8uZ0KeamNX29i6KsDGlYeePTaogb63LCA737AHw0G0tQVRZLNY5h91BwIl8ArJmtmvipw1iGmq/aZS+EGkOiqQRWQx8qPQERW40+aPPGtyZeBrwSpgXtn/muZtR5EEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y/rrYygZm3Y4nO7uVX5cZ+m71lRX1uP7yZD8M/961Fk=; b=YL139RKFQv1rr2imTa0p4pRRmDXM0E06ftbsIR3JC1uPfDAjawcLkZeH7BiaJLJCzkVEST6VPiSqc89Tti1D3jy08R/cQLaDPDHhiRG5cupX1MpnY9Khqj8afxus5KZ8po0r1mH/JJmH0oDGLp8oa3ugnwoG78iMf49H32g2GiEd4i46FE3WqBvSazoMk6nCe1Lr5fdqULtrnCqrV0i6ewCKrufVEIpj0bwqNb9aTQiq/IbL6u+a/mrgge10AaKxnmcDvJhfC23OP20H9ZR8ip564mjzc+OmK08zK19bBiPhv73uTqGdpkAl0EQKqjJe7oMQ8sQe++EsH5qkAZaKpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y/rrYygZm3Y4nO7uVX5cZ+m71lRX1uP7yZD8M/961Fk=; b=U60Z3s0BPYqFZxiUOpJIz3yLBN1MbjQfvaZxbHbh7JZ3vV5YlyAjATRfQ8q6yuXTTt/6VvzNmv93V0P7rvt5TtxAFIMyndtQZDdICxpO+8vSw1edfF1f1+Bj/Yo6HwZIMFd8s1CmyShZkE8YttSloJyKmDChpoHh3DorIHs31Q8=
Received: from BN8PR05MB6098.namprd05.prod.outlook.com (2603:10b6:408:45::29) by BN7PR05MB4418.namprd05.prod.outlook.com (2603:10b6:406:f5::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.11; Fri, 11 Dec 2020 15:43:36 +0000
Received: from BN8PR05MB6098.namprd05.prod.outlook.com ([fe80::e1b6:748b:a75e:172c]) by BN8PR05MB6098.namprd05.prod.outlook.com ([fe80::e1b6:748b:a75e:172c%3]) with mapi id 15.20.3654.016; Fri, 11 Dec 2020 15:43:36 +0000
From: John Scudder <jgs@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, Hares Susan <shares@ndzh.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
Thread-Index: AQHWyA5X6afyebyui0SmqWUAtjHoCanmK1IAgAA7eICAC7GtAA==
Date: Fri, 11 Dec 2020 15:43:36 +0000
Message-ID: <57157343-384E-4939-AE9E-580D9A308E27@juniper.net>
References: <160684669488.21585.5180075052177708759@ietfa.amsl.com> <9456ACB8-D843-41CD-9178-DBA0EA1D8EA7@juniper.net> <20201204050806.GR64351@kduck.mit.edu>
In-Reply-To: <20201204050806.GR64351@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c00d7f78-a401-4322-55f2-08d89deb8612
x-ms-traffictypediagnostic: BN7PR05MB4418:
x-microsoft-antispam-prvs: <BN7PR05MB441830699F9A24893381DFC0AACA0@BN7PR05MB4418.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G0m7IT8vrNNqGbr8AqgwQyRX6lZBi2fMq1hrs+gILw/J+O93xftYfxEaBORnAfq8Ij2sJQwrMnT59B9atT7NrDSNp3XpRYBhpimqAMkj3Q0kFQKVIWQtoY/GOmn1Fo0Xudd4DksSTPyihgq/aZJzeOl3Dqjh9jAJauX7IUNlDsSwfZ2pfr/mSCqnJ8Zckh/XVSksyLjxfugIyipsV37k1V8BA/D9jsgyCaMZj3rOo16k5Twgr9wTYtViRH4h1DdPpD1z8JC2hEZJzIkjHOcQgc5ENcaD34G9vTB/359sE1L/6UBzcp0VvQdOr1B6Ztdn+oSD3rhkX8kUEG2m80Mfa/+gKPxKeEP6m1hVmg5H+7TUF4cNl7RRRfhmV8qvIU/t
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR05MB6098.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(346002)(186003)(6512007)(8676002)(26005)(54906003)(64756008)(53546011)(66446008)(6486002)(83380400001)(2906002)(2616005)(36756003)(91956017)(66476007)(6916009)(66556008)(5660300002)(76116006)(33656002)(66946007)(8936002)(71200400001)(4326008)(86362001)(6506007)(508600001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?YTRHcXNCbjR2NklZY3JHVlRkRlRCeFRXa2NEYzg1Q3hDNGtDSmFERnR5aTFr?= =?utf-8?B?TGdVQ0lMdm0vbFdrajc2KzUwT0xGK0F6ZjhkWHI2cTluY1k4VEk5bEpjRmYv?= =?utf-8?B?aUF1VXVtakQyTzB6NzdINVRuRkU3bVRzTzVPa2lyZ29JM1ZHZDN2ZlNTY3FX?= =?utf-8?B?MXN0SjY1akJuNjhZbW5yTnMrRG9yejdoeVZvYldMN2JoQ2VmSWU2NDlrQVhF?= =?utf-8?B?bGtORVQwOERFbnRXeTUxZWRialRFM014dCtBRE5MbTlrU2h1ZHpwaXNXdGZH?= =?utf-8?B?R1ovenJsYURxV2ExSGg4YStHUmh6d3VRWWRqWWxXaG5aQnlTNHFiTGtueERa?= =?utf-8?B?Vkg1MGdVSk5KbFRheTJPVWIzbkVITmd1bXhsK2hqZGYwNHBQOERuQ0FUWEZK?= =?utf-8?B?ZEpDcjBXV2RlWWNYa0NSdXpaeVBTVk9aT2d6RENwdHMxWUwyZGtjVWFwVHlM?= =?utf-8?B?eEI4QkZEMlRPamluODEyYWRMUWx4d3RhYlVaVzFHbWlxRTYydXYyNDVoK2RU?= =?utf-8?B?TzdYb2JJS3RpbzlIMGVCZUEvbmgzcmovQmZjZWJpVDZDLzBDWmdqbkxsNlFx?= =?utf-8?B?UFlyNWN4WjZ6Y1FYd3JTTTl3eWJVQkpaV1VIZC9Cb3hvcEtPUUxnVDdXOHdo?= =?utf-8?B?QTBScm9OdUJ6UkJuVWY3MnFmMFRCZEFlU1k5ejFIaUppbER2NytSUEl6T3F4?= =?utf-8?B?L2VETE52VDFtWUxrMTV4UVpoNDVzaDVQdERFYUhkL1VBb013UktyWlRqNW5D?= =?utf-8?B?MVNONkJmbmlnak5Pdmp4Y1lKU1RwUW54c3Y3MS9iVW90bHlDZTJvSGFyVHRj?= =?utf-8?B?M29KS2pmMnRwK21CVkJBUDZYMktBU00xV0hETWY5czhldE1mUlZrOWtKOU1j?= =?utf-8?B?cVE2UGwvK2psSmtWVXN6YzNOeGNwclY1aUMyV0NJZGJ5SmVCWS9ITUlXcFkv?= =?utf-8?B?eURVQ2t2STRPYUJWRGtwT08ydVVYV0xSUnlWTGFLd3NoTzE4OGV0eUNrRG9w?= =?utf-8?B?Mzk0YnZpMWg3WnNkbWZNUjJYM1g4eTZIaGpqcElZY1VEVE8rN0VMMHhIbHQy?= =?utf-8?B?eDdIQmpuOEt5c09LWUxSdkZBem0xQ0xOMTM0OW9KU3ZJZ2UzWEN0Z0pGc1dr?= =?utf-8?B?T296T1lqaWxKcnEvdW1SVEg1UUZZbDR5QnVRRDBiYkNvN2lqMEdXRHJHWFVR?= =?utf-8?B?N2pBU3FtcmZ0Q2ZYNHRqdElJY2ExcnYrVUkrZmxZdTZnNForajVyQXBiT1hk?= =?utf-8?B?Z0M0am82RnNVL3dxb0pBUlNlSEtFWG1lQWV6dGlJRHhmWjhIeDFHV09KQlpp?= =?utf-8?Q?eJ6BdnIWeehSOZvKFXCJ+8e8dPR8dLICj8?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_57157343384E4939AE9E580D9A308E27junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN8PR05MB6098.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c00d7f78-a401-4322-55f2-08d89deb8612
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 15:43:36.4459 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sE32V6o/A/Sr1N1iZhKR09gEoJZkcXd7PTyizu5SU8FOR12bwt5UxJvdDN8GDytW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4418
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-11_03:2020-12-11, 2020-12-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 spamscore=0 malwarescore=0 mlxscore=0 adultscore=0 suspectscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012110103
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fAn-sRanNG02O16FuMt9svE-Lv0>
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
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, 11 Dec 2020 15:44:06 -0000

Hi Ben,

In this reply I’ll just address your open Discuss:

On Dec 4, 2020, at 12:08 AM, Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Erik's discuss.

I see that Roman has already suggested adding normative language
regarding the limitation to a single administrative domain (in addition
to the "MUST filter by default for EBGP sessions"), which I agree with.
However, I think there is an additional consideration regarding the
limitation of use to a single administrative domain, wherein the domain
of use for the tunnel encapsulation attribute may diverge from the
domain of use of segment routing, that seems to place this document in
conflict with the requirements of RFC 8402.  In particular,
RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter
any external traffic", and additionally for SRv6 that "explicit routing
information MUST NOT be leaked through the boundaries of the
administrered domain".  In §3.7 of this document, though, we find that
for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be
in the same Segment Routing Domain as the tunnel's egress endpoint, and
there is no implication that the prefix-SID for the advertised prefix is
the same in the Segment Routing domains of the BGP speaker that
originated the sub-TLV and the BGP speaker that received it", which
seems to suggest violation of the RFC 8402 requirement.  I think we need
to have greater clarity on what relationship is actually intended
between the SR domain and the tunnel encapsulation usage domain, and if
they are to diverge, we need to both somehow rectify this behavior with
RFC 8402 and to very clearly document how the 8402-mandated filtering at
the SR domain boundary is supposed to happen when the boundary includes
tunneled traffic.

We’ll respond to this later, I need to discuss it with my coauthors and didn’t want to hold up the rest of the response any longer than I have.

Sounds good.  I am not surprised that this one is going to require more
discussion; it seems like a tricky task to figure out the right thing to
do.

We did a review of RFC 8402’s definition of an “SR domain”. Here’s 8402, from the Terminology section, emphasis added:


   Segment Routing domain (SR domain): the set of nodes participating in
   the source-based routing model.  These nodes may be connected to the
   same physical infrastructure (e.g., a Service Provider's network).
   They may as well be remotely connected to each other (e.g., an
   enterprise VPN or an overlay).  If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a network.  However, some deployments may wish to
   subdivide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR domain are managed by the same administrative entity.


Other parts of 8402 imply other properties of an SR domain. One is that all the participating routers share a Prefix-SID namespace (this is my interpretation, not the wording of 8402), another is the text in Section 8.1 you quote above, about filtering external traffic.

The text that bothered you in tunnel-encaps (“need not even be in the same Segment Routing Domain”) was directed only toward the namespace aspect: the two ends of the tunnel may be using different prefix-SID namespaces. But as we see above, the namespace isn’t a defining attribute of the SR domain. So, I think the best way forward is to strike the offending text from tunnel-encaps. The paragraph stands just as well (arguably better) without it:


   The Prefix-SID sub-TLV has slightly different semantics than the
   Prefix-SID attribute.  When the Prefix-SID attribute is attached to a
   given route, the BGP speaker that originally attached the attribute
   is expected to be in the same Segment Routing domain as the BGP
   speakers who receive the route with the attached attribute.  The
   Label-Index tells the receiving BGP speakers what the prefix-SID is
   for the advertised prefix in that Segment Routing domain.  When the

   Prefix-SID sub-TLV is used, the receiving BGP speaker need not even


   be in the same Segment Routing Domain as the tunnel's egress
   endpoint, and there is no implication that the prefix-SID for the
   advertised prefix is the same in the Segment Routing domains of the
   BGP speaker that originated the sub-TLV and the BGP speaker that
   received it.


We’d also add something like the following to the Security Considerations section:


   RFC 8402 specifies that "SR domain boundary routers MUST filter any
   external traffic" ([RFC 8402] Section 8.1). For these purposes,
   traffic introduced into a SR domain using the Prefix-SID sub-TLV lies
   within the SR domain, even though the prefix-SIDs used by the routers
   at the two ends of the tunnel may be different, as discussed in
   Section 3.7. This implies that the duty to filter external traffic
   extends to all routers participating in such tunnels.


What do you think?

Thanks,

—John