Re: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt
Susan Hares <shares@ndzh.com> Sat, 26 February 2022 01:03 UTC
Return-Path: <shares@ndzh.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 ADD6D3A0D25; Fri, 25 Feb 2022 17:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.05
X-Spam-Level: *
X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 CRnr-bgkL3PH; Fri, 25 Feb 2022 17:03:15 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 87D433A09D0; Fri, 25 Feb 2022 17:03:14 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.120.176;
From: Susan Hares <shares@ndzh.com>
To: bruno.decraene@orange.com
Cc: idr@ietf.org, idr-chairs@ietf.org, "'Alvaro Retana (aretana)'" <aretana@cisco.com>, "'Sriram, Kotikalapudi (Fed)'" <kotikalapudi.sriram@nist.gov>
References: <23467_1645021138_620D07D2_23467_279_1_61ab1378871c454881d0d6ad5f6605be@orange.com> <051401d82a53$83beee90$8b3ccbb0$@ndzh.com> <13056_1645809448_62190F28_13056_476_4_186646c90e06474dab17a798a0794c16@orange.com>
In-Reply-To: <13056_1645809448_62190F28_13056_476_4_186646c90e06474dab17a798a0794c16@orange.com>
Date: Fri, 25 Feb 2022 20:03:06 -0500
Message-ID: <005501d82aac$9df43b40$d9dcb1c0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01D82A82.B5227900"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKIhKveajNJfLrh+1/3oZ1EigVU3gLiwFwRAbcJKMGrH30d0A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/h3z66EzQfpGGrPxEIGaKNNz8p2k>
Subject: Re: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt
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: Sat, 26 Feb 2022 01:03:20 -0000
Bruno: The idr-chairs discussed your proposals. Since Jeff kindly led the discussion this week, Jeff is posting the IDR chairs response. As Jeff mentioned, we will be glad to sponsor a revision for RFC7606. Since you were kind enough to respond to me quickly, I have responded to your questions from my view As Jeff mentioned, we will be glad to sponsor a revision for RFC7606. Please let us know if this consensus call works for you. Again, Jeff, Keyur and I really appreciate you digging into the error cases. We hope that other people will carefully read this discussion, and think about RFC7606. If you wish to have a short presentation discussing this topic at the next IETF, please let us know. Sue From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Friday, February 25, 2022 12:17 PM To: Susan Hares Cc: idr@ietf.org; idr-chairs@ietf.org; 'Alvaro Retana (aretana)'; 'Sriram, Kotikalapudi (Fed)' Subject: RE: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt Hi Sue, Thanks for your email. Please see inline [Bruno3] On a side note, I'm not even sure that the feature needs the attribute to encode an AS number: The AS number seems to be only checked in step "Ingress.2" when received from a Peer. However, there seem to be only 2 cases: - if the EBGP neighbor supports OTC, it won't send the route if it's a leak (OTC is present), so no need to double check on receipt as we won't receive the route - if the EBGP neighbor does not support OTC, it won't add the OTC with its own AS number, so no need to check for this specific AS number an OTC would not have this AS number. Also, doesn't leaking the AS number in the OTC reveal some business relationship that may be private? The security section does not seem to say a word about this. [Sue]: [personal opinion]: Yes, it does reveal something. The security section should mention it. Two caveats: 1) Does it help operators to realize this point? - If so, suggest some wording that will be effective for the operators. 2) Alvaro has reached an agreement on the text with the IESG. We will need Alvaro to approve any text changes as Ok with IESG's intent. From: Susan Hares <shares@ndzh.com> Sent: Friday, February 25, 2022 3:25 PM Bruno: One question which I am pulling to the front: 1) Why disable length checks? [Bruno3] Because on IBGP we don't even need to read this attribute and there seem to be difficulties about defining how to react to error. So not checking is possible and avoid the difficult discussion. My preference would be to check and perform attribute discard on IBGP. But some want to keep the OTC feature even though the attribute is bogus (while the vast majority of routes are not leak so the probabilities would be that the route is useful and should be kept, rather than treat-as-withdraw). [Sue]: Jeff clearly states the chairs reasoning. On IBGP, we need to check and "treat-as-withdraw" behavior. I think this addresses your concern and the IDR chair's concern. Your comment : [Bruno2] First step that RFC7606 does is to define (i.e. choose) what constitute an error. We could define that length is not checked for IBGP because we don't care about the content (or even the attribute). Alternatively, I'm also fine with attribute discard if we consider that the attribute is in error and hence could not be trusted. My point: Length checks in RFC7606 seem basic sanity check for any message. [Bruno3] Sure. That being said, for the CLUSTER_LIST attribute, there is a different handling for EBGP and IBGP with IBGP checking for the length while EBGP not checking the length <https://datatracker.ietf.org/doc/html/rfc7606#section-7.10> https://datatracker.ietf.org/doc/html/rfc7606#section-7.10 [sue]: I agree that the cluster list attribute has a different handling for E-BGP and I-BGP. We discussed the pros/cons for OTC, but we think the "treat as withdraw' is best. After that point, I am fine the remaining being specific to a draft. For example, OTC for IBGP can be tossed out after it is determined to have a valid length. [Bruno3] I'm assuming that you meant "is determined to have an _invalid_ length". [Sue]: First test for valid length. If invalid, treat as withdraw. --Bruno Did I miss some other reason. Thanks, Sue Orange Restricted From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Wednesday, February 16, 2022 9:19 AM To: Sriram, Kotikalapudi (Fed) Cc: idr@ietf.org; idr-chairs@ietf.org; Alvaro Retana (aretana); Susan Hares Subject: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt Hi Sriram, Please see inline [Bruno2] Orange Restricted From: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> Sent: Tuesday, February 15, 2022 11:52 PM To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; Alexander Azimov <a.e.azimov@gmail.com>; Jeffrey Haas <jhaas@pfrc.org> Cc: idr@ietf.org; Alvaro Retana (aretana) <aretana@cisco.com>; idr-chairs@ietf.org; Susan Hares <shares@ndzh.com> Subject: RE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt Hi Bruno, Comments inline marked with [Sriram]. >[Bruno] - RFC7606 provides a guidance https://datatracker.ietf.org/doc/html/rfc7606#section-8 <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack er.ietf.org%2Fdoc%2Fhtml%2Frfc7606%23section-8&data=04%7C01%7Ckotikalapudi.s riram%40nist.gov%7Cb7a059d3cee145ca531c08d9f0a3c35f%7C2ab5d82fd8fa4797a93e05 4655c61dec%7C1%7C0%7C637805408436586543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fsbz%2B8 gTR8c0r94m4SoaamR4O%2BmHiMYH5tY9uRCXTHk%3D&reserved=0> . It's only half a page so anyone interested could read. I don't think it can be summarized as per you above sentence. [Sriram] Section 8 of RFC 7606 that you cite, says: A document that specifies a new BGP attribute MUST provide specifics regarding what constitutes an error for that attribute and how that error is to be handled. Allowable error-handling approaches are detailed in Section 2. [Sriram] From the list of error-handling approaches detailed in Section 2, only treat-as-withdraw and attribute discard are relevant for us. Since the RFC says, "Allowable error-handling approaches are detailed in Section 2", it does not allow for applying none of the approaches as an option. [Bruno2] First step that RFC7606 does is to define (i.e. choose) what constitute an error. We could define that length is not checked for IBGP because we don't care about the content (or even the attribute). Alternatively, I'm also fine with attribute discard if we consider that the attribute is in error and hence could not be trusted. >[Bruno] In particular there is not such "SHALL be handled using the approach of "treat-as-withdraw". [Sriram] Regarding attribute discard, RFC 7606 says: "This approach MUST NOT be used except in the case of an attribute that has no effect on route selection or installation." This implies: This approach MUST NOT be used in the case of an attribute that has an effect on route selection or installation. Do you agree? The route does propagate from iBGP (ingress) to eBGP (in the ASBR), where the attribute plays a role in route selection for propagation. [Bruno2] 1) For IBGP, OTC attribute has no effect on route selection and installation. 2) Since you seem to be calling for "treat-as-withdraw", I would argue that "treat-as-withdraw" has also an effect on route selection or installation, and a bigger one. So it's not really safer in term of side effect. >[Bruno] It also specifically calls for attention to optional transitive attributes (such as OTC) for which "the damage inflicted may be multiplied manyfold > [Sriram] The "damage inflicted may be multiplied manyfold" is about session reset. That is why the RFC urges the use of treas-as-withdraw or attribute discard instead. [Bruno2] It's discussed in the context as session reset, but the cause is the optional transitive attribute. Cf following text which only refers to the type of attribute and not the action taken although the problematic attributes may have originated with a single update transmitted by a single BGP speaker, by the time they encounter a router that checks them they may have been replicated many times and thus may cause the reset of many peering sessions. Thus, the damage inflicted may be multiplied manyfold. >[Bruno] Without double checking, I don't recall that OTC is acted upon within IBGP. So in this case it does not affect routing selection. Let's just specify to not even look at it (it's optional) and problem is solved. [Sriram] iBGP and eBGP within an ASBR are not isolated operations. Please see my comment above. Not to look at OTC is not an option. [Bruno2] If this were true, we could not define the OTC as an optional transitive attribute, because essentially some routers will not look at OTC. Pick your option. A compliant router checks syntax errors in iBGP (just as in eBGP) based on its expectations of the OTC Attribute. If the length value does not match, the Attribute is malformed. [Sriram] If the OTC attribute is malformed for any reason, we cannot be sure that even the Attribute type value is correct (or as intended). [Bruno2] 1) That's not the path chosen by RFC 7606 in case of a length error. 2) I would find debatable to assume an error on a field (type) when you don't see an error on this field. TLV construct provides hierarchy: I agree that what is inside the TLV (i.e. after/below the error) can't be trusted; but for what is before the error, there is little to no reason to assume an error (and if we do, we could imagine anything and in particular an attribute for which the error handling is "session reset".) [Sriram] Then must it be propagated from iBGP to eBGP (in the ASBR) and then to eBGP neighbors? [Bruno2] Current text proposes to _not_ propagate to eBGP neighbors except for Customer. If length is wrong, I would be fine to also not propagate to Customerif you find this better. Thanks for the discussion --Bruno Thanks. Sriram ____________________________________________________________________________ _____________________________________________ 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.
- [Idr] ttRE: FW: New Version Notification for draf… bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … Alexander Azimov
- Re: [Idr] ttRE: FW: New Version Notification for … bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … Alexander Azimov
- Re: [Idr] ttRE: FW: New Version Notification for … bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … Alexander Azimov
- Re: [Idr] ttRE: FW: New Version Notification for … bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … Sriram, Kotikalapudi (Fed)
- Re: [Idr] ttRE: FW: New Version Notification for … bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … Susan Hares
- Re: [Idr] ttRE: FW: New Version Notification for … bruno.decraene
- Re: [Idr] ttRE: FW: New Version Notification for … Jeffrey Haas
- Re: [Idr] ttRE: FW: New Version Notification for … Susan Hares