draft-ietf-idr-optional-transitive-03.txt   draft-ietf-idr-optional-transitive-04.txt 
Internet Engineering Task Force J. Scudder Internet Engineering Task Force (IETF) J. Scudder
Internet-Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Standards Track E. Chen Update: 1997, 4271, 4360 (if approved) E. Chen
Expires: April 1, 2011 Cisco Systems Intended Status: Standards Track P. Mohapatra
September 28, 2010 Expires: April 26, 2012 K. Patel
Cisco Systems
October 25, 2011
Error Handling for Optional Transitive BGP Attributes Revised Error Handling for BGP UPDATE Messages
draft-ietf-idr-optional-transitive-03.txt draft-ietf-idr-optional-transitive-04.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 as a session reset would impact not only
attributes. This document revises BGP's error-handling rules for routes with the offending attribute, but also other valid routes
optional transitive attributes, and provides guidelines for the exchanged over the session. This document partially revises the
authors of documents defining new optional transitive attributes. It error handling for UPDATE messages, and provides guidelines for the
also introduces a new Path Attribute flag, Neighbor-Complete, to authors of documents defining new optional attributes. Finally, it
allow more accurate fault-finding. Finally, it revises the error revises the error handling procedures for several existing
handling procedures for several existing optional transitive
attributes. attributes.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF), its areas, and its working groups. Note that
working documents as Internet-Drafts. The list of current Internet- other groups may also distribute working documents as Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts.
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 April 1, 2011. The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified 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 as a session reset would
transitive attributes whose Partial flag is set; the reason is that impact not only routes with the offending attribute, but also other
such attributes may have been propagated without being checked by valid routes exchanged over the session. In the case of optional
intermediate routers that do not recognize the attribute -- in effect transitive attributes, the behavior is especially troublesome and may
the attributes may have been tunneled, and when they do reach a present a potential security vulnerability. The reason is that such
attributes may have been propagated without being checked by
intermediate routers that do not recognize the attributes -- in
effect the attribute may have been tunneled, and when they do reach a
router that recognizes and checks them, the session that is reset may router that recognizes and checks them, the session that is reset may
not be associated with the router that is at fault. This document not be associated with the router that is at fault.
revises BGP's error-handling rules for optional transitive
attributes, and provides guidelines for the authors of documents
defining new optional transitive attributes. It also revises the
error handling procedures for several existing optional transitive
attributes. Specifically, the error handling procedures of
[RFC4271], [RFC1997], and [RFC4360] are revised.
Error handling procedures are not revised if the error can be imputed The goal for revising the error handling for UPDATE messages is to
to the direct neighbor. A new flag, Neighbor-Complete, is introduced minimize the impact on routing by a malformed UPDATE message, while
which, when used, allows the direct neighbor's involvement to be maintaining protocol correctness to the extent possible. This can be
determined unequivocally. Imputation of "blame" to the direct achieved largely by maintaining the established session and keeping
neighbor is achieved by checking the Partial flag and the Neighbor- the valid routes exchanged, but removing the routes carried in the
Complete flag. If the Partial flag is clear, or the Neighbor- malformed UPDATE from the routing system.
Complete flag is set, the original error handling procedures remain
in force.
1.1. Requirements Language This document partially revises the error handling for UPDATE
messages, and provides guidelines for the authors of documents
defining new optional attributes. Finally, it revises the error
handling procedures for several existing attributes. Specifically,
the error handling procedures of [RFC4271], [RFC1997], and [RFC4360]
are revised.
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. Neighbor-Complete Flag Bit 2. Revision to Base Specification
It is desirable to know whether a neighbor recognizes, or does not The first paragraph of Section 6.3 of [RFC4271] is revised as
recognize, a given optional transitive attribute. The Partial Path follows:
Attribute flag does not provide exactly this information -- it only
enables the determination that a given neighbor did understand such
an attribute, if the flag is set to zero. However, if the flag is
set to one all that can be concluded is that some BGP speaker in the
path did not understand the attribute, it cannot be determined
whether the speaker in question was the neighbor or some other
speaker.
To remedy this, we introduce a new Path Attribute Flag to those Old Text:
defined in [RFC4271] Section 4.3. The fifth high-order bit (bit 4)
of the Attribute Flags octet is the Neighbor-Complete bit. It
indicates whether the neighbor that sent the message recognizes the
attribute (if set to one) or does not recognize it (if set to zero).
The Neighbor-Complete flag only applies to optional transitive
attributes. For other types of attributes the flag MUST be sent as
zero and ignored when received.
A BGP speaker MUST set the Neighbor-Complete flag to one when sending All errors detected while processing the UPDATE message MUST be
a recognized, or zero when sending an unrecognized, optional indicated by sending the NOTIFICATION message with the Error Code
transitive path attribute to its neighbor. UPDATE Message Error. The error subcode elaborates on the specific
nature of the error.
The Neighbor-Complete flag is the equivalent of the Partial flag, New text:
with two differences. First, it is reset on a hop-by-hop basis.
Second, its "polarity" is reversed, with one instead of zero
indicating that a neighbor does recognize the attribute. The reason
for this difference is that during the period while this
specification is being adopted, some BGP speakers will recognize the
Neighbor-Complete flag and some will not. Since the previous
definition [RFC4271] of bit 4 required it to be sent as zero, the use
of one to mean "attribute recognized" allows the recipient of such a
flag to unequivocally determine that a neighbor does recognize the
given attribute.
Use of the flag on receipt is discussed in Section 3. An error detected while processing the UPDATE message for which a
session reset is specified MUST be indicated by sending the
NOTIFICATION message with the Error Code UPDATE Message Error.
The error subcode elaborates on the specific nature of the error.
3. Revision to Base Specification The error handling of the following case described in Section 6.3 of
[RFC4271] remains unchanged:
Section 6.3 of [RFC4271] is revised as follows. The paragraphs If the Withdrawn Routes Length or Total Attribute Length
related to "any recognized attribute" and "an optional attribute" do is too large (i.e., if Withdrawn Routes Length + Total Attribute
not apply to optional transitive attributes received with their Length + 23 exceeds the message Length), then the Error Subcode
Partial flag set and Neighbor-Complete flag clear -- an error limited MUST be set to Malformed Attribute List.
to such an attribute SHALL NOT be responded to by sending a
NOTIFICATION message or resetting the BGP session. Instead, when
such an attribute is determined to be malformed, the UPDATE message
containing that attribute SHOULD be treated as though all contained
routes had been withdrawn just as if they had been listed in the
WITHDRAWN ROUTES field of 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 optional transitive attribute which has no effect
on route selection or installation, the malformed attribute MAY
instead be discarded and the UPDATE message continue to be processed.
An example of an attribute which has no effect on route selection or The error handling of the following case described in Section 6.3 of
installation is the AGGREGATOR attribute. [RFC4271] is revised
A document which specifies an optional transitive attribute MUST If any recognized attribute has Attribute Flags that conflict with
provide specifics regarding what constitutes an error for that the Attribute Type Code, then the Error Subcode MUST be set to
attribute and how that error is to be handled. Attribute Flags Error. The Data field MUST contain the erroneous
attribute (type, length, and value).
Note that the revised error handling only applies when an individual as follows:
optional transitive attribute is received with its Partial flag set
and Neighbor-Complete flag clear and deemed to be erroneous. In the
event that an UPDATE message is deemed to be malformed in any other
way then the procedures of [RFC4271] MUST be applied. This is
likewise the case if an optional transitive attribute is received
whose Partial flag is not set or whose Neighbor-Complete flag is set
-- this is because the detected error can be imputed to the direct
peer.
Examples of errors which would continue to be treated according to If any attribute has Attribute Flags that conflict with the
the procedures of [RFC4271] include the cases where the Total Attribute Type Code, then the error SHOULD be logged, and the
Attribute Length is inconsistent with the message length, or where Attribute Flags MUST be reset to the correct value. The UPDATE
there is more than one attribute with a given type code. Also, message MUST continue to be processed.
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. 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 The error handling of all other cases described in Section 6.3 of
path attribute that is known by its type code to be Optional and [RFC4271] that specify a session reset is revised as follows.
Transitive but whose flags are not set accordingly -- the behavior
specified by [RFC4271] SHALL be followed. (Consider that in the case
of such an error, the "tunneling" argument given above does not
apply, by definition.)
Finally, we observe that in order to treat an UPDATE as though all When a path attribute in an UPDATE message is determined to be
contained routes had been withdrawn as discussed above, the NLRI malformed, the UPDATE message containing that attribute MUST be
field and/or MP_REACH and MP_UNREACH [RFC4760] attributes need to be treated as though all contained routes had been withdrawn just as if
successfully parsed. If this were not possible, the UPDATE would they had been listed in the WITHDRAWN ROUTES field (or in the
necessarily be malformed in some way beyond the scope of this MP_UNREACH_NLRI attribute [RFC4760bis] if appropriate) of the UPDATE
document and therefore, the procedures of [RFC4271] would continue to message, thus causing them to be removed from the Adj-RIB-In
apply. according to the procedures of [RFC4271]. In the case of an
attribute which has no effect on route selection or installation, the
malformed attribute MAY instead be discarded and the UPDATE message
continue to be processed. For the sake of brevity, the former
approach is termed "treat-as-withdraw", and the latter as "attribute
discard".
4. Parsing of NLRI Fields The approach of "treat-as-withdraw" MUST be used for the error
handling of the cases described in Section 6.3 of [RFC4271] that
specify a session reset and involve any of the following attributes:
ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, and LOCAL_PREF.
We observe that in order to treat an UPDATE as though all contained The approach of "attribute discard" MUST be used for the error
routes had been withdrawn as discussed above, the NLRI field and/or handling of the cases described in Section 6.3 of [RFC4271] that
MP_REACH and MP_UNREACH [RFC4760] attributes need to be successfully specify a session reset and involve any of the following attributes:
parsed. If this were not possible, the UPDATE would necessarily be ATOMIC_AGGREGATE and AGGREGATOR.
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 When multiple malformed attributes exist in an UPDATE message, if the
malformed attributes, we strongly RECOMMEND that the MP_REACH or same approach (either "treat-as-withdraw" or "attribute discard") is
MP_UNREACH attribute (if present) be encoded as the very first path specified for the handling of these malformed attributes, then the
attribute in an UPDATE. specified approach MUST be used. Otherwise "treat-as-withdraw" MUST
be used.
Traditionally the NLRI for the IPv4 unicast address family are A document which specifies a new attribute MUST provide specifics
carried immediately following all the attributes in an UPDATE regarding what constitutes an error for that attribute and how that
[RFC4271]. When such an UPDATE is received, we observe that the NLRI error is to be handled.
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 Finally, we observe that in order to use the approach of "treat-as-
family can equally well be carried in the MP_REACH attribute of an withdraw", the entire NLRI field and/or MP_REACH and MP_UNREACH
UPDATE when the IPV4 unicast address family capability is shared [RFC4760bis] attributes need to be successfully parsed. If this is
(i.e., both advertised and received) over a BGP session. For the not possible, the procedures of [RFC4271] continue to apply.
same sake of better debugging and fault handling, we also RECOMMEND Alternatively the error handling procedures specified in [RFC4760bis]
that the MP_REACH attribute be used and be placed as the very first for disabling a particular AFI/SAFI MAY be followed.
path attribute in an UPDATE in this case.
5. Operational Considerations 3. Parsing of NLRI Fields
Although the "treat as withdraw" error-handling behavior defined in To facilitate the determination of the NLRI field in an UPDATE with a
Section 3 makes every effort to preserve BGP's correctness, we note malformed attribute, the MP_REACH or MP_UNREACH attribute (if
present) SHOULD be encoded as the very first path attribute in an
UPDATE as recommended by [RFC4760bis]. An implementation, however,
MUST still be prepared to receive these fields in any position.
If the encoding of [RFC4271] is used, the NLRI field for the IPv4
unicast address family is carried immediately following all the
attributes in an UPDATE. 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.
4. Operational Considerations
Although the "treat-as-withdraw" error-handling behavior defined in
Section 2 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.
Even if inconsistent routing does not arise, the "treat as withdraw" When a malformed attribute is indeed detected over an IBGP session,
we recommend that routes with the malformed attribute be identified
and traced back to the ingress router in the network where the routes
were sourced or received externally, and then a filter be applied on
the ingress router to prevent the routes from being sourced or
received. This will help maintain routing consistency in the
network.
Even if inconsistent routing does not arise, the "treat-as-withdraw"
behavior can cause either complete unreachability or sub-optimal behavior can cause either complete unreachability or sub-optimal
routing for the destinations whose routes are carried in the affected routing for the destinations whose routes are carried in the affected
UPDATE message. UPDATE message.
Note that "treat as withdraw" is different from discarding an UPDATE Note that "treat-as-withdraw" is different from discarding an UPDATE
message. The latter violates the basic BGP principle of incremental message. The latter violates the basic BGP principle of incremental
update, and could cause invalid routes to be kept. (See also update, and could cause invalid routes to be kept. (See also
Appendix A.) Appendix A.)
For any malformed attribute which is discarded instead of the For any malformed attribute which is handled by the "attribute
containing UPDATE being treated as a withdraw as discussed in discard" instead of the "treat-as-withdraw" approach, it is critical
Section 3, it is critical to consider the potential impact of doing to consider the potential impact of doing so. In particular, if the
so. In particular, if the attribute in question has or may have an attribute in question has or may have an effect on route selection or
effect on route selection or installation, the presumption is that installation, the presumption is that discarding it is unsafe, unless
discarding it is unsafe, unless careful analysis proves otherwise. careful analysis proves otherwise. The analysis should take into
The analysis should take into account the tradeoff between preserving account the tradeoff between preserving connectivity and potential
connectivity and potential 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 malformed optional debugging facilities to permit issues caused by a malformed attribute
transitive attributes to be diagnosed. At a minimum, such facilities to be diagnosed. At a minimum, such facilities MUST include logging
SHOULD include logging an error when such an attribute is detected. an error listing the NLRI involved, and containing the entire
malformed UPDATE message when such an attribute is detected. The
malformed UPDATE message SHOULD be analyzed, and the root cause
SHOULD be investigated.
6. Error Handling Procedures for Existing Optional Transitive 5. Error Handling Procedures for Existing Optional Attributes
Attributes
6.1. AGGREGATOR 5.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 using the approach of "attribute discard".
Complete flag is clear, either the attribute MUST be discarded or the
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
flag is set), the procedures of [RFC4271] MUST be followed with
respect to an Optional Attribute Error.
6.2. Community 5.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 using the approach of "treat-as-withdraw".
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
flag is clear or its Neighbor-Complete flag is set), the procedures
of [RFC4271] MUST be followed with respect to an Optional Attribute
Error.
6.3. Extended Community 5.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 using the approach of "treat-as-withdraw".
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
flag is clear or its Neighbor-Complete flag is set), the procedures
of [RFC4271] MUST be followed with respect to an Optional Attribute
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.
7. Security Considerations 6. IANA Considerations
This document makes no request of IANA.
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. Acknowledgements 8. Acknowledgments
The authors wish to thank Ron Bonica, Andy Davidson, Dong Jie, Rex
Fernando, Joel Halpern, Akira Kato, Miya Kohno, Alton Lo, Shin
Miyakawa, Jonathan Oddy, Robert Raszuk, Yakov Rekhter, Rob Shakir,
Ananth Suryanarayana, and Kaliraj Vairavakkalai for their
observations and discussion of this topic. The Neighbor-Complete
flag was introduced as the result of helpful discussion with Jie Dong
and Mach Chen.
9. IANA Considerations
IANA is requested to establish and maintain a registry of BGP Path
Attribute Flags. Flags one through four are defined in [RFC4271].
Flag five is defined in Section 2 of this document. Future
allocations are to be made according to the IETF Standards Action
policy [RFC5226].
10. References The authors wish to thank Ron Bonica, Mach Chen, Andy Davidson, Dong
Jie, Rex Fernando, Joel Halpern, Akira Kato, Miya Kohno, Tony Li,
Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Robert Raszuk,
Yakov Rekhter, Rob Shakir, Naiming Shen, Shyam Sethuram, Ananth
Suryanarayana, and Kaliraj Vairavakkalai for their observations and
discussion of this topic, and review of this document.
10.1. 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
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.
10.2. Informative References [RFC4760bis]
Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4",
"Multiprotocol Extensions for BGP-4", RFC 4760, draft-ietf-idr-rfc4760bis-03.txt, work in progress,
January 2007. August 2011.
Appendix A. Why not discard UPDATES? 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:
AS1--AS2 AS1 ---- AS2
\ / \ /
\ / \ /
AS3 \ /
AS3
o AS1 prefers to reach AS3 directly, and advertises its route to o AS1 prefers to reach AS3 directly, and advertises its route to
AS2. AS2.
o AS2 prefers to reach AS3 directly, and advertises its route to o AS2 prefers to reach AS3 directly, and advertises its route to
AS1. AS1.
o Connections AS3-AS1 and AS3-AS2 fail simultaneously. o Connections AS3-AS1 and AS3-AS2 fail simultaneously.
o AS1 switches to prefer AS2's route, and sends an update message o AS1 switches to prefer AS2's route, and sends an update message
skipping to change at page 10, line 5 skipping to change at page 9, line 33
Although the example above discusses route withdraws, we observe that Although the example above discusses route withdraws, we observe that
in BGP the announcement of a route also withdraws the route in BGP the announcement of a route also withdraws the route
previously advertised. The implicit withdraw can be converted into a previously advertised. The implicit withdraw can be converted into a
real withdraw in a number of ways; for example, the previously- real withdraw in a number of ways; for example, the previously-
announced route might have been accepted by policy, but the new announced route might have been accepted by policy, but the new
announcement might be rejected by policy. For this reason, the same announcement might be rejected by policy. For this reason, the same
concerns apply even if explicit withdraws are removed from concerns apply even if explicit withdraws are removed from
consideration. consideration.
Authors' Addresses 10. Authors' Addresses
John G. Scudder John G. Scudder
Juniper Networks Juniper Networks
Email: jgs@juniper.net Email: jgs@juniper.net
Enke Chen Enke Chen
Cisco Systems Cisco Systems, Inc.
Email: enkechen@cisco.com EMail: enkechen@cisco.com
Pradosh Mohapatra
Cisco Systems, Inc.
EMail: pmohapat@cisco.com
Keyur Patel
Cisco Systems, Inc.
EMail: keyupate@cisco.com
 End of changes. 58 change blocks. 
237 lines changed or deleted 200 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/