[Idr] Re: draft-haas-idr-bgp-attribute-escape-04

[Jeffrey Haas <[e-mail]>]

Bruno,

Thanks for your comments.  

> On Jun 5, 2026, at 13:02, [e-mail] wrote:
[slight reordering of the original message]

> §2
> Most of this document seems to focus on the "escape" part (emission), not the "escaped' part (reception). I think that both aspects should be covered. In particular in case of bugs -but not only-, we could only improve the situation on the receiving side (handling the escaped attribute).

When the document was originally drafted, the focus was to discuss what caused the escape and what techniques could be used in the design or operation of new protocol features to avoid doing that.

It's understood that there's a desire in the working group to address classes of things that currently have escape issues.  If such mitigations are general, they can easily fit into the scope of this document.  I fear that the mitigation considerations will turn into an endless "just one more thing" and this is never published. :-)


>   §2
> Attribute escape may be due to implementation bugs. I think that this is a source that should be mentioned. (whether this document or future documents may improve this or not, is not relevant IMHO and it makes sense to me to list this case of attribute escape). ---
> 

I've added the following to 4.2:

+        <t>
+         Escapes may happen for a number of reasons:
+        </t>
+       <ul>
+         <li>Operational error.</li>
+         <li>Implementation defects.</li>
+         <li>Protocol design or incremental deployment issues.</li>
+       </ul>

> Also in §4.3 community where a network operator may not want to accept some of its internal community from an EBGP session)

This is somewhat captured in the reference to RFC 7454. I do think we're seeing a need to be more explicit about scrubbing procedures overall. The work in GROW updating that RFC may be a better place to capture the procedures.

I'll add a github issue to consider what portion fo the new GROW work we should cite here.

https://github.com/jhaas-pfrc/draft-haas-idr-bgp-attribute-escape/issues/5

>  §4.4 being the exception that prove the rule ;-). Thanks for it, but the title is not that self-explicit to me. I'd probably prefer referring to "escaped attribute" or "reception of escaped attributes". or something like that

I've changed the title to Inadvertent Use - Receiving and Using Escaped Attributes

The motivation to keep the word "inadvertent" is to capture the "oops" aspect of the escape problem space.  The "fault" is somewhat less that the operator isn't careful, it's that the features are not safe as designed.

Hopefully this addresses your comment.

>  §5.1 is an example: referring to "propagate" but not "receive"

Perhaps:
Rather than simply permitting propagation or reception of all unknown Path  Attributes, lists of permitted Path Attributes by Attribute Type Code may be provisioned throughout the network.

> §3
> " In general, it is necessary for all BGP speakers in an Autonomous System (AS) to agree on how to do route selection. Inconsistent route selection may lead to routing or forwarding loops."
>  ok
>  "A consequence of this point is that any new feature that alters route selection needs to be consistently deployed within an AS."
>  On the pedantic side, I think I'd disagree with the term "A consequence". "In general" and "may" does not translate into "_any_ new feature [...] _needs_"
> I also think that the use of encapsulation between ASBR may allow feature altering route selection.

I agree with your point.  Determining whether a consequence of a new feature or its deployment considerations can be safely deployed in a partial fashion is part of the review we give new features in the BGP-related working groups.

And I agree that the use of tunneling to a next hop can mitigate many scenarios.

However, I don't think I can distill my review process for this sort of thing into a short consideration covering attribute escape or incremental feature deployment.  Did you have text to propose that would do this?

Meanwhile, perhaps this text:
        New features that alter route selection need to be evaluated for
        consistent deployment within an AS.  In most circumstances, this is
        true for the full scope of BGP route propagation where the next hop is
        unchanged.  Thus, this applies to BGP Confederations
        <xref target="RFC5065"/> as well.

> §3
> "Non-transitive Path Attributes can be helpful for features that impact route selection."
>  Agreed, but this read strangely (to me) given the previous paragraph. Indeed, previous paragraph is about the importance of consistent route selection and for sure non-transitive attribute do not help. I'd guess that you have in mind the inter-AS case while previous paragraph was about intra-AS. If so, may be expliciting this inter-AS scope would help).

How about:
        To ensure consistent route selection, Non-transitive Path Attributes
        that impact route selection need to be consistently deployed.  Once a
        route containing a non-transitive Path Attribute reaches a BGP speaker
        that is ignorant of its behavior, that attribute will be dropped.  This
        prevents escape of that Path Attribute via BGP speakers ignorant of the
        feature.  An example of this behavior is used in the AIGP
        <xref target="RFC7311"/> feature.
>  ---
> §4
> " A common scoping boundary is intra-AS only; for example, drop at eBGP boundaries."
> Agreed.
>  "BGP Capabilities [RFC5492] can also provide the ability to signal a scoping boundary."
> Agreed, but IINM, the former "scope" is related to the network topology, while the latter "scope" is probably related to the BGP session topology. When IBGP RR are used, it seems to be that the type of scopoing is relatively different. (I'd guess you primarily have the EBGP case in mind). I think the distinction should be indicated.
>  "Another implicit scoping boundary are features that are AFI/SAFI specific ([RFC4760])"
>  Agreed. One may discuss the term "another" as it seems mostly depend on BGP capabilities.
>  "the scope is the contiguous domain of all devices that participate in that AFI/SAFI."
>  Same comment as before. "contiguous" does not refer to the network topology.

Perhaps:
        <t>
          The propagation scope of BGP attributes is typically described as
          part of a BGP protocol extension's procedures.  The procedures are
          often BGP session-specific. Common scoping boundaries include:
        </t>

        <ul>
          <li>Intra-AS only; for example, drop at eBGP boundaries.</li>
          <li>Features that are AFI/SAFI specific (<xref target="RFC4760"/>);
          the scope is the contiguous domain of all devices that participate in
          that AFI/SAFI.</li>
          <li>BGP Capabilities <xref target="RFC5492"/> can also provide the
          ability to signal a scoping boundary.</li>
        </ul>

The intention is to discuss that scoping is generally tied to sessions.  "Network topology" is the property that comes into being by provisioning of sessions in a particular way.


> §4.2
>  "A second example of escape is when attributes are expected to change at next hop reset boundaries. While this is typically the case for eBGP, this could be done elsewhere within a network by configuration. One example of this is the BGP Entropy Label feature [RFC6790]. A second example is the BGP Prefix-SID feature [RFC8669]."
>  For BGP ELC, I woud not say that the attribute is expected to change at next hop reset boundaries. Quite the contrary, I'd say that it may change but in general it's not expected to change (it does not change along the MPLS LSP of this FEC/NLRI, including when BGP NH is changed (and label swap is performed). cfhttps://datatracker.ietf.org/doc/html/rfc6790#section-5.2
>  For BGP Prefix SID, although I've not re-read the RFC in full detail, I don't think that for SR-MPLS the attribute is expected to change. (also there is no match for "hop" nor "next" in the text of the RFC so this looks suspicious) https://www.rfc-editor.org/info/rfc8669/

I think this is addressed by the text "are expected to be evaluated at next hop reset boundaries" rather than "changed".  

The intention here is to suggest that each of the listed features has to consider what to do when a next hop is updated.  If it's updated and the associated extension isn't exercised appropriately, we get bugs.  The general case of this has been that an ignorant BGP speaker alters the next hop and since the associated attributes may not have appropriate mechanisms to see that it's no longer appropriately coupled to that next hop, we can get issues.


>  ---
> §4.3
> "A third example of escape is when attributes leak across AFI/SAFIs."
> +10 thanks.
> I'd propose to add "For example" before "Layer-3 VPNs [RFC4364]", as there are other cases. e.g. 6PE.

Done.

> Also there may also be filtering consideration for attribute from the CE to the PE. (CsC for example, but not only)

Currently: "attributes attached to those routes that are solely for use within the scope of the provider network and not intended for the customer network, need to be filtered when the route is again placed in a customer network context. "

Would you suggest different text?

> §4.5
> At this point, I'm not convinced that this whole section is specific to attribute escape (vs any/all attributes).
> One part is error handling, which have been greatly improved by RFC 7606. (Thanks to authors/WG).
> One part is implementation bugs. (improvements have been less obvious)
>  To me, this is applicable to all BGP attributes, and not specific to attribute escape. (quite the contrary, attribute which are supposed to be scoped, seems less likely to trigger the two above issues)

I agree with your points.  However, I think it's important for this document to discuss the role that escape has in being the reason we're seeing some of these issues.

As our favorite well known example, and a leading motivator for RFC 7606, inconsistent deployment of code related to RFC 6368 caused us grief.  When old versions and new versions of the feature interacted across the Internet, we got our outage.  Locally, the old and new implementations did fine as long as they were standalone.  Implementations of the feature on the vendor (hi!) stripped the attribute fine at our boundaries... but they'd leak out via ignorant implementations due to escape.

Had the feature been designed to avoid escape, the entire class of this outage likely would have been mitigated.

We now do evaluations of the impacts of such escape on our new features for this reason.

Your point perhaps is there are deeper considerations covering error handling.  Some of those might belong in 4271bis.  Perhaps a github issue should be created to track that?

>  ---
> §5.1
> "Once a policy has been devised for the deployment, it must be consistent deployed to have good effect."
> I'd partially disagree with this sentence:
> - It's not required to be consistently deployed
> - partial deployment provides partial benefit.

I'll update this to "they should be consistently deployed". (We're thus setting up the next bcp14 fight.) But my thought here is we shouldn't be recommending the installation of leaky balloons.  The air will get out.

>  ---
> §5.1
> "Aggressive filtering"
>  The word "aggressive" seems on the judgement side.

I'm sure the entirety of IDR has noted that I'm quite judgmental.  In this case my intent was rather pejorative.

> I'd prefer another choice of word. e.g. "indiscriminate", but you’re way more qualified than me to propose a word.

... but I can be talked into using a different word.

>  ---
> §5.1
> "Aggressive filtering may be more reasonable in some contexts. For example, a Layer-3 VPN customer may benefit from aggressive default Path Attribute filtering as it provides protection from attribute escape from their provider."
>  It's funny as a priori I'd probably have a different opinion. VPN is a service provided by the SP to interconnect customer sites. As a customer, I would typically expect that the SP be transparent in both my dataplane packets and by control plane signaling. Whereas in the Internet, packets are explicitly best effort and could possibly be filtered (e.g. specific IPv6 Extension header, specific (infrastructure/SRv6) destinations addresses, under provisionned peering links...) and I'm not sure that there are specific rules mandating transparency of BGP attributes (and may be filtering unallocated IANA attributes would help to police codepoint squatting. Yes, this would need to be dynamic, but less volume/dynamicity than for RPKI so probably doable if the motivation were there)

I understand your opinion.  And operationally what one would hope for accomplishing exactly these roles would be more consistent use of the attr-set feature to tunnel the VPN customer's BGP updates and their chosen attributes across a provider backbone as unmolested as possible.

We don't see that.  And as we note elsewhere, we don't have the best cleanup and sanitization of provider network interactions or VPN feature interactions.  Similarly, implementations make it rather too hard to do certain types of scrubbings that may lead to inadvertent or active attacks on VPN forwarding.

Implementations can do better.  We likely should encode broad operational advice about such things, probably as part of the work in GROW. (I'd suggest you contribute text from your personal experience!)

But in the absence of better procedures, many service providers will treat routes cross a BGP VPN as needing to run through the autoclave in both directions.


>  ---
> §5.2
> " It is important that implementors and vendors translate these filtering requirements into easy to configure mechanisms for enforcement."
>  What about adding IETF standard yang model?

Possibly. Part of the motivation for this document going out at this time for adoption along with OAD and other attribute filtering threads is to try to get some forward motion on establishing the best practices and toolsets.

>  ---
> §5.2
> "Current IETF practice is to include an Operational Considerations ([RFC5706]) section in its documents."
>  "Current IETF practice" Really?? 😉

See my prior rants to wgchairs about this. :-)


> BTW, this document is missing one 😉, even so it's partially about operational considerations.

... and this document is an example of why a universal requirement for such a section is problematic.  The scope of the document thus far is protocol and implementation design considerations.  Some of the items will translate to operational considerations - but would be scoped to discussion of a particular sub-topic.  Unnecessary repetition doesn't help document clarity.

(Cue the next fight with the IESG...)

> §5.3.1
>  "New features that are intended to be AS-Scoped SHOULD consider including an scoping AS number, or AS number list, as part of the attribute."
>  As of today, I find the "SHOULD" a bit strong. Especially since this may be one solution, but there may be other equally valid.

For this item, I'll be retaining it until an explicitly better option is added.

> I would also suggest referring to OAD (draft/scoping). (and +1 to propose/evaluate the choice of a single AS number to provide the OAD scope)

I find the OAD procedures feeble and fragile.  But that's a rant for a different reply.  I'm supportive of the desire for the work though.

>  ---
> §5.3.2
>  "New features that are intended to next hop scope SHOULD consider including the next hop that was last present when the feature is being used."
>  I'm biased, but I would primarily advise to rather use NHC when applicable. For two reasons:
> - NHC being older and already partly implemented/deployed, the filtering infrastructure is pre-existent. (while if it's not with a new transitive attribute, by hypothesis non-compliant ASBR won't be able to filter. Attribute escape again)
> - The NH filtering trick is not totally trivial nor perfect. Starting again from scratch seems more likely to make errors again rather than benefit from past experience.

The intention for this section was to indicate we had something already in the toolbox but describe the motivation.

For this document, I'd rather not have the form "Use this feature for this mitigation".  Then again, post adoption, that might be what the WG wants.

>  ---
> §5.3.3
> "When protocol extensions make use of registered code points"
> What about refering to "protocol extension" making use of unregistering code points (aka squatting).

I think this is mostly fixed by removing "registered".  The intention here is "the registry may tell us what to expect the behavior to be".


> This section could be the place to discuss the filtering of squatted code points. (and if implementation dynamically read the IANA registry, we could also add a scoping/filtering column in the IANA registry to allow non-compliant implementation to automatically filter new unknown attributes.)

For the moment, I'd recommend that the document stay with the issue of escape and its mitigation.

I believe we'll be seeing more explicit documents covering mitigation techniques, toolings, and lists.  

Robert's request to list current leaky attributes will probably start the bridge for that discussion.

-- Jeff