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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/