--- 1/draft-ietf-idr-error-handling-13.txt 2014-09-03 13:14:37.070645743 -0700 +++ 2/draft-ietf-idr-error-handling-14.txt 2014-09-03 13:14:37.102646539 -0700 @@ -1,23 +1,23 @@ 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 15, 2014 K. Patel +Expires: March 7, 2015 K. Patel Cisco Systems, Inc. - June 13, 2014 + September 3, 2014 Revised Error Handling for BGP UPDATE Messages - draft-ietf-idr-error-handling-13 + draft-ietf-idr-error-handling-14 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 December 15, 2014. + This Internet-Draft will expire on March 7, 2015. 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 @@ -83,40 +83,40 @@ 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 . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 12 - 7.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 11 + 7.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 11 7.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 12 7.9. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 12 - 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 13 + 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12 7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13 - 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 14 - 7.13. Traffic Engineering path attribute . . . . . . . . . . . 14 - 7.14. Extended Community . . . . . . . . . . . . . . . . . . . 14 + 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 13 + 7.13. Traffic Engineering path attribute . . . . . . . . . . . 13 + 7.14. Extended Community . . . . . . . . . . . . . . . . . . . 13 7.15. IPv6 Address Specific BGP Extended Community Attribute . 14 - 7.16. BGP Entropy Label Capability Attribute . . . . . . . . . 15 - 7.17. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.16. BGP Entropy Label Capability Attribute . . . . . . . . . 14 + 7.17. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Guidance for Authors of BGP Specifications . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 12.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 12.2. Informative References . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 @@ -473,32 +473,22 @@ [RFC4271] also says that an implementation optionally "MAY check whether the leftmost ... AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message". A BGP implementation SHOULD also handle routes that violate this check using "treat-as-withdraw", but MAY follow the session reset behavior if configured to do so. 7.3. NEXT_HOP - 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 SHOULD provide a means to modify - the list of invalid host addresses by configuration -- these are - sometimes referred to as "Martians". + The attribute is considered malformed if its length is not 4 + [RFC4271]. 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]. An UPDATE message with a malformed MULTI_EXIT_DISC attribute SHALL be @@ -571,55 +561,32 @@ neighbor, it SHALL be discarded using the approach of "attribute discard", or o if received from an internal neighbor, it SHALL be considered malformed if its length is not a nonzero multiple of 4. If malformed, the UPDATE SHALL be handled using the approach of "treat-as-withdraw". 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 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 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". + If the Length of Next Hop Network Address field of the MP_REACH + attribute is inconsistent with that which was expected, the attribute + is considered malformed. Since the next hop precedes the NLRI field + in the attribute, in this case it will not be possible to reliably + locate the NLRI, and thus the "session reset" or "AFI/SAFI disable" + approach MUST be used. - o An implementation SHOULD provide a means to modify the list of - invalid host addresses by configuration -- these are sometimes - referred to as "Martians". + "That which was expected", while somewhat vague, is intended to + encompass the next hop specified for the Address Family Identifier + and Subsequent Address Family Identifier fields and potentially + modified by any extensions in use. For example, if [RFC5549] is in + use then the next hop would have to have a length of 4 or 16. 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 @@ -737,30 +704,20 @@ and discussion of this topic, and review of this document. 12. References 12.1. Normative References [IANA-BGP-ATTRS] "BGP Path Attributes", . - [IANA-IPV4] - "IANA IPv4 Special-Purpose Address Registry", - . - - [IANA-IPV6] - "IANA IPv4 Special-Purpose Address Registry", - . - [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended @@ -797,27 +754,23 @@ 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. + [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network + Layer Reachability Information with an IPv6 Next Hop", RFC + 5549, May 2009. [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