Re: [Idr] AD Review of draft-ietf-idr-bgp-open-policy-15
Alvaro Retana <aretana.ietf@gmail.com> Wed, 18 August 2021 16:01 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 5F7963A200C; Wed, 18 Aug 2021 09:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 BW_wjZjswU6O; Wed, 18 Aug 2021 09:01:29 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 C35543A2004; Wed, 18 Aug 2021 09:01:28 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id dj8so3938057edb.2; Wed, 18 Aug 2021 09:01:28 -0700 (PDT)
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:content-transfer-encoding; bh=Ymgw16TrgfPg+pWrnPG00A1Cvj+7kwBeLrv+0JTVg+c=; b=S0Y6yj7vbNOT26Cvj3U4i7f86lPgEpXng7ibCBzMPGBXSsoyh4p1vGgzkk4G1kni83 FNtwtkm3Ap/SUvAVwGUHpvueX/tmy9AYfMsl8glQG0FrChp6JA27Vmn9x07+R6IE9fKx QDCxDDBSliCy+1jxLQfxUVa5jVm0LFd6EfBH8Ju94m7yeGtZ4XYeUR3Zv+1bDhdaKkNR w9OGyuRfOWdkITuf3yJrn6qklSAKN6KbGJfdrqwD6dzbiJULK9ZutJeuRZsPSCYyuYru fxrKsKoY/ryDBtLG/BL+L+ryZK6nKkmL0oWauzIa4EjNu1ATGfclTX6EBHTH6kxgR9er YRMg==
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:content-transfer-encoding; bh=Ymgw16TrgfPg+pWrnPG00A1Cvj+7kwBeLrv+0JTVg+c=; b=p7C+abW2SgPbeWLDwKfsK0PuvppOMyEd+V4U5SJzHlDFKBHO14DykCuVu4pu9Q/oH8 diuPYPo7g+40Umsr3HmIMx4SHL0zR4sVWsUPoZEAzP2QM/AOoDDbNwFhMJ5zf8tHpxir KyM/hQ23f5u1cuP7chZmTapJgWiUAD42SAUniWQkHuX6Jjd3fdkYUH48TpFFQ+ssiHit TnNT9aP66aWUBa12udMEc2i/EG/PjF5QBzlYNmHaCCGoh3b18QSMqNFiLNsfdF4Uadjj unMvTu5bTbRDCGwhcNfSFtU4k11pKonNNlapfRPCMKIzqeKCwmpPdOxna1Ng2XR/+Bfj SXhw==
X-Gm-Message-State: AOAM531ZbU8Ww2nvQW9Ohu2fUrKWb9DltV1WDLP0s145CpykNg0E8Vz3 r5aoKWRMsyko+w7v5+EgJaIocOrysUAQA+0LWgM=
X-Google-Smtp-Source: ABdhPJwGOmOOxzBP/L1Vj3fkox9xEBn8YrwROlim2YoVnhnbAq5p9OJ8RnlbQiSvjPq04vL/EkB32eMsPJ0/2ROeH9I=
X-Received: by 2002:a05:6402:2889:: with SMTP id eg9mr11226655edb.38.1629302486169; Wed, 18 Aug 2021 09:01:26 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 18 Aug 2021 09:01:25 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAEGSd=BhdHbrh3unLXZOJtoUU+6gkPfH9fiHkkSrgCA4XKpffw@mail.gmail.com>
References: <CAMMESszyrdFsaYYtvTo_0jHnsWGsbc-0aSthUi7pmNUt+U+GsA@mail.gmail.com> <CAEGSd=BqtM8=DtWUbrk0t7dkwhuvOvhhsGu8ozHmriqJNs5Cvw@mail.gmail.com> <CAMMESsz7g1agqGVomHUyL83k3enhJ8uYaNPoUwtAG+CADxDfmg@mail.gmail.com> <CAEGSd=BhdHbrh3unLXZOJtoUU+6gkPfH9fiHkkSrgCA4XKpffw@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 18 Aug 2021 09:01:25 -0700
Message-ID: <CAMMESsyR2grTniKhfiozKX4QSW2=nrP=y0TLwZb9oa-DYb7=3g@mail.gmail.com>
To: Alexander Azimov <a.e.azimov@gmail.com>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Susan Hares <shares@ndzh.com>
Cc: draft-ietf-idr-bgp-open-policy@ietf.org, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "grow@ietf.org grow@ietf.org" <grow@ietf.org>, IDR List <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bU5E4jYi7Bmcg0iQ-1embIMkxlg>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-open-policy-15
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: Wed, 18 Aug 2021 16:01:37 -0000
On August 10, 2021 at 12:23:09 PM, Alexander Azimov wrote: Alexander/Sriram: The document as improved significantly! Thank you for the hard work!! I have just a couple of responses inline, and have appended a quick review of -16. In general, most of the remaining items should be easy to address. The only significant issue I want to discuss some more is related to confederations (see below). All these comments can be considered last call comments. > Instead of returning the document to the WG, and because it is short, > I am including a long list of suggestions below. Given all the > proposed changes, we will eventually need to run a new WGLC explicitly > including the grow WG -- I have cc'd them in this message as well. Sue: Please issue a WGLC (cc'ing grow) for this document. A week should be enough. Once the WGLC is done and we have an updated document I will start the IETF LC. Thanks! Alvaro. ... > 124 2. Peering Relationships ... > [major] "MUST NOT send...prefixes learned from..." Again, given that > the roles are session-based, how do you expect this requirement to be > satisfied? IOW, how would an eBGP session in routerA know that a > specific prefix was learned from a Peer (or not) at routerB on the > other side of the network? > [AA/KS] There are some details that need to be understood. If a route was [AA/KS] advertised by a Peer, Provider, or RS and it is not marked with OTC, [AA/KS] then the ingress router adds an OTC Attribute with the AS number of [AA/KS] the sender (remote AS). See revised Section 4. The mere presence of [AA/KS] an OTC indicates to the egress router that the route was learned from [AA/KS] a Peer, Provider, or RS and it can be advertised only to customers. [AA/KS] The absence of an OTC Attribute indicates to the egress router that [AA/KS] the route was either advertised by a Customer or originated by the [AA/KS] local AS. If a route received from a Customer at an ingress router has [AA/KS] an OTC Attribute, then the route is rejected by ingress policy. So, a [AA/KS] customer route or a locally originated route never has OTC attached [AA/KS] when received at the egress router. Now, this is explained well in the [AA/KS] revised Section 4 in the updated draft. Please add something like that (shorter) to §2. Suggestion> As specified in §4, the Only to Customer (OTC) Attribute is used to identify all the routes in the AS that have been received from a Peer, Provider or RS. ... > What about confederations? I understand the intent here is to prevent > leaks in the Internet, so a private ASN shouldn't show up there. §5 > hints at the BGP Role Capability being applicable only to eBGP, but it > doesn't normatively constrain it to "normal" eBGP sessions. Should > it? I think it should. If you do too, what should a receiver do if > the Capability is received over iBGP or an eBGP session that is not > "normal" -- ignore sounds like a good thing. > [AA/KS] Yes, “ignore” -- meaning do not act on it and let the OTC Attribute [AA/KS] propagate -- seems correct. IMO, the OTC processing at the ingress/ [AA/KS] egress of the confederation will happen correctly as per this draft [AA/KS] (RFC). So, nothing specific to confederations needs to be said. [AA/KS] Please advise. The question is this: §4 says (talking about egress policy) that "an OTC Attribute MUST be added with a value equal to the AS number of the local AS". Should a router that sends an UPDATE to a member of the confederation in a different ASN include the OTC? Note that rfc5065 says this: A member of a BGP confederation MUST use its Member-AS Number in all transactions with peers that are members of the same confederation as the local BGP speaker. ...and rfc4271 defines eBGP simply as: A peer in a different AS is referred to as an external peer, while a peer in the same AS is referred to as an internal peer. Internal BGP and external BGP are commonly abbreviated as IBGP and EBGP. So, if a confederation peer is in a different ASN, then it is an eBGP peer. The egress policy should then result in an OTC with the a Member-ASN. Which results in the route not being propagated to a Provider (assuming the confederation is a Customer). If the OTC is ignored (as suggested above) and the route is advertised to the Provider, who will not use the route anyway because it has an OTC. This assumes that the intra-confederation eBGP sessions are configured to use BGP Roles. Yes, I think this won't be too common...but it could happen. Thinking out loud -- I see a couple of possibilities: 1- Say that the rules in §4 don't apply if there is a private ASN in it. But this cconstrains other applications, specially ones where the Customer doesn't have its own ASN. 2- Require that any OTCs added inside a confederation be removed before a route is advertised externally. This path is against this text: Once the OTC Attribute has been set, it MUST be preserved unchanged. Suggestion> A BGP speaker that advertises a route to a BGP speaker located in a neighboring autonomous system that is not a member of the local confederation [rfc5065] MUST remove any OTC Attributes whose value matches an ASN in the removed AS_CONFED_SEQUENCE or AS_CONFED_SET in the AS_PATH. Otherwise, the OTC Attribute MUST be preserved unchanged. rfc5065 would need to be a Normative reference. [End Comments -15] [Start of Review -16] [Line numbers from idnits.] ... 124 1.1. Terminology 126 In the rest of this document, the term "Peer" is used to refer to a 127 "lateral peer" for simplicity. Also, the terms Provider and Customer 128 are used to refer to a transit provider and a transit customer, 129 respectively. Further, the terms RS and RS-Client are used to refer 130 to a Route Server and its client, respectively. [major] "lateral peer" is used in several places but not explicitly defined. What is a lateral peer? How is it different from a "regular" peer? I looked at rfc7909 but couldn't find an explicit definition there either -- did I miss it? If so, then there's no need to add anything else. :-) ... 173 3. BGP Role 175 The BGP Role characterizes the relationship between the eBGP speakers 176 forming a session. BGP Role is configured on a per-session basis. 177 An eBGP speaker SHOULD configure the BGP Role locally based on the 178 local AS's knowledge of its Role. The only exception is when the 179 eBGP connection is complex (see Section 5). BGP Roles are mutually 180 confirmed using the BGP Role Capability (described in Section 3.1) on 181 each eBGP session between autonomous systems (ASes). One of the 182 Roles described below SHOULD be configured at the local AS for each 183 eBGP session with a neighbor (remote AS) (see definitions in 184 Section 1.1). [minor] There's some redundant text... Suggestion> The BGP Role characterizes the relationship between the eBGP speakers forming a session. One of the Roles described below SHOULD be configured at the local AS for each eBGP session (see definitions in Section 1.1) based on the local AS's knowledge of its Role. The only exception is when the eBGP connection is 'complex' (see Section 5). BGP Roles are mutually confirmed using the BGP Role Capability (described in Section 3.1) on each eBGP session. ... 227 3.2. Role Correctness ... 251 If the BGP Role Capability is sent, but one is not received, then the 252 connection MAY be rejected using the Role Mismatch Notification (code 253 2, subcode 8); this mode of operation is called the "strict mode". 254 For backward compatibility, if the BGP speaker does not receive the 255 capability from its peer, it SHOULD ignore the absence of BGP Role 256 Capability and proceed with session establishment; this SHOULD be the 257 default non-strict mode of operation. In this case, the locally 258 configured BGP Role is used for the procedures described in 259 Section 4. [major] "strict mode" The text is not strict about "strict mode": rejecting the session is optional. You also added this text to the Security Considerations: Setting the strict mode of operation for BGP Role negotiation as the default may result in a situation where the eBGP session will not come up after a software update. Such an implementation of this document is strongly discouraged. Even if strict mode is not the default, configuring it may still result in the same problem. If discouraged then why even talk about it? Suggestion> For backward compatibility, if the BGP Role Capability is sent but one is not received, the BGP Speaker SHOULD ignore the absence of the BGP Role Capability and proceed with session establishment. The locally configured BGP Role is used for the procedures described in Section 4. ... later on in the security section ... Strictly requiring the presence of the BGP Role Capability may result in a situation where the eBGP session will not come up after a software update or configuration change. Such an implementation of this document is strongly discouraged. Note that this suggestion simplifies the text (no more "MAY...strict" "contradiction") while not changing the functionality. If the strict requirement is not good, is there a reason to not always require the backwards compatible behavior? If implementations already reset sessions then I guess we can keep the "SHOULD". 261 If an eBGP speaker receives multiple but identical BGP Role 262 Capabilities with the same value in each, then the speaker MUST 263 consider it to be a single BGP Role Capability and proceed [RFC5492]. 264 If multiple BGP Role Capabilities are received and not all of them 265 have the same value, then the BGP speaker MUST reject the connection 266 using the Role Mismatch Notification (code 2, subcode 8). [major] s/the speaker MUST...[RFC5492]/the speaker must...[RFC5492] This behavior is already specified in rfc5492, no need to specify it here again. ... 271 4. BGP Only to Customer (OTC) Attribute ... 316 The OTC Attribute may be set by the egress policy of remote AS or by 317 the ingress policy of local AS. In both scenarios, the OTC value 318 will be the same. This makes the scheme more robust and benefits 319 early adopters. [nit] s/egress policy of remote AS or by the ingress policy of local AS/egress policy of the remote AS or by the ingress policy of the local AS ... 334 The described ingress and egress policies are applicable only for 335 unicast IPv4 and IPv6 address families and MUST not affect other 336 address families by default. The operator MUST NOT have the ability 337 to modify the policies defined in this section. [major] s/MUST not/MUST NOT [major] "MUST not affect other address families by default" Maybe "MUST NOT be applied to other address families by default" ?? 339 5. Additional Considerations ... 349 No Roles SHOULD be configured on a 'complex' eBGP session (assuming 350 it is not segregated) and in that case, the OTC Attribute processing 351 MUST be done relying on configuration on a per-prefix basis. Also, 352 in this case, the per-prefix peering configuration MUST follow the 353 same definitions of peering relations as described in Section 2. 354 However, in this case, there are no built-in measures to check 355 correctness of the per-prefix peering configuration. [major] This paragraph requires the use of OTC in cases where a Role is not configured. I don't feel comfortable with that because it is equivalent to mandating behavior for eBGP sessions that don't support this document. I would prefer it if this was worded as a recommendation (non-normative). Suggestion> No Roles SHOULD be configured on a 'complex' eBGP session (assuming it is not segregated). An operator may want to achieve an equivalent outcome by configuring policies on a per-prefix basis to follow the definitions of peering relations as described in Section 2. However, in this case, there are no built-in measures to check correctness of the per-prefix peering configuration. 357 The incorrect setting of BGP Roles and/or OTC Attributes may affect 358 prefix propagation. Further, this document does not specify any 359 special handling of incorrect AS numbers in the OTC Attribute. Such 360 errors should not happen with proper configuration. [] Let's take out the last sentence. The rest of the paragraph implies that the value of the ASN doesn't matter/shouldn't be checked (because it could be set elsewhere)...but calling it an error gives it the importance that it doesn't have. 362 6. IANA Considerations 364 IANA has registered a new BGP Capability described in Section 3.1 in 365 the "Capability Codes" registry's "IETF Review" range [RFC5492]. The 366 description for the new capability is "BGP Role". IANA has assigned 367 the value 9 [to be removed upon publication: 368 https://www.iana.org/assignments/capability-codes/capability- 369 codes.xhtml]. This document is the reference for the new capability. [nit] s/BGP Capability described in Section 3.1/BGP Capability (Section 3.1) ... 406 7. Security Considerations ... 428 Removing the OTC Attribute or changing its value can limit the 429 opportunity of route leak detection. Such activity can be done on 430 purpose as part of a Man in the Middle (MITM) attack. For example, 431 an AS can remove the OTC Attribute on a received route and then leak 432 the route to its transit provider. Such malicious activity cannot be 433 prevented without cryptographically signing the BGP UPDATE [RFC8205] 434 or out of band detection [I-D.ietf-sidrops-aspa-verification], but 435 such schemes are beyond the scope of this document. [] As you may know, the IETF has been discussing the use of more inclusive terminology. Please consider changing this phrase: "on purpose as part of a Man in the Middle (MITM) attack." Suggestions: "on purpose by a rogue router." "on purpose as part of an on-path attack." https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/ [major] "Such malicious activity cannot be prevented without cryptographically signing the BGP UPDATE [RFC8205] or out of band detection [I-D.ietf-sidrops-aspa-verification], but such schemes are beyond the scope of this document." BGPSec doesn't protect against the removal of the OTC -- or protect any other attribute (except for the AS_PATH). As far as I can tell, I-D.ietf-sidrops-aspa-verification doesn't protect against the removal of the OTC either, and could only detect anomalies related to the Customer/Peer(s) relationship. The point here is the the potential mitigation would either not work in this case or only provide a partial solution. I think we would be better off simply recognizing that this threat is not new in BGP and that it may affect any attribute. ... 448 8.1. Normative References ... 460 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 461 RFC 4272, DOI 10.17487/RFC4272, January 2006, 462 <https://www.rfc-editor.org/info/rfc4272>. [major] This reference can be informative. [EoR -16]
- [Idr] AD Review of draft-ietf-idr-bgp-open-policy… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-open-po… Alexander Azimov
- Re: [Idr] AD Review of draft-ietf-idr-bgp-open-po… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-open-po… Alexander Azimov
- Re: [Idr] AD Review of draft-ietf-idr-bgp-open-po… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-open-po… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-open-po… Sriram, Kotikalapudi (Fed)