Skip to main content

Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
RFC 9234

Yes

Alvaro Retana
Erik Kline
(Martin Vigoureux)

No Objection

Francesca Palombini
Zaheduzzaman Sarker

Note: This ballot was opened for revision 19 and is now closed.

Alvaro Retana Yes

Erik Kline Yes

Warren Kumari Yes

Comment (2022-01-19 for -20)
Firstly, thank you for this document -- if deployed, I think it will go a very long way towards reducing accidental leaks.

I have a few comments, feel free to address or not.

1: It seems like there should also be a code-point for "Complex" - I guess that something similar could be inferred if this is negotiated and one of the other codepoints isn't sent, but having it explicit seems cleaner.

2: The document says things like "It **prevents** ASes from creating leaks,..." and "The purpose of this attribute is to **guarantee** the once a route is sent, ..." - it feels like this is overselling things. As an example, the OTC attribute could be stripped (unintentionally or maliciously) and it would be included in a leak, etc. Again, this is only a comment, but it seems like more weasel words would make the document stronger.

3: "If a route with the OTC Attribute is received from a Customer or RS-Client, then it is a route leak and MUST be considered ineligible" - fine, but it seems like there should be a bit more than just "considered ineligible", for example, this should be logged somewhere, or implementations should allow the operator to do the conceptual equivalent of "show route leaked" or similar....

Again, thank you for a really useful document,

Francesca Palombini No Objection

John Scudder No Objection

Comment (2022-01-12 for -19)
I’m happy to see this document proceeding forward. Thanks for all the work that went into it, and into the shepherding. I do have a few points I’d like to raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a term with quite a bit of baggage in BGP, and without further qualification, it’s likely to be interpreted as “routing policy configured by the router’s operator”. I wondered at first if your choice of “policy” was deliberate, to imply that the specification is not expected to be hard coded into the implementation, but rather configured (or not) by the operator? But, the whole point of the spec is to move away from using policy configuration to protect against route leaks — requiring configuration to enact the import and export “policies” given in §4 would fly in the face of the document’s raison d’être. Furthermore, you close §4 with “the operator MUST NOT have the ability to modify the policies defined in this section” — and that does help, but not before considerable potential confusion is created by the unfortunate choice of terminology.



So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be hard coded into any compliant implementation. I strongly suggest you find a term other than “policy” to express what you mean. For example, “procedures” seems like a good replacement. You could say something like “the following procedures apply to the processing of the OTC Attribute during route reception” and “the following procedures apply to the processing of the OTC Attribute during route transmission”. (You could also try to put it in terms of RFC 4271, but it might be a bit painful.) I just grepped through §4 and a simple replacement of “policy” with “procedure” throughout seems like it would be almost sufficient.



I was ready to make this a DISCUSS until I came to the final sentence of §4. That sentence does clarify matters sufficiently to reach the minimum bar, but I think the document would be even more usable if further edits are made along the lines above.


2. Section 4 says



   The OTC Attribute may be set by the egress policy of the remote AS or

   by the ingress policy of the local AS.



First, my earlier comment about “policy” applies here as well — you could maybe say “on egress from the remote AS or on ingress to the local AS”. Beyond that, I suggest changing the “may” (which is admittedly lower-case”) to a “might”, which has even less risk of confusion with any kind of normative meaning. Presumably what you mean is actually that if the remote AS is noncompliant with this spec, the local AS will have to set the attribute, and this is a feature, not a bug.


3. In Section 4 you write,


   The same OTC Attribute which is set locally also provides
   a way to detect route leaks by an AS multiple hops away if a route is
   received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be several sentences. I don’t think it’s needed, or even desirable, to explain in detail in this document how you might make use of the OTC Attribute for troubleshooting, but if there’s a different document that does explain it, an informative reference might not hurt. I’m pretty sure I remember this being covered in one or more IDR and/or GROW presentations, but I don’t know if it got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP Roles”. The document, per se, doesn’t provide any such thing of course — an implementation of the specification would provide such. “This document specifies” would be more correct I think.



A second point related to the same sentence is that it feels like a poor fit to refer to what you do in this spec as configuration automation, a term more usually associated with automatic, typically database-driven, generation and management of (router) configurations. In the second ¶ of §1, you identify configuration as the bad, error-prone, legacy way of preventing route leaks. So maybe something like, “This document specifies a means of replacing the configuration-based method of route leak prevention, described above, with a more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client, and Peer. I think the definitions provided in §2 are better than those in §1.1, and sufficient unto themselves, and that you could remove the first ¶ of §1.1. 


6. You refer to transit and non-transit providers in many places throughout the document. Although these seem to some of us like well-known terms of art that need no reference, I have the feeling that may not be true for our entire community, or worse still, different people might all “know” what it means but with different definitions, and so it might be desirable to provide a citation. 

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC 7705)? Mostly, I just have a free-floating unease here, because with the hacks described in RFC 7705, a given router may represent itself as any one of several different ASes, and your spec does ASN embedding and enforcement. Most likely there would be no problem, since the egress rules in §4 suggest the OTC attribute is to be attached as part of route transmission; therefore, a router might be expected to attach whatever value is appropriate based on the ASN it’s currently representing itself as. It might still be worth adding a note cautioning implementors about this, though, since implementations tend to do things for the sake of efficiency that spec authors aren’t expecting. One optimization pattern is to pre-build updates and copy them to many different transport connections; in such cases the OTC value might be prepopulated and the implementor might need to give extra attention to the exception case where a particular transport connection is representing a different ASN from the router's "real" ASN.

Lars Eggert No Objection

Comment (2022-01-20 for -20)
DOWNREF [RFC7908] from this Proposed Standard to Informational RFC7908.
It doesn't look like RFC7908 needs to be a normative reference, so
citing this informationally should address this.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Thanks to Gyan S. Mishra for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/bnQ6_d1J8TSN6zw-579JvK8bxkQ).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 4, nit:
-    This document specifies a means of replacing the operator driven
-                                                             ^
+    This document specifies a means of replacing the operator-driven
+                                                             ^

Section 4. , paragraph 11, nit:
-    the ingress of the local AS, i.e., if the remote AS is noncompliant
+    the ingress of the local AS, i.e., if the remote AS is non-compliant
+                                                              +

Section 3.1. , paragraph 7, nit:
> , if the BGP Role Capability is sent but one is not received, the BGP Speake
>                                     ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 4. , paragraph 8, nit:
> fied in this document are NOT RECOMMENDED to be used between autonomous syste
>                               ^^^^^^^^^^^^^^^^^
The verb "RECOMMENDED" is used with the gerund form.

Section 4. , paragraph 13, nit:
> epresent itself as any one of several different ASes. This should not be a p
>                               ^^^^^^^^^^^^^^^^^
Consider using "several".

Section 7. , paragraph 2, nit:
> will limit route propagation in an unpredictable way. 8. References 8.1. Norm
>                              ^^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "unpredictably" to avoid
wordiness.

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2

Murray Kucherawy No Objection

Comment (2022-01-19 for -20)
Nice work on this.

The shepherd writeup says this document creates a new Expert Review registry and suggests some experts, but the document doesn't actually create any registry as far as I can tell.  Is there something missing in the document, or is the shepherd writeup in error?

Robert Wilton No Objection

Comment (2022-01-18 for -20)
Hi,

Thanks for this document.  I'm no expect on BGP, but I found this document pretty easy to read and understand.  Not surprisingly, I'm always supportive of drafts that aim to minimize configuration errors and operational problems.

I have a a few comments though:

(1) Did you consider explicitly defining a code point for the "complex" role?  Today, because of the desire for backwards compatibility, it is not possible for a peer to distinguish between the case that (i) no role has been provided by the peer because it doesn't support roles, and (ii) no role has been provided by the peer because it thinks that it has a "complex" peering relationship.  Unless I'm missing something, adding an explicit role for "complex" would allow the peer to distinguish between these two cases and potentially capture more errors (e.g., complex role is only valid with peer's complex role).  In theory, enabling "strict" checking might also be able to cover this case, it is feels less intuitive (i.e., enable strict, but don't advertise a role to indicate and enforce a complex relationship).

(2) The obvious OPS/Mgmt AD question: Is the associated configuration for this feature covered in the IETF BGP YANG module, or extension/augmentation that is being worked on?  If so, then an informational reference to the configuration leaves associated with this feature might be helpful to readers, although one could perhaps argue that this would end up being a forward reference, and any associated YANG module configuration should have references back to this draft anyhow.

(3) As a nit, I notice that the sender can only include a single role but the receiver must tolerate multiple roles if they have the same value.  Perhaps everything else in BGP is tolerant of receiving malformed packets, and hence this is done for consistency, but I do wonder whether it isn't better to return an error to the peer instead.

Regards,
Rob

Roman Danyliw No Objection

Comment (2022-01-19 for -20)
Thank you to Alexey Melnikov for the SECDIR review.

I agree with Warren that the following text is too strong:

* Section 4 

   The purpose of this attribute is to guarantee
   that once a route is sent to a Customer, Peer, or RS-Client, it will
   subsequently go only to Customers.

Maybe "The purpose of this attribute is to convey ..."

Zaheduzzaman Sarker No Objection

Éric Vyncke No Objection

Comment (2022-01-18 for -19)
Thank you for the work put into this document. The technique could indeed be useful, let's simply hope that not only the well-configured BGP speakers will use it ;-)

Please find below some non-blocking minor COMMENT points (no need to reply).

Special thanks to Susan Hares for the shepherd's write-up including the section about the WG consensus. 

I hope that this helps to improve the document,

Regards,

-éric

Is RFC 7908 really a normative reference ?

-- Section 3.1 --
"An eBGP speaker MUST NOT advertise multiple versions of the BGP Role Capability" Should there be a description of what to do when a eBGP speaker receives multiple conflicting roles on a session ? Or hint to section 3.2 for more details ?

(Martin Vigoureux; former steering group member) Yes

Yes (for -20)

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2022-01-17 for -19)
Thanks to Alexey Melnikov for the secdir review and re-review; I echo
his comments about the usefulness of the mechanism and the quality of
the security considerations section.  Thank you for this document!

I'm rather sympathetic to John's remarks about "policy" vs (e.g.)
"procedures".

This document establishes the generic-sounding "BGP Role" capability and
a registry for the corresponding values, but the focus of the technical
mechanisms presented here is to avoid route leakage.  Might there be
other future consumers of BGP Role (perhaps including use of Role for
iBGP to get in-band confirmation of the relationship between peers) that
are unrelated to avoiding route leakage?  Is there anything in this
document we might change to facilitate such future extensions?

Section 6

Subsections for the individual actions/registries being acted upon/in
might aid readability.

Section 8.1

RFC 7908 is referenced only once, in a location that doesn't obviously
induce a normative requirement.  It does seem like a good thing to read
before implementing this document, though, so maybe the takeaway is to
add more references to it rather than demote it to informative.

NITS

Section 1

   Existing approaches to leak prevention rely on marking routes by
   operator configuration, with no check that the configuration
   corresponds to that of the eBGP neighbor, or enforcement that the two
   eBGP speakers agree on the relationship.  This document enhances the

I suggest adding an adjective to "relationship" (maybe "topology"?).

   BGP OPEN message to establish an agreement of the relationship on
   each eBGP session between autonomous systems in order to enforce

Similarly here, though maybe "nature of the relationship" in this
instance.

Section 2

   A BGP speaker may apply policy to reduce what is announced, and a
   recipient may apply policy to reduce the set of routes they accept.
   Violation of the above rules may result in route leaks.  Automatic
   enforcement of these rules should significantly reduce route leaks
   that may otherwise occur due to manual configuration mistakes.

If I understand correctly, "violation of the above rules" refers to the
enumerated rules a few paragraphs prior, and specifically not to the two
applications of policy mentioned in the preceding sentence.  Assuming
that's correct, then it seems useful to clarify the transition between
sentences, perhaps "use of such policies that violate the rules listed
above may result in route leaks" or "when these policies violate the
rules listed above, route leaks may occur".

Section 5

   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 the correctness of the per-prefix
   peering configuration.

"built-in" is perhaps needlessly vague; we might say "in-band" or "no
measures in the protocol" instead.

Section 7

   Removing the OTC Attribute or changing its value can limit the
   opportunity of route leak detection.  Such activity can be done on

I think s/of/for/