Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Fri, 08 January 2021 22:46 UTC
Return-Path: <aretana.ietf@gmail.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 14AB03A1358; Fri, 8 Jan 2021 14:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=gmail.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 phDySuNrX7BL; Fri, 8 Jan 2021 14:46:32 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 CC37A3A1357; Fri, 8 Jan 2021 14:46:31 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id r5so12696631eda.12; Fri, 08 Jan 2021 14:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=kwYlD26SbuowaNfhf4u8sXCGJDUosbMqfLlzRzNg7SQ=; b=jIjHMvQPaBj6i87ZHYy7UmLu7Xlu+61aJCL5+oGrVszZszGDq3W0M3u3MtaLhtmPA9 QCsSZ4Cz4Ga0TWJptrZ1bd3BRjkLnluB5IkLeayExVX8VxAKEGDw01jZd0u4yCrLeloq eYG0LbQtFlTJTxsE7hMhI1YGb4MgBLmy6AEtHXxY9XeoLhl1f7bBgmFPXElMWEiFJOxy G2DZwRxIhKfyHXCOOYHnq1eVrxExlh+Til1+cOBXn+sw5CHohxxydhrotj0cf8vE4TYw sb7cSC2758qGlWMzKDgLW1kGSLxixYiB07YBplhgNiRzqOGaCYpytqSNCpOxisssUrCo Wo5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=kwYlD26SbuowaNfhf4u8sXCGJDUosbMqfLlzRzNg7SQ=; b=alXrEnXfyj/O55NtKUd3dSJHav7b199VEV/J1HYzyaDypj1028vY7M8zhzN4CA/FRA M0ORuL1EA8di6rf954Afa8GSY2okbVN/z8MDliL0XILF/FciJE8TJ0+A4lFPGd5PBflM PJVVfjqZ8/+E0WMKgfM0KSO9btdW7knLJAvOjc1+orYd1//zGbPAB/HsCaSH94pjdc0G FHf27kXPlp45/drfuW4I29O8ymjmwfbriDRda7x4hK95JaXI1KMClaKivra32/hclkuX +FbIxyJCTMtFV79AOwrPrZ0wANi8WUyE8bPYlN1KE5WCyRHw3+NCSacxsM23TX0NUg26 lvEQ==
X-Gm-Message-State: AOAM532FpLLyrNWPO950JGjFofJ+UIZPGx07RYcoTKw2EjkDW3kWftHw eaFfxs6jmEeorVrs8J0IyqGniiUAixt+1P6bvxw=
X-Google-Smtp-Source: ABdhPJzi8RpCWH+FLvE+mLErcVw6chugfylMAUn7U7gBsS40CCYHrlP8E7ejYO6PZ1Qyc0b3OT5ThGcf4BNjjU61yNQ=
X-Received: by 2002:aa7:da03:: with SMTP id r3mr6703549eds.155.1610145990164; Fri, 08 Jan 2021 14:46:30 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Jan 2021 17:46:29 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESszENfB0Vo-8tWaaauz3fL3Mx00QZhPrEv7kVqrNEJs1NA@mail.gmail.com>
References: <160684669488.21585.5180075052177708759@ietfa.amsl.com> <9456ACB8-D843-41CD-9178-DBA0EA1D8EA7@juniper.net> <20201204050806.GR64351@kduck.mit.edu> <57157343-384E-4939-AE9E-580D9A308E27@juniper.net> <CAMMESszENfB0Vo-8tWaaauz3fL3Mx00QZhPrEv7kVqrNEJs1NA@mail.gmail.com>
MIME-Version: 1.0
Date: Fri, 08 Jan 2021 17:46:29 -0500
Message-ID: <CAMMESsyukYq1iYiMB7yRmh=SGbmBdJSvohLs9SaOtmCJk_72jQ@mail.gmail.com>
To: John Scudder <jgs@juniper.net>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Hares Susan <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7c30705b86b5315"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1ksmdoTPn_TZ7N-vaq9Wn-bYSn8>
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, 08 Jan 2021 22:46:34 -0000
Ben: Hi! The proposed changes are reflected in -22. Please take a look. Thanks! Alvaro. On December 17, 2020 at 4:45:23 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote: Ben: Hi! Any thoughts on this? Thanks! Alvaro. On December 11, 2020 at 10:43:40 AM, John Scudder (jgs@juniper.net) wrote: 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> 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
- [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-… Benjamin Kaduk via Datatracker
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Susan Hares
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Susan Hares
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Alvaro Retana
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Alvaro Retana
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Susan Hares
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… John Scudder
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… John Scudder
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Alvaro Retana
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Alvaro Retana
- Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk