draft-ietf-idr-error-handling-02.txt   draft-ietf-idr-error-handling-03.txt 
Internet Engineering Task Force (IETF) J. Scudder Internet Engineering Task Force (IETF) J. Scudder
Internet Draft Juniper Networks Internet Draft Juniper Networks
Update: 1997, 4271, 4360 (if approved) E. Chen Update: 1997, 4271, 4360, 5701 (if approved) E. Chen
Intended Status: Standards Track P. Mohapatra Intended Status: Standards Track P. Mohapatra
Expires: December 18, 2012 K. Patel Expires: May 22, 2013 K. Patel
Cisco Systems Cisco Systems
June 17, 2012 November 21, 2012
Revised Error Handling for BGP UPDATE Messages Revised Error Handling for BGP UPDATE Messages
draft-ietf-idr-error-handling-02.txt draft-ietf-idr-error-handling-03.txt
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
authors of documents defining new attributes. Finally, it revises authors of documents defining new attributes. Finally, it revises
the error handling procedures for several existing attributes. the error handling procedures for a number of existing attributes.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 18, 2012. This Internet-Draft will expire on May 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 46 skipping to change at page 2, line 46
The goal for revising the error handling for UPDATE messages is to The goal for revising the error handling for UPDATE messages is to
minimize the impact on routing by a malformed UPDATE message, while minimize the impact on routing by a malformed UPDATE message, while
maintaining protocol correctness to the extent possible. This can be maintaining protocol correctness to the extent possible. This can be
achieved largely by maintaining the established session and keeping achieved largely by maintaining the established session and keeping
the valid routes exchanged, but removing the routes carried in the the valid routes exchanged, but removing the routes carried in the
malformed UPDATE from the routing system. malformed UPDATE from the routing system.
This document partially revises the error handling for UPDATE This document partially revises the error handling for UPDATE
messages, and provides guidelines for the authors of documents messages, and provides guidelines for the authors of documents
defining new attributes. Finally, it revises the error handling defining new attributes. Finally, it revises the error handling
procedures for several existing attributes. Specifically, the error procedures for a number of existing attributes. Specifically, the
handling procedures of [RFC4271], [RFC1997], and [RFC4360] are error handling procedures of [RFC4271], [RFC1997], [RFC4360] and
revised. [RFC5701] are revised.
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Revision to Base Specification 2. Revision to Base Specification
The first paragraph of Section 6.3 of [RFC4271] is revised as The first paragraph of Section 6.3 of [RFC4271] is revised as
skipping to change at page 3, line 48 skipping to change at page 3, line 48
The error handling of the following case described in Section 6.3 of The error handling of the following case described in Section 6.3 of
[RFC4271] is revised [RFC4271] is revised
If any recognized attribute has Attribute Flags that conflict with If any recognized attribute has Attribute Flags that conflict with
the Attribute Type Code, then the Error Subcode MUST be set to the Attribute Type Code, then the Error Subcode MUST be set to
Attribute Flags Error. The Data field MUST contain the erroneous Attribute Flags Error. The Data field MUST contain the erroneous
attribute (type, length, and value). attribute (type, length, and value).
as follows: as follows:
If any attribute has Attribute Flags that conflict with the If the "Optional bit" or the "Transitive bit" in the Attribute
Attribute Type Code, then the error SHOULD be logged, and the Flags for an attribute conflicts with the Attribute Type Code,
then the error SHOULD be logged, and the conflicting bit in the
Attribute Flags MUST be reset to the correct value. The UPDATE Attribute Flags MUST be reset to the correct value. The UPDATE
message MUST continue to be processed. message MUST continue to be processed.
The error handling of all other cases described in Section 6.3 of The error handling of all other cases described in Section 6.3 of
[RFC4271] that specify a session reset is revised as follows. [RFC4271] that specify a session reset is revised as follows.
When a path attribute in an UPDATE message is determined to be When a path attribute (other than the MP_REACH_NLRI attribute
malformed, the UPDATE message containing that attribute MUST be [RFC4760] or the MP_UNREACH_NLRI attribute [RFC4760]) in an UPDATE
treated as though all contained routes had been withdrawn just as if message is determined to be malformed, the UPDATE message containing
they had been listed in the WITHDRAWN ROUTES field (or in the that attribute MUST be treated as though all contained routes had
MP_UNREACH_NLRI attribute [RFC4760bis] if appropriate) of the UPDATE been withdrawn just as if they had been listed in the WITHDRAWN
message, thus causing them to be removed from the Adj-RIB-In ROUTES field (or in the MP_UNREACH_NLRI attribute if appropriate) of
according to the procedures of [RFC4271]. In the case of an the UPDATE message, thus causing them to be removed from the Adj-RIB-
In according to the procedures of [RFC4271]. In the case of an
attribute which has no effect on route selection or installation, the attribute which has no effect on route selection or installation, the
malformed attribute MAY instead be discarded and the UPDATE message malformed attribute MAY instead be discarded and the UPDATE message
continue to be processed. For the sake of brevity, the former continue to be processed. For the sake of brevity, the former
approach is termed "treat-as-withdraw", and the latter as "attribute approach is termed "treat-as-withdraw", and the latter as "attribute
discard". discard".
If any of the well-known mandatory attributes are not present in an
UPDATE message, then the approach of "treat-as-withdraw" MUST be used
for the error handling.
The approach of "treat-as-withdraw" MUST be used for the error The approach of "treat-as-withdraw" MUST be used for the error
handling of the cases described in Section 6.3 of [RFC4271] that handling of the cases described in Section 6.3 of [RFC4271] that
specify a session reset and involve any of the following attributes: specify a session reset and involve any of the following attributes:
ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, and LOCAL_PREF. ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, and LOCAL_PREF.
The approach of "attribute discard" MUST be used for the error The approach of "attribute discard" MUST be used for the error
handling of the cases described in Section 6.3 of [RFC4271] that handling of the cases described in Section 6.3 of [RFC4271] that
specify a session reset and involve any of the following attributes: specify a session reset and involve any of the following attributes:
ATOMIC_AGGREGATE and AGGREGATOR. ATOMIC_AGGREGATE and AGGREGATOR.
If an attribute appears more than once in an UPDATE message, then all If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI attribute
the occurrences of the attribute other than the first one SHALL be appears more than once in the UPDATE message, then a NOTIFICATION
discarded and the UPDATE message continue to be processed. message MUST be sent with the Error Subcode "Malformed Attribute
List". If any other attribute appears more than once in an UPDATE
message, then all the occurrences of the attribute other than the
first one SHALL be discarded and the UPDATE message continue to be
processed.
When multiple malformed attributes exist in an UPDATE message, if the When multiple malformed attributes exist in an UPDATE message, if the
same approach (either "treat-as-withdraw" or "attribute discard") is same approach (either "session reset", or "treat-as-withdraw" or
specified for the handling of these malformed attributes, then the "attribute discard") is specified for the handling of these malformed
specified approach MUST be used. Otherwise "treat-as-withdraw" MUST attributes, then the specified approach MUST be used. Otherwise the
be used. approach with the strongest action MUST be used following the order
of "session reset", "treat-as-withdraw" and "attribute discard" from
the strongest to the weakest.
A document which specifies a new attribute MUST provide specifics A document which specifies a new attribute MUST provide specifics
regarding what constitutes an error for that attribute and how that regarding what constitutes an error for that attribute and how that
error is to be handled. error is to be handled.
Finally, we observe that in order to use the approach of "treat-as- Finally, we observe that in order to use the approach of "treat-as-
withdraw", the entire NLRI field and/or MP_REACH and MP_UNREACH withdraw", the entire NLRI field and/or the MP_REACH_NLRI and
[RFC4760bis] attributes need to be successfully parsed. If this is MP_UNREACH_NLRI attributes need to be successfully parsed. If this
not possible, the procedures of [RFC4271] continue to apply. is not possible, the procedures of [RFC4271] continue to apply.
Alternatively the error handling procedures specified in [RFC4760bis] Alternatively the error handling procedures specified in [RFC4760]
for disabling a particular AFI/SAFI MAY be followed. for disabling a particular AFI/SAFI MAY be followed.
3. Parsing of NLRI Fields 3. 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 MP_REACH or MP_UNREACH attribute (if malformed attribute, the MP_REACH_NLRI or MP_UNREACH_NLRI attribute
present) SHOULD be encoded as the very first path attribute in an (if present) SHALL be encoded as the very first path attribute in an
UPDATE as recommended by [RFC4760bis]. An implementation, however, UPDATE. An implementation, however, MUST still be prepared to
MUST still be prepared to receive these fields in any position. receive these fields in any position.
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. Operational Considerations 4. Operational Considerations
skipping to change at page 6, line 19 skipping to change at page 6, line 32
side effects. side effects.
Because of these potential issues, a BGP speaker MUST provide Because of these potential issues, a BGP speaker MUST provide
debugging facilities to permit issues caused by a malformed attribute debugging facilities to permit issues caused by a malformed attribute
to be diagnosed. At a minimum, such facilities MUST include logging to be diagnosed. At a minimum, such facilities MUST include logging
an error listing the NLRI involved, and containing the entire an error listing the NLRI involved, and containing the entire
malformed UPDATE message when such an attribute is detected. The malformed UPDATE message when such an attribute is detected. The
malformed UPDATE message SHOULD be analyzed, and the root cause malformed UPDATE message SHOULD be analyzed, and the root cause
SHOULD be investigated. SHOULD be investigated.
5. Error Handling Procedures for Existing Optional Attributes 5. Error Handling Procedures for Existing Attributes
5.1. AGGREGATOR 5.1. ORIGIN
The error handling of [RFC4271] is revised as follows: The attribute is considered malformed if its length is not 1, or it
has an undefined value [RFC4271].
An UPDATE message with a malformed ORIGIN attribute SHALL be handled
using the approach of "treat-as-withdraw".
5.2. AS_PATH
The error conditions for the attribute have been defined in
[RFC4271].
An UPDATE message with a malformed AS_PATH attribute SHALL be handled
using the approach of "treat-as-withdraw".
5.3. NEXT_HOP
The error conditions for the NEXT_HOP attribute have been defined in
[RFC4271].
An UPDATE message with a malformed NEXT_HOP attribute SHALL be
handled using the approach of "treat-as-withdraw".
5.4. MULTI_EXIT_DESC
The attribute is considered malformed if its length is not 4
[RFC4271].
An UPDATE message with a malformed MULTI_EXIT_DESC attribute SHALL be
handled using the approach of "treat-as-withdraw".
5.5. LOCAL_PREF
The attribute is considered malformed if its length is not 4
[RFC4271].
An UPDATE message with a malformed LOCAL_PREF attribute SHALL be
handled as follows:
o using the approach of "attribute discard" if the UPDATE message
is received from an external neighbor, or
o using the approach of "treat-as-withdraw" if the UPDATE message
is received from an internal neighbor.
In addition, if the attribute is present in an UPDATE message from an
external neighbor, the approach of "attribute discard" SHALL be used
to handle the unexpected attribute in the message.
5.6. ATOMIC_AGGREGATE
The attribute SHALL be considered malformed if its length is not 0
[RFC4271].
An UPDATE message with a malformed ATOMIC_AGGREGATE attribute SHALL
be handled using the approach of "attribute discard".
5.7. AGGREGATOR
The error conditions specified in [RFC4271] for the attribute are
revised as follows:
The AGGREGATOR attribute SHALL be considered malformed if any of the The AGGREGATOR attribute SHALL be considered malformed if any of the
following applies: following applies:
o Its length is not 6 (when the "4-octet AS number capability" is o Its length is not 6 (when the "4-octet AS number capability" is
not advertised to, or not received from the peer [RFC4893]). not advertised to, or not received from the peer [RFC4893]).
o Its length is not 8 (when the "4-octet AS number capability" is o Its length is not 8 (when the "4-octet AS number capability" is
both advertised to, and received from the peer). both advertised to, and received from the peer).
An UPDATE message with a malformed AGGREGATOR attribute SHALL be An UPDATE message with a malformed AGGREGATOR attribute SHALL be
handled using the approach of "attribute discard". handled using the approach of "attribute discard".
5.2. Community 5.8. Community
The error handling of [RFC1997] is revised as follows: The error handling of [RFC1997] is revised as follows:
The Community attribute SHALL be considered malformed if its length The Community attribute SHALL be considered malformed if its length
is not a nonzero multiple of 4. is nonzero and is not a multiple of 4.
An UPDATE message with a malformed Community attribute SHALL be An UPDATE message with a malformed Community attribute SHALL be
handled using the approach of "treat-as-withdraw". handled using the approach of "treat-as-withdraw".
5.3. Extended Community 5.9. Extended Community
The error handling of [RFC4360] is revised as follows: The error handling of [RFC4360] is revised as follows:
The Extended Community attribute SHALL be considered malformed if its The Extended Community attribute SHALL be considered malformed if its
length is not a nonzero multiple of 8. length is nonzero and is not a multiple of 8.
An UPDATE message with a malformed Extended Community attribute SHALL An UPDATE message with a malformed Extended Community attribute SHALL
be handled using the approach of "treat-as-withdraw". be handled using the approach of "treat-as-withdraw".
Note that a BGP speaker MUST NOT treat an unrecognized Extended Note that a BGP speaker MUST NOT treat an unrecognized Extended
Community Type or Sub-Type as an error. Community Type or Sub-Type as an error.
5.10. IPv6 Address Specific BGP Extended Community Attribute
The error handling of [RFC5701] is revised as follows:
The IPv6 Address Specific Extended Community attribute SHALL be
considered malformed if its length is nonzero and is not a multiple
of 20.
An UPDATE message with a malformed IPv6 Address Specific Extended
Community attribute SHALL be handled using the approach of "treat-as-
withdraw".
Note that a BGP speaker MUST NOT treat an unrecognized IPv6 Address
Specific Extended Community Type or Sub-Type as an error.
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
7. Security Considerations 7. Security Considerations
This specification addresses the vulnerability of a BGP speaker to a This specification addresses the vulnerability of a BGP speaker to a
potential attack whereby a distant attacker can generate a malformed potential attack whereby a distant attacker can generate a malformed
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.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Ron Bonica, Mach Chen, Andy Davidson, Dong The authors wish to thank Juan Alcaide, Ron Bonica, Mach Chen, Andy
Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Tony Li, Davidson, Bruno Decraene, Dong Jie, Rex Fernando, Joel Halpern, Akira
Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Robert Raszuk, Kato, Miya Kohno, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal,
Yakov Rekhter, Rob Shakir, Naiming Shen, Shyam Sethuram, Ananth Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, Naiming
Suryanarayana, and Kaliraj Vairavakkalai for their observations and Shen, Shyam Sethuram, Ananth Suryanarayana, Kaliraj Vairavakkalai and
discussion of this topic, and review of this document. Lili Wang for their observations and discussion of this topic, and
review of this document.
9. Normative References 9. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
skipping to change at page 8, line 26 skipping to change at page 10, line 26
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC4760bis] [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760,
"Multiprotocol Extensions for BGP-4", January 2007.
draft-ietf-idr-rfc4760bis-03.txt, work in progress,
August 2011. [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended
Community Attribute", RFC 5701, November 2009.
Appendix A. Why not discard UPDATE messages? Appendix A. Why not discard UPDATE messages?
A commonly asked question is "why not simply discard the UPDATE A commonly asked question is "why not simply discard the UPDATE
message instead of treating it like a withdraw? Isn't that safer and message instead of treating it like a withdraw? Isn't that safer and
easier?" The answer is that it might be easier, but it would easier?" The answer is that it might be easier, but it would
compromise BGP's correctness so is unsafe. Consider the following compromise BGP's correctness so is unsafe. Consider the following
example of what might happen if UPDATE messages carrying bad example of what might happen if UPDATE messages carrying bad
attributes were simply discarded: attributes were simply discarded:
 End of changes. 24 change blocks. 
51 lines changed or deleted 139 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/