--- 1/draft-ietf-idr-error-handling-12.txt 2014-06-13 12:14:25.202267613 -0700 +++ 2/draft-ietf-idr-error-handling-13.txt 2014-06-13 12:14:25.242268562 -0700 @@ -1,55 +1,55 @@ Internet Engineering Task Force E. Chen, Ed. Internet-Draft Cisco Systems, Inc. Updates: 1997, 4271, 4360, 4456, 4760, J. Scudder, Ed. 5543, 5701, 6368, 6790 (if Juniper Networks approved) P. Mohapatra Intended status: Standards Track Sproute Networks -Expires: December 13, 2014 K. Patel +Expires: December 15, 2014 K. Patel Cisco Systems, Inc. - June 11, 2014 + June 13, 2014 Revised Error Handling for BGP UPDATE Messages - draft-ietf-idr-error-handling-12 + draft-ietf-idr-error-handling-13 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 authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, - 4760 and 5701. + 4760, 5543, 5701, 6368 and 6790. 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 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 December 13, 2014. + This Internet-Draft will expire on December 15, 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 @@ -77,46 +77,46 @@ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Error-Handling Approaches . . . . . . . . . . . . . . . . . . 4 3. Revision to BGP UPDATE Message Error Handling . . . . . . . . 4 4. Attribute Length Fields . . . . . . . . . . . . . . . . . . . 6 5. Parsing of NLRI Fields . . . . . . . . . . . . . . . . . . . 7 5.1. Encoding NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Missing NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Syntactic Correctness of NLRI Fields . . . . . . . . . . 8 5.4. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8 6. Operational Considerations . . . . . . . . . . . . . . . . . 9 - 7. Error Handling Procedures for Existing Attributes . . . . . . 9 + 7. Error Handling Procedures for Existing Attributes . . . . . . 10 7.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 11 7.5. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . 11 - 7.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 11 + 7.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 12 7.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 12 7.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 12 7.9. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 12 - 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12 + 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 13 7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13 - 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 13 - 7.13. Traffic Engineering path attribute . . . . . . . . . . . 13 + 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 14 + 7.13. Traffic Engineering path attribute . . . . . . . . . . . 14 7.14. Extended Community . . . . . . . . . . . . . . . . . . . 14 7.15. IPv6 Address Specific BGP Extended Community Attribute . 14 - 7.16. BGP Entropy Label Capability Attribute . . . . . . . . . 14 - 7.17. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.16. BGP Entropy Label Capability Attribute . . . . . . . . . 15 + 7.17. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Guidance for Authors of BGP Specifications . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 12.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + 12.2. Informative References . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. In the case of optional transitive attributes, the behavior is especially troublesome and may @@ -138,21 +138,22 @@ maintaining protocol correctness to the extent possible. This can be achieved largely by maintaining the established session and keeping the valid routes exchanged, but removing the routes carried in the malformed UPDATE from the routing system. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. Specifically, the error handling procedures of [RFC1997], [RFC4271], [RFC4360], - [RFC4456], [RFC4760] and [RFC5701] are revised. + [RFC4456], [RFC4760], [RFC5543], [RFC5701], [RFC6368] and [RFC6790] + are revised. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Error-Handling Approaches In this document we refer to four different approaches to handling @@ -365,26 +366,27 @@ the attribute. o The attribute flags of the attribute are inconsistent with those specified in [RFC4760]. 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. 5.4. 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. + Certain address families, for example MCAST-VPN [RFC6514], MCAST-VPLS + [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. A BGP speaker advertising support for such a typed address family MUST handle routes with unrecognized NLRI types within that address family by discarding them, unless the relevant specification for that address family specifies otherwise. 6. Operational Considerations Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note @@ -481,21 +482,21 @@ According to [RFC4271] the attribute is considered malformed if it is syntactically incorrect. To quote from that document, "Syntactic correctness means that the NEXT_HOP attribute represents a valid IP host address", but it does not go on to define what it means to be a "valid IP host address". Therefore: An IP host address SHOULD be considered invalid if it appears in the "IANA IPv4 Special-Purpose Address Registry" [IANA-IPV4] and either the "destination" or the "forwardable" boolean in that registry is - given as "false". An implementation MAY provide a means to modify + given as "false". An implementation SHOULD provide a means to modify the list of invalid host addresses by configuration -- these are sometimes referred to as "Martians". An UPDATE message with a malformed NEXT_HOP attribute SHALL be handled using the approach of "treat-as-withdraw". 7.4. MULTI_EXIT_DISC The attribute is considered malformed if its length is not 4 [RFC4271]. @@ -577,52 +578,64 @@ 7.11. MP_REACH_NLRI [RFC4760] references the error-handling of the base BGP specification for validation of the next hop. ("The rules for the next hop information are the same as the rules for the information carried in the NEXT_HOP BGP attribute".) Thus just as in Section 7.3 we must consider what it means for the Next Hop field of the MP_REACH attribute to be a "valid host address": - o If the Next Hop field is an IPv4 address, it SHOULD be considered - invalid if it appears in the "IANA IPv4 Special-Purpose Address - Registry" [IANA-IPV4] and either the "destination" or the - "forwardable" boolean in that registry is given as "false". + o If the Next Hop field contains an IPv4 address (possibly as a sub- + field), the field SHOULD be considered invalid if the IPv4 address + appears in the ""IANA IPv4 Special-Purpose Address Registry" + [IANA-IPV4] and either the "destination" or the "forwardable" + boolean in that registry is given as "false". - o If the Next Hop field is an IPv6 address, it SHOULD be considered - invalid if it appears in the "IANA IPv6 Special-Purpose Address - Registry" [IANA-IPV6] and either the "destination" or the - "forwardable" boolean in that registry is given as "false". + o If the Next Hop field contains an IPv6 address (possibly as a sub- + field), the field SHOULD be considered invalid if the IPv6 address + appears in the "IANA IPv6 Special-Purpose Address Registry" + [IANA-IPV6], the address is not an IPv4-mapped IPv6 address, and + either the "destination" or the "forwardable" boolean in that + registry is given as "false". + + o If the Next Hop field contains an IPv4-mapped IPv6 address + (possibly as a sub-field), the field SHOULD be considered invalid + unless the use of such addresses has been explicitly allowed for + the particular AFI/SAFI that occurs in this MP_REACH_NLRI + attribute. (E.g., see [RFC4659] and [RFC4798].) o If the Next Hop field is some other form of address, it should be considered invalid in circumstances analogous to the above -- if it is found in the relevant IANA special-purpose address registry (if any) and its "destination" or "forwardable" boolean is given as "false". - o An implementation MAY provide a means to modify the list of + o An implementation SHOULD provide a means to modify the list of invalid host addresses by configuration -- these are sometimes referred to as "Martians". Section 3 and Section 5 provide further discussion of the handling of this attribute. 7.12. MP_UNREACH_NLRI Section 3 and Section 5 discuss the handling of this attribute. 7.13. Traffic Engineering path attribute - The error handling of [RFC5543] is revised as follows. - - TBD + We note that [RFC5543] does not detail what constitutes + "malformation" for the Traffic Engineering path attribute. A future + update to that specification may provide more guidance. In the + interim, an implementation that determines (for whatever reason) that + an UPDATE message contains a malformed Traffic Engineering path + attribute MUST handle it using the approach of "treat-as-withdraw". 7.14. Extended Community The error handling of [RFC4360] is revised as follows: The Extended Community attribute SHALL be considered malformed if its length is not a nonzero multiple of 8. An UPDATE message with a malformed Extended Community attribute SHALL be handled using the approach of "treat-as-withdraw". @@ -784,20 +797,32 @@ Autonomous System (AS) Number Space", RFC 6793, December 2012. 12.2. Informative References [I-D.ietf-l2vpn-evpn] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- evpn-07 (work in progress), May 2014. + [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, + "BGP-MPLS IP Virtual Private Network (VPN) Extension for + IPv6 VPN", RFC 4659, September 2006. + + [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, + "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 + Provider Edge Routers (6PE)", RFC 4798, February 2007. + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, February 2012. + [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014. Authors' Addresses Enke Chen (editor) Cisco Systems, Inc. Email: enkechen@cisco.com