draft-ietf-idr-optional-transitive-02.txt   draft-ietf-idr-optional-transitive-03.txt 
Internet Engineering Task Force J. Scudder Internet Engineering Task Force J. Scudder
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track E. Chen Intended status: Standards Track E. Chen
Expires: September 27, 2010 Cisco Systems Expires: April 1, 2011 Cisco Systems
March 26, 2010 September 28, 2010
Error Handling for Optional Transitive BGP Attributes Error Handling for Optional Transitive BGP Attributes
draft-ietf-idr-optional-transitive-02.txt draft-ietf-idr-optional-transitive-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 in the case of optional transitive This behavior is undesirable in the case of optional transitive
attributes. This document revises BGP's error-handling rules for attributes. This document revises BGP's error-handling rules for
optional transitive attributes, and provides guidelines for the optional transitive attributes, and provides guidelines for the
authors of documents defining new optional transitive attributes. It authors of documents defining new optional transitive attributes. It
also introduces a new Path Attribute flag, Neighbor-Complete, to also introduces a new Path Attribute flag, Neighbor-Complete, to
allow more accurate fault-finding. Finally, it revises the error allow more accurate fault-finding. Finally, it revises the error
handling procedures for several existing optional transitive handling procedures for several existing optional transitive
attributes. 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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 1, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 10
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
According to the base BGP specification [RFC4271], a BGP speaker that According to the base BGP specification [RFC4271], a BGP speaker that
receives an UPDATE message containing a malformed attribute is receives an UPDATE message containing a malformed attribute is
required to reset the session over which the offending attribute was required to reset the session over which the offending attribute was
received. This behavior is undesirable in the case of optional received. This behavior is undesirable in the case of optional
transitive attributes whose Partial flag is set; the reason is that transitive attributes whose Partial flag is set; the reason is that
such attributes may have been propagated without being checked by such attributes may have been propagated without being checked by
intermediate routers that do not recognize the attribute -- in effect intermediate routers that do not recognize the attribute -- in effect
skipping to change at page 4, line 37 skipping to change at page 4, line 33
-- this is because the detected error can be imputed to the direct -- this is because the detected error can be imputed to the direct
peer. peer.
Examples of errors which would continue to be treated according to Examples of errors which would continue to be treated according to
the procedures of [RFC4271] include the cases where the Total the procedures of [RFC4271] include the cases where the Total
Attribute Length is inconsistent with the message length, or where Attribute Length is inconsistent with the message length, or where
there is more than one attribute with a given type code. Also, there is more than one attribute with a given type code. Also,
implicit in the foregoing paragraph is the fact that if due to an implicit in the foregoing paragraph is the fact that if due to an
error, including those in an optional transitive attribute, the other error, including those in an optional transitive attribute, the other
attributes of the UPDATE message cannot be correctly parsed, then the attributes of the UPDATE message cannot be correctly parsed, then the
procedures of [RFC4271] continue to apply. procedures of [RFC4271] continue to apply. Examples of errors that
would continue to be treated according to the procedures of [RFC4271]
include the cases where the Total Attribute Length is inconsistent
with the message length, where the Attribute Length is inconsistent
with the Total Attribute Length, or where there is more than one
attribute with a given type code. Also, implicit in the foregoing
paragraph is the fact that if due to an error, including those in an
optional transitive attribute, the other attributes of the UPDATE
message cannot be correctly parsed, then the procedures of [RFC4271]
continue to apply.
In the specific case of incorrect path attribute flags -- i.e., a In the specific case of incorrect path attribute flags -- i.e., a
path attribute that is known by its type code to be Optional and path attribute that is known by its type code to be Optional and
Transitive but whose flags are not set accordingly -- the behavior Transitive but whose flags are not set accordingly -- the behavior
specified by [RFC4271] SHALL be followed. (Consider that in the case specified by [RFC4271] SHALL be followed. (Consider that in the case
of such an error, the "tunneling" argument given above does not of such an error, the "tunneling" argument given above does not
apply, by definition.) apply, by definition.)
Finally, we observe that in order to treat an UPDATE as though all Finally, we observe that in order to treat an UPDATE as though all
contained routes had been withdrawn as discussed above, the NLRI contained routes had been withdrawn as discussed above, the NLRI
field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be
successfully parsed. If this were not possible, the UPDATE would successfully parsed. If this were not possible, the UPDATE would
necessarily be malformed in some way beyond the scope of this necessarily be malformed in some way beyond the scope of this
document and therefore, the procedures of [RFC4271] would continue to document and therefore, the procedures of [RFC4271] would continue to
apply. apply.
4. Operational Considerations 4. Parsing of NLRI Fields
We observe that in order to treat an UPDATE as though all contained
routes had been withdrawn as discussed above, the NLRI field and/or
MP_REACH and MP_UNREACH [RFC4760] attributes need to be successfully
parsed. If this were not possible, the UPDATE would necessarily be
malformed in some way beyond the scope of this document and
therefore, the procedures of [RFC4271] would continue to apply.
To facilitate the determination of the NLRI field in an UPDATE with
malformed attributes, we strongly RECOMMEND that the MP_REACH or
MP_UNREACH attribute (if present) be encoded as the very first path
attribute in an UPDATE.
Traditionally the NLRI for the IPv4 unicast address family are
carried immediately following all the attributes in an UPDATE
[RFC4271]. 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.
Furthermore, we observe that the NLRI for the IPv4 unicat address
family can equally well be carried in the MP_REACH attribute of an
UPDATE when the IPV4 unicast address family capability is shared
(i.e., both advertised and received) over a BGP session. For the
same sake of better debugging and fault handling, we also RECOMMEND
that the MP_REACH attribute be used and be placed as the very first
path attribute in an UPDATE in this case.
5. Operational Considerations
Although the "treat as withdraw" error-handling behavior defined in Although the "treat as withdraw" error-handling behavior defined in
Section 3 makes every effort to preserve BGP's correctness, we note Section 3 makes every effort to preserve BGP's correctness, we note
that if an UPDATE received on an IBGP session is subjected to this that if an UPDATE received on an IBGP session is subjected to this
treatment, inconsistent routing within the affected Autonomous System treatment, inconsistent routing within the affected Autonomous System
may result. The consequences of inconsistent routing can include may result. The consequences of inconsistent routing can include
long-lived forwarding loops and black holes. While lamentable, this long-lived forwarding loops and black holes. While lamentable, this
issue is expected to be rare in practice, and more importantly is issue is expected to be rare in practice, and more importantly is
seen as less problematic than the session-reset behavior it replaces. seen as less problematic than the session-reset behavior it replaces.
skipping to change at page 5, line 41 skipping to change at page 6, line 30
effect on route selection or installation, the presumption is that effect on route selection or installation, the presumption is that
discarding it is unsafe, unless careful analysis proves otherwise. discarding it is unsafe, unless careful analysis proves otherwise.
The analysis should take into account the tradeoff between preserving The analysis should take into account the tradeoff between preserving
connectivity and potential side effects. connectivity and potential 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 malformed optional debugging facilities to permit issues caused by malformed optional
transitive attributes to be diagnosed. At a minimum, such facilities transitive attributes to be diagnosed. At a minimum, such facilities
SHOULD include logging an error when such an attribute is detected. SHOULD include logging an error when such an attribute is detected.
5. Error Handling Procedures for Existing Optional Transitive 6. Error Handling Procedures for Existing Optional Transitive
Attributes Attributes
5.1. AGGREGATOR 6.1. AGGREGATOR
The error handling of [RFC4271] is revised as follows: The error handling of [RFC4271] is 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 as follows. If its Partial flag is set and its Neighbor- handled as follows. If its Partial flag is set and its Neighbor-
Complete flag is clear, either the attribute MUST be discarded or the Complete flag is clear, either the attribute MUST be discarded or the
UPDATE containing it treated as a withdraw as discussed in Section 3. UPDATE containing it treated as a withdraw as discussed in Section 3.
Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete Otherwise (i.e. if its Partial flag is clear or its Neighbor-Complete
flag is set), the procedures of [RFC4271] MUST be followed with flag is set), the procedures of [RFC4271] MUST be followed with
respect to an Optional Attribute Error. respect to an Optional Attribute Error.
5.2. Community 6.2. 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 not a nonzero multiple of 4.
An UPDATE message with a malformed Community attribute SHALL be An UPDATE message with a malformed Community attribute SHALL be
handled as follows. If its Partial flag is set and its Neighbor- handled as follows. If its Partial flag is set and its Neighbor-
Complete flag is clear, the update containing it MUST be treated as a Complete flag is clear, the update containing it MUST be treated as a
withdraw as discussed in Section 3. Otherwise (i.e. if its Partial withdraw as discussed in Section 3. Otherwise (i.e. if its Partial
flag is clear or its Neighbor-Complete flag is set), the procedures flag is clear or its Neighbor-Complete flag is set), the procedures
of [RFC4271] MUST be followed with respect to an Optional Attribute of [RFC4271] MUST be followed with respect to an Optional Attribute
Error. Error.
5.3. Extended Community 6.3. 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 not a nonzero 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 as follows. If its Partial flag is set and its Neighbor- be handled as follows. If its Partial flag is set and its Neighbor-
Complete flag is clear, the update containing it MUST be treated as a Complete flag is clear, the update containing it MUST be treated as a
withdraw as discussed in Section 3. Otherwise (i.e. if its Partial withdraw as discussed in Section 3. Otherwise (i.e. if its Partial
flag is clear or its Neighbor-Complete flag is set), the procedures flag is clear or its Neighbor-Complete flag is set), the procedures
of [RFC4271] MUST be followed with respect to an Optional Attribute of [RFC4271] MUST be followed with respect to an Optional Attribute
Error. Error.
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.
6. 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.
7. Acknowledgements 8. Acknowledgements
The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex
Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin
Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir, Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir,
Ananth Suryanarayana, and Kaliraj Vairavakkalai for their Ananth Suryanarayana, and Kaliraj Vairavakkalai for their
observations and discussion of this topic. The Neighbor-Complete observations and discussion of this topic. The Neighbor-Complete
flag was introduced as the result of helpful discussion with Jie Dong flag was introduced as the result of helpful discussion with Jie Dong
and Mach Chen. and Mach Chen.
8. IANA Considerations 9. IANA Considerations
IANA is requested to establish and maintain a registry of BGP Path IANA is requested to establish and maintain a registry of BGP Path
Attribute Flags. Flags one through four are defined in [RFC4271]. Attribute Flags. Flags one through four are defined in [RFC4271].
Flag five is defined in Section 2 of this document. Future Flag five is defined in Section 2 of this document. Future
allocations are to be made according to the IETF Standards Action allocations are to be made according to the IETF Standards Action
policy [RFC5226]. policy [RFC5226].
9. References 10. References
9.1. Normative References 10.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.
[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
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
9.2. Informative References 10.2. Informative References
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
Appendix A. Why not discard UPDATES? Appendix A. Why not discard UPDATES?
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
 End of changes. 19 change blocks. 
27 lines changed or deleted 61 lines changed or added

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