Internet Engineering Task Force B. Decraene Internet-Draft Orange Updates: 7606 (if approved) J. G. Scudder Intended status: Standards Track HPE Expires: 18 April 2026 15 October 2025 NLRI Error handling draft-decraene-idr-nlri-error-handling-00 Abstract RFC 7606 partially revises the error handling for BGP UPDATE messages. It reduces the cases of BGP session reset by defining and using less impactful error handling approaches, such as attribute discard and treat-as-withdraw when applicable. The treat-as-withdraw approach requires that the entire NLRI field of the MP_REACH_NLRI attribute be successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. This is exacerbated by the use of non-key data within NLRI, which introduces parsing complexity and additional error cases. This specification defines a non-transitive BGP attribute, the "Treat-As-Withdraw Attribute", to encode NLRIs as per the format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as- withdraw error-handling approach to be used in case an error in the MP_UNREACH_NLRI attribute prevents the parsing of its NLRIs. This document updates RFC 7606 by mandating that the Treat-As- Withdraw Attribute appear before the MP_REACH_NLRI (or any other) attribute in an UPDATE message. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 April 2026. Decraene & Scudder Expires 18 April 2026 [Page 1] Internet-Draft NLRI Error handling October 2025 Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Treat-As-Withdraw Attribute . . . . . . . . . . . . . . . . . 3 3. Sending the Treat-As-Withdraw Attribute . . . . . . . . . . . 4 4. Receiving the Treat-As-Withdraw Attribute . . . . . . . . . . 4 5. Treat-As-Withdraw attribute Error Handling . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction According to the base BGP specification [RFC4271], a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset impacts not only routes with the offending attribute but also other valid routes exchanged over the session. Decraene & Scudder Expires 18 April 2026 [Page 2] Internet-Draft NLRI Error handling October 2025 [RFC7606] revises BGP error handling, with the goal of minimizing the impact on routing of a malformed UPDATE message, while maintaining protocol correctness to the extent possible. For most BGP attributes, a malformed attribute may be handled using attribute discard or treat-as-withdraw. Both approaches preserve the routing of all the NLRIs not advertised in the affected BGP UPDATE message. However, as indicated in Section 3 of [RFC7606], treat-as-withdraw can only be used if the entire NLRI field of the MP_REACH_NLRI attribute is successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. [RFC4760] allows the Border Gateway Protocol (BGP) to advertise general routing information in the Network Layer Reachability Information (NLRI) field of the UPDATE message. Some specifications, such as [RFC8277], [I-D.ietf-idr-bgp-car], and [I-D.ietf-idr-bgp-ct] carry both a key field and a non-key field in the NLRI. The key field is typically the real NLRI. The non-key field carries extra data that is NLRI-specific and hence not located in the BGP path attributes for packing optimization purposes. For example, [RFC8277] carries the Prefix in the key field and one label (stack) in the non- key field. As another example, [I-D.ietf-idr-bgp-car] defines a BGP CAR SAFI explicitly carrying Key Fields and Non-Key Fields as a list of TLVs. In case of a BGP withdraw, the key is indicated in the MP_UNREACH_NLRI attribute to withdraw the unfeasible routes, while the non-key data is typically not encoded. This specification defines a new BGP non-transitive attribute, the "Treat-As-Withdraw Attribute", to carry the NLRIs using the simple and existing format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as-withdraw error-handling approach to be used when there is an error in the MP_UNREACH_NLRI attribute that prevents the parsing of its NLRIs. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Treat-As-Withdraw Attribute The Treat-As-Withdraw attribute is an optional, non-transitive BGP path attribute with type code TBD1. The format of the Treat-As- Withdraw attribute is the same as the format of the MP_UNREACH_NLRI as defined in Section 4 of [RFC4760]. Decraene & Scudder Expires 18 April 2026 [Page 3] Internet-Draft NLRI Error handling October 2025 3. Sending the Treat-As-Withdraw Attribute The Treat-As-Withdraw attribute may be sent in any BGP UPDATE message carrying the MP_REACH_NLRI attribute. It MUST NOT be sent in an UPDATE message not carrying the MP_REACH_NLRI attribute. To facilitate the determination of the NLRI field in an UPDATE message with a malformed attribute, the Treat-As-Withdraw SHALL be encoded as the very first path attribute in an UPDATE message, followed by the MP_REACH_NLRI attribute. (This represents an update to Section 5.1 [RFC7606], which mandated that the MP_REACH_NLRI come first.) The ordering of NLRIs within the Treat-As-Withdraw MUST be the same as their ordering within the corresponding MP_REACH_NLRI. If the AFI/SAFI specification allows for different NLRI encodings in the MP_UNREACH_NLRI, the sender MUST use the simplest encoding. The receiver MUST accept any valid encoding. For example, [RFC3107] allows the use of either the MPLS label stack originally sent or the static 0x800000 value. The latter is simpler in that the size is smaller, fixed, and the number of labels to parse is minimized. The Treat-As-Withdraw attribute is generally useful as its encoding is simpler than the encoding of the MP_REACH_NLRI, hence it maximizes the chances of handling an error in the MP_REACH_NLRI attribute using the treat-as-withdraw approach. It is specifically useful for AFI/ SAFI carrying non-key data in the NLRI such as [RFC8277], [I-D.ietf-idr-bgp-car], and [I-D.ietf-idr-bgp-ct] as these NLRI are longer and more complex, hence have a higher probability of error. In addition, in case of error, they have a lower probability of being able to parse the full list of NLRIs. 4. Receiving the Treat-As-Withdraw Attribute An UPDATE message with a malformed MP_REACH_NLRI attribute and a correctly formed Treat-As-Withdraw attribute SHALL be handled using the approach of "treat-as-withdraw". The UPDATE message SHALL be handled as if received with only the Treat-As-Withdraw attribute - all other attributes being ignored - and the Treat-As-Withdraw Attribute handled as an MP_UNREACH_NLRI attribute. In the case of an UPDATE message with a correctly formed MP_REACH_NLRI attribute, the Treat-As-Withdraw attribute SHOULD be parsed and its list of NLRI compared to the list of NLRI present in the MP_REACH_NLRI attribute. In case of difference, the Treat-As- Withdraw attribute SHALL be ignored. However, because this reveals an error in either the Treat-As-Withdraw attribute or the MP_REACH_NLRI attribute, a BGP speaker must provide debugging facilities to permit issues caused by a malformed attribute to be diagnosed. At a minimum, such facilities must include logging an Decraene & Scudder Expires 18 April 2026 [Page 4] Internet-Draft NLRI Error handling October 2025 error listing the NLRI involved and containing the entire malformed UPDATE message when such an attribute is detected. The malformed UPDATE message should be analyzed, and the root cause should be investigated. 5. Treat-As-Withdraw attribute Error Handling The Treat-As-Withdraw attribute has the same format as the MP_UNREACH_NLRI and hence has the same conditions under which it is considered malformed. As per Section 4, an UPDATE message with a malformed Treat-As-Withdraw attribute is handled using the approach of "attribute discard". 6. IANA Considerations IANA is requested to allocate a new optional, non-transitive attribute called "Treat-As-Withdraw" from the BGP Path Attributes registry of the Border Gateway Protocol (BGP) Parameters group. +=======+===================+============+ | Value | Code | Reference | +=======+===================+============+ | TBD1 | Treat-As-Withdraw | (this doc) | +-------+-------------------+------------+ Table 1 7. Security Considerations The Treat-As-Withdraw attribute does not change BGP security considerations. An attacker having the ability to send or modify a BGP Message has the ability to withdraw any NLRI, with or without the Treat-As-Withdraw attribute. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Decraene & Scudder Expires 18 April 2026 [Page 5] Internet-Draft NLRI Error handling October 2025 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . [I-D.ietf-idr-bgp-car] Rao, D. and S. Agrawal, "BGP Color-Aware Routing (CAR)", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-car- 16, 20 February 2025, . [I-D.ietf-idr-bgp-ct] Vairavakkalai, K. and N. Venkataraman, "BGP Classful Transport Planes", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ct-39, 28 February 2025, . Authors' Addresses Bruno Decraene Orange Email: bruno.decraene@orange.com Decraene & Scudder Expires 18 April 2026 [Page 6] Internet-Draft NLRI Error handling October 2025 John G. Scudder HPE Email: jgs@juniper.net Decraene & Scudder Expires 18 April 2026 [Page 7]