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/