--- 1/draft-ietf-idr-error-handling-08.txt 2014-05-19 13:14:26.709411826 -0700 +++ 2/draft-ietf-idr-error-handling-09.txt 2014-05-19 13:14:26.741412604 -0700 @@ -1,23 +1,23 @@ Internet Engineering Task Force E. Chen, Ed. Internet-Draft Cisco Systems, Inc. Updates: 1997, 4271, 4360, 4456, 4760, 5701(if approved) J. Scudder, Ed. Intended status: Standards Track Juniper Networks -Expires: November 15, 2014 P. Mohapatra +Expires: November 20, 2014 P. Mohapatra Sproute Networks K. Patel Cisco Systems, Inc. - May 14, 2014 + May 19, 2014 Revised Error Handling for BGP UPDATE Messages - draft-ietf-idr-error-handling-08 + draft-ietf-idr-error-handling-09 Abstract According to the base BGP specification, 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 as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the @@ -35,21 +35,21 @@ 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 http://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 November 15, 2014. + This Internet-Draft will expire on November 20, 2014. Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -82,21 +82,21 @@ 4.2. Syntactic Correctness of NLRI Fields . . . . . . . . . . 7 4.3. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 6. Error Handling Procedures for Existing Attributes . . . . . . 9 6.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 10 6.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 10 6.5. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . 10 6.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 10 - 6.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 10 6.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 11 6.9. Extended Community . . . . . . . . . . . . . . . . . . . 11 6.10. IPv6 Address Specific BGP Extended Community Attribute . 11 6.11. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 12 6.12. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12 6.13. MP_REACH_NLRI and MP_UNREACH_NLRI . . . . . . . . . . . . 12 7. Guidance for Authors of BGP Specifications . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 @@ -212,21 +212,23 @@ New Text: If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the attribute MUST be treated as malformed and the treat-as-withdraw approach used, unless the specification for the attribute mandates different handling for incorrect Attribute Flags. d. If any of the well-known mandatory attributes are not present in - an UPDATE message, then "treat-as-withdraw" MUST be used. + an UPDATE message, then "treat-as-withdraw" MUST be used. (Note + that [RFC4760] reclassifies NEXT_HOP as what is effectively + discretionary.) e. "Treat-as-withdraw" MUST be used for the cases that specify a session reset and involve any of the attributes ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, or LOCAL_PREF. f. "Attribute discard" MUST be used for any of the cases that specify a session reset and involve ATOMIC_AGGREGATE or AGGREGATOR. g. If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760] @@ -261,35 +263,26 @@ this part of [RFC4271] Section 6.3 necessarily continues to apply: The NLRI field in the UPDATE message is checked for syntactic validity. If the field is syntactically incorrect, then the Error Subcode MUST be set to Invalid Network Field. 4. Parsing of NLRI Fields To facilitate the determination of the NLRI field in an UPDATE with a - malformed attribute, the following restrictions on encoding NLRI MUST - be followed: - - o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL - be encoded as the very first path attribute in an UPDATE. - - o The MP_REACH_NLRI or MP_UNREACH_NLRI SHALL NOT be combined in the - same UPDATE message. - - o The MP_REACH_NLRI and MP_UNREACH_NLRI attributes MUST NOT be used - in an UPDATE that also contains a non-empty Withdrawn Routes or - Network Layer Reachability Information field. - - In all these cases, however, an implementation MUST still be prepared - to receive these fields in any position or combination. + malformed attribute, an UPDATE message MUST NOT contain more than one + of the following: non-empty Withdrawn Routes field, non-empty Network + Layer Reachability Information field, MP_REACH_NLRI attribute, and + MP_UNREACH_NLRI attribute. Since older BGP speakers may not + implement these restrictions, an implementation MUST still be + prepared to receive these fields in any position or combination. If the encoding of [RFC4271] is used, the NLRI field for the IPv4 unicast address family is carried immediately following all the attributes in an UPDATE. When such an UPDATE is received, we observe that the NLRI field can be determined using the "Message Length", "Withdrawn Route Length" and "Total Attribute Length" (when they are consistent) carried in the message instead of relying on the length of individual attributes in the message. 4.1. Attribute Length Fields @@ -321,36 +314,37 @@ The NLRI field or Withdrawn Routes field SHALL be considered "syntactically incorrect" if either of the following are true: o The length of any of the included NLRI is greater than 32, o When parsing NLRI contained in the field, the length of the last NLRI found exceeds the amount of unconsumed data remaining in the field. - Similarly, the MP_REACH or MP_UNREACH attribute of an update SHALL be - considered to be incorrect if any of the following are true: + Similarly, the MP_REACH_NLRI or MP_UNREACH_NLRI attribute of an + update SHALL be considered to be incorrect if any of the following + are true: o The length of any of the included NLRI is inconsistent with the given AFI/SAFI (for example, if an IPv4 NLRI has a length greater than 32 or an IPv6 NLRI has a length greater than 128), o When parsing NLRI contained in the attribute, the length of the last NLRI found exceeds the amount of unconsumed data remaining in the attribute. o The attribute flags of the attribute are inconsistent with those specified in [RFC4760]. - o The length of the MP_UNREACH attribute is less than 3, or the - length of the MP_REACH attribute is less than 5. + o The length of the MP_UNREACH_NLRI attribute is less than 3, or the + length of the MP_REACH_NLRI attribute is less than 5. 4.3. Typed NLRI Certain address families, for example MVPN [RFC7117] and EVPN [I-D.ietf-l2vpn-evpn] have NLRI that are typed. Since supported type values within the address family are not expressed in the MP-BGP capability [RFC4760], it is possible for a BGP speaker to advertise support for the given address family and sub-address family while still not supporting a particular type of NLRI within that AFI/SAFI. @@ -445,21 +439,21 @@ incorrect according to [RFC4271]. An UPDATE message with a malformed NEXT_HOP attribute SHALL be handled using the approach of "treat-as-withdraw". 6.4. MULTI_EXIT_DISC The attribute is considered malformed if its length is not 4 [RFC4271]. - An UPDATE message with a malformed MULTI_EXIT_DESC attribute SHALL be + An UPDATE message with a malformed MULTI_EXIT_DISC attribute SHALL be handled using the approach of "treat-as-withdraw". 6.5. LOCAL_PREF The error handling of [RFC4271] is revised as follows. o If the LOCAL_PREF attribute is received from an external neighbor, it SHALL be discarded using the approach of "attribute discard", or @@ -589,26 +583,26 @@ optional transitive attribute that is not recognized by intervening routers (which thus propagate the attribute unchecked) but that causes session resets when it reaches routers that do recognize the given attribute type. In other respects, this specification does not change BGP's security characteristics. 10. Acknowledgements - The authors wish to thank Juan Alcaide, Ron Bonica, Mach Chen, Andy - Davidson, Bruno Decraene, Rex Fernando, Jeff Haas, Chris Hall, Joel - Halpern, Dong Jie, Akira Kato, Miya Kohno, Tony Li, Alton Lo, Shin - Miyakawa, Tamas Mondal, Jonathan Oddy, Tony Przygienda, Robert - Raszuk, Yakov Rekhter, Eric Rosen, Shyam Sethuram, Rob Shakir, - Naiming Shen, Adam Simpson, Ananth Suryanarayana, Kaliraj + The authors wish to thank Juan Alcaide, Deniz Bahadir, Ron Bonica, + Mach Chen, Andy Davidson, Bruno Decraene, Rex Fernando, Jeff Haas, + Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Tony Li, + Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Tony + Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen, Shyam Sethuram, + Rob Shakir, Naiming Shen, Adam Simpson, Ananth Suryanarayana, Kaliraj Vairavakkalai, Lili Wang and Ondrej Zajicek for their observations and discussion of this topic, and review of this document. 11. References 11.1. Normative References [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.