[Idr] John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Fri, 07 May 2021 19:57 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FEE3A3069; Fri, 7 May 2021 12:57:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-flowspec-oid@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <162041746726.16037.6421894058933171338@ietfa.amsl.com>
Date: Fri, 07 May 2021 12:57:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uimsAdy0z4cGSvFx5-qqzE10tz8>
Subject: [Idr] John Scudder's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 07 May 2021 19:57:48 -0000
John Scudder has entered the following ballot position for draft-ietf-idr-bgp-flowspec-oid-13: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document, I'm glad to see it finally close to publication. I have a few comments I hope will help improve it, below. 1. Section 2 [RFC8955] defines a BGP NLRI [RFC4271] that can be used to distribute RFC 4271 is the right citation for “BGP” but for “BGP NLRI” other than IPv4 unicast you want RFC 4760. the Flow Specification. The aim is making sure that only speakers on making -> to make originated in any location within the same autonomous system than the than -> as Flow Specification received from an iBGP peer, it could be possible to disseminate such Flow Specification NLRIs directly from the “It could be possible”? Or “it would be necessary”? validated when received by RR and R1. Sometimes the Flow Specification needs to be originated on AS1. ASBR1 could originate on -> within 2. Section 4.1 1. This condition SHOULD be enabled by default (it may be disabled by explicit configuration as described on the next list item (b.2.1)).. an empty AS_PATH. Looks as though “an empty AS_PATH” is a cut-n-paste error that should be deleted? 3. As an extension to this rule, a given non-empty AS_PATHs AS_PATHs -> AS_PATH (agreement in number) AS_CONFED_SET segments), MAY be validated by policy. A I think “permitted” would be clearer than “validated”. Also, policy may be useful to validate a specific set of non-empty AS_PATHs (b.2.3). For example, it could validate a Flow Specification whose AS_PATH contains only an AS_SEQUENCE with ASes that are all known to belong to the same administrative domain. Same point, I suggest “permit”. 3. Section 4.2 This rule prevents the exchange of BGP Flow Specification NLRIs at Internet exchanges with BGP route servers [RFC7947]. Since it may not be common knowledge that route servers don’t insert their own AS number, I suggest a change something like this, for clarity: This rule prevents the exchange of BGP Flow Specification NLRIs at Internet exchanges with BGP route servers, which by design don’t insert their own AS number into the AS_PATH ([RFC7947] Section 2.2.2.1). 4. Section 4.2 For clarity, the AS in the left-most position of the AS_PATH means the AS that was last added to the AS_SEQUENCE. I suggest changing “last” to “most recently”. This is just personal preference, though. I also suggest changing “AS_SEQUENCE” somehow, probably to “AS_PATH”. The reason for this is there could be more than one AS_SEQUENCE in the AS_PATH so the definite article isn’t quite correct. There is however only one AS_PATH, and you can make the change without loss of generality or correctness. So, the full suggested rewrite is: For clarity, the AS in the left-most position of the AS_PATH means the AS that was most recently added to the AS_PATH. 5. Section 4.2 Specifications. This is a security BGP threat, but out of the “Security BGP threat” -> “security threat” (or “BGP security threat” if you prefer) 6. Section 4.2 Using the new rule to validate a Flow Specification route received from an External Border Gateway Protocol (eBGP) peer belonging to the same local domain (in the case of a confederation) is out of the scope of this document. Note that although it's possible, its utility is dubious. Although it is conceivable that an router in the same local domain (both iBGP and eBGP within the same local domain) could send a rogue update, only eBGP (outside the local domain) risk is considered within this document (in the same spirit of the mentioned beforehand AS_PATH validation in [RFC4271]). I’m having a hard time understanding this paragraph. This is at least partly due to the use of “local domain“, which isn’t a well-defined term of art. You could try something like “under the same administration“? But, even if I make that change in my head as I read the paragraph, I still don’t get your point. :-( Is the whole paragraph strictly about confederations, and what you’re talking about is a BGP session between a router in one member-AS and a router in another member-AS of the confederation? If that’s it, I can probably propose some new text. Also, “an router” -> “a router”. Also, you should cite RFC 5065 when you mention confederations. 7. Section 5 its best-match unicast route) are learned from the same peer accross accross-> across 8. Section 5 Consider the validation procedure preceding this document. The I think what you mean here is “consider the validation procedure defined in RFC 8955“. If that’s correct, I suggest saying it that way. (If that’s not correct, what did you mean?) 9. Section 7 thus maintain security characteristics equivalent to the existing Maintain -> maintains 10. Section 7 The original AS_PATH validation rule ([RFC4271] section 6.3) becomes hereby optional (section 4.2). I don’t think you’re actually updating RFC 4271, are you? The way you’ve written this makes it sound as though you are. You’re relaxing the rule in RFC 8955, but as you point out in section 4.2, RFC 4271 makes AS_PATH neighbor AS insertion enforcement optional to begin with: If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost (with respect to the position of octets in the protocol message) AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH. Maybe you could rewrite something like this: “As per section 4.2, it is becomes optional to enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the leftmost position of the AS_PATH attribute. Then we continue: If that original rule is actually not enforced it may introduce some security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route whose first AS in AS_PATH was Y (assume Y is the first AS in the AS_PATH of the best-match unicast route). This risk is impossible to prevent if the Flow Specification route is received from a route server peer. I think you’ve missed out on the opportunity to point out that the risk can also be mitigated if the route server itself enforces the optional rule of RFC 4271 section 6.3.. I think it’s fair to say that at an exchange point, the administrator of the route server enjoys more trust then the administrators of other routers at the exchange point. If that peer is known for a fact not to be a route server, that optional rule SHOULD be enforced for Flow Specification routes. It may be necessary to say a little more about how you would get this knowledge about the peer not being a route server. Possibly a rewrite could be something like: "Unless configuration (or other means beyond the scope of this document) indicates that the peer is a route server, that optional rule SHOULD be enforced for Flow Specification routes from EBGP peers." 11. Section 7 absolute and the new possibility than an iBGP speaker could send a Than -> that
- [Idr] John Scudder's No Objection on draft-ietf-i… John Scudder via Datatracker
- Re: [Idr] John Scudder's No Objection on draft-ie… Juan Alcaide (jalcaide)
- Re: [Idr] John Scudder's No Objection on draft-ie… John Scudder
- Re: [Idr] John Scudder's No Objection on draft-ie… Juan Alcaide (jalcaide)
- Re: [Idr] John Scudder's No Objection on draft-ie… John Scudder
- Re: [Idr] John Scudder's No Objection on draft-ie… Juan Alcaide (jalcaide)