draft-ietf-idr-error-handling-18.txt   draft-ietf-idr-error-handling-19.txt 
Internet Engineering Task Force E. Chen, Ed. Internet Engineering Task Force E. Chen, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Updates: 1997, 4271, 4360, 4456, 4760, J. Scudder, Ed. Updates: 1997, 4271, 4360, 4456, 4760, J. Scudder, Ed.
5543, 5701, 6368 (if approved) Juniper Networks 5543, 5701, 6368 (if approved) Juniper Networks
Intended status: Standards Track P. Mohapatra Intended status: Standards Track P. Mohapatra
Expires: June 15, 2015 Sproute Networks Expires: October 23, 2015 Sproute Networks
K. Patel K. Patel
Cisco Systems, Inc. Cisco Systems, Inc.
December 12, 2014 April 21, 2015
Revised Error Handling for BGP UPDATE Messages Revised Error Handling for BGP UPDATE Messages
draft-ietf-idr-error-handling-18 draft-ietf-idr-error-handling-19
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, because a session reset would impact This behavior is undesirable, because a session reset would impact
not only routes with the offending attribute, but also other, valid not only routes with the offending attribute, but also other, valid
routes exchanged over the session. This document partially revises routes 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
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 15, 2015. This Internet-Draft will expire on October 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12
7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13 7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13
7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 13 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 13
7.13. Traffic Engineering path attribute . . . . . . . . . . . 13 7.13. Traffic Engineering path attribute . . . . . . . . . . . 13
7.14. Extended Community . . . . . . . . . . . . . . . . . . . 13 7.14. Extended Community . . . . . . . . . . . . . . . . . . . 13
7.15. IPv6 Address Specific BGP Extended Community Attribute . 14 7.15. IPv6 Address Specific BGP Extended Community Attribute . 14
7.16. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 14 7.16. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Guidance for Authors of BGP Specifications . . . . . . . . . 14 8. Guidance for Authors of BGP Specifications . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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, because a session reset received. This behavior is undesirable, because a session reset
skipping to change at page 4, line 31 skipping to change at page 4, line 31
In this document we refer to four different approaches to handle In this document we refer to four different approaches to handle
errors found in BGP path attributes. They are as follows (listed in errors found in BGP path attributes. They are as follows (listed in
order, from the one with the "strongest" action to the one with the order, from the one with the "strongest" action to the one with the
"weakest" action): "weakest" action):
o Session reset: This is the approach used throughout the base BGP o Session reset: This is the approach used throughout the base BGP
specification [RFC4271], where a NOTIFICATION is sent and the specification [RFC4271], where a NOTIFICATION is sent and the
session terminated. session terminated.
o AFI/SAFI disable: [RFC4760] specifies a procedure for disabling a o AFI/SAFI disable: [RFC4760] specifies a procedure for disabling a
particular AFI/SAFI. particular AFI/SAFI (Address Family Identifier and Subsequent
Address Family Identifier).
o Treat-as-withdraw: In this approach, the UPDATE message containing o Treat-as-withdraw: In this approach, the UPDATE message containing
the path attribute in question MUST be treated as though all the path attribute in question MUST be treated as though all
contained routes had been withdrawn just as if they had been contained routes had been withdrawn just as if they had been
listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI
attribute if appropriate) of the UPDATE message, thus causing them attribute if appropriate) of the UPDATE message, thus causing them
to be removed from the Adj-RIB-In according to the procedures of to be removed from the Adj-RIB-In according to the procedures of
[RFC4271]. [RFC4271].
o Attribute discard: In this approach the malformed attribute MUST o Attribute discard: In this approach the malformed attribute MUST
skipping to change at page 6, line 29 skipping to change at page 6, line 29
first one SHALL be discarded and the UPDATE message continue to first one SHALL be discarded and the UPDATE message continue to
be processed. be processed.
h. When multiple attribute errors exist in an UPDATE message, if the h. When multiple attribute errors exist in an UPDATE message, if the
same approach (either "session reset", "treat-as-withdraw" or same approach (either "session reset", "treat-as-withdraw" or
"attribute discard") is specified for the handling of these "attribute discard") is specified for the handling of these
malformed attributes, then the specified approach MUST be used. malformed attributes, then the specified approach MUST be used.
Otherwise the approach with the strongest action MUST be used. Otherwise the approach with the strongest action MUST be used.
i. The Withdrawn Routes field MUST be checked for syntactic i. The Withdrawn Routes field MUST be checked for syntactic
correctness in the same manner as the NLRI field. This is correctness in the same manner as the NLRI (network layer
discussed further below, and in Section 5.3. reachability information) field. This is discussed further
below, and in Section 5.3.
j. Finally, we observe that in order to use the approach of "treat- j. Finally, we observe that in order to use the approach of "treat-
as-withdraw", the entire NLRI field and/or the MP_REACH_NLRI and as-withdraw", the entire NLRI field and/or the MP_REACH_NLRI and
MP_UNREACH_NLRI attributes need to be successfully parsed -- what MP_UNREACH_NLRI attributes need to be successfully parsed -- what
this entails is discussed in more detail in Section 5. If this this entails is discussed in more detail in Section 5. If this
is not possible, the procedures of [RFC4271] and/or [RFC4760] is not possible, the procedures of [RFC4271] and/or [RFC4760]
continue to apply, meaning that the "session reset" approach (or continue to apply, meaning that the "session reset" approach (or
the "AFI/SAFI disable" approach) MUST be followed. the "AFI/SAFI disable" approach) MUST be followed.
4. Attribute Length Fields 4. Attribute Length Fields
skipping to change at page 8, line 48 skipping to change at page 8, line 49
o The attribute flags of the attribute are inconsistent with those o The attribute flags of the attribute are inconsistent with those
specified in [RFC4760]. specified in [RFC4760].
o The length of the MP_UNREACH_NLRI attribute is less than 3, or the o The length of the MP_UNREACH_NLRI attribute is less than 3, or the
length of the MP_REACH_NLRI attribute is less than 5. length of the MP_REACH_NLRI attribute is less than 5.
5.4. Typed NLRI 5.4. Typed NLRI
Certain address families, for example MCAST-VPN [RFC6514], MCAST-VPLS Certain address families, for example MCAST-VPN [RFC6514], MCAST-VPLS
[RFC7117] and EVPN [I-D.ietf-l2vpn-evpn] have NLRI that are typed. [RFC7117] and EVPN [RFC7432] have NLRI that are typed. Since
Since supported type values within the address family are not supported type values within the address family are not expressed in
expressed in the MP-BGP capability [RFC4760], it is possible for a the MP-BGP capability [RFC4760], it is possible for a BGP speaker to
BGP speaker to advertise support for the given address family and advertise support for the given address family and sub-address family
sub-address family while still not supporting a particular type of while still not supporting a particular type of NLRI within that AFI/
NLRI within that AFI/SAFI. SAFI.
A BGP speaker advertising support for such a typed address family A BGP speaker advertising support for such a typed address family
MUST handle routes with unrecognized NLRI types within that address MUST handle routes with unrecognized NLRI types within that address
family by discarding them, unless the relevant specification for that family by discarding them, unless the relevant specification for that
address family specifies otherwise. address family specifies otherwise.
6. Operational Considerations 6. Operational Considerations
Although the "treat-as-withdraw" error-handling behavior defined in Although the "treat-as-withdraw" error-handling behavior defined in
Section 2 makes every effort to preserve BGP's correctness, we note 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.
When a malformed attribute is indeed detected over an IBGP session, When a malformed attribute is indeed detected over an IBGP session,
we RECOMMEND that routes with the malformed attribute be identified we recommend that routes with the malformed attribute be identified
and traced back to the ingress router in the network where the routes 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 were sourced or received externally, and then a filter be applied on
the ingress router to prevent the routes from being sourced or the ingress router to prevent the routes from being sourced or
received. This will help maintain routing consistency in the received. This will help maintain routing consistency in the
network. network.
Even if inconsistent routing does not arise, the "treat-as-withdraw" 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. update, and could cause invalid routes to be kept.
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.
Section 8 mentions that attribute discard should not be used in cases Section 8 mentions that attribute discard should not be used in cases
where "the attribute in question has or may have an effect on route where "the attribute in question has or may have an effect on route
selection." Although all cases that specify attribute discard in selection." Although all cases that specify attribute discard in
this document do not affect route selection by default, in principle this document do not affect route selection by default, in principle
routing policies could be written that affect selection based on such routing policies could be written that affect selection based on such
an attribute. Operators should take care when writing such policies an attribute. Operators should take care when writing such policies
to consider the possible consequences of an attribute discard. (In to consider the possible consequences of an attribute discard. (In
general, as long as such policies are only applied to external BGP general, as long as such policies are only applied to external BGP
sessions, correctness issues are not expected to arise.) sessions, correctness issues are not expected to arise.)
skipping to change at page 15, line 28 skipping to change at page 15, line 28
9. IANA Considerations 9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
10. Security Considerations 10. 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. Since the intervening routers do not recognize the
causes session resets when it reaches routers that do recognize the attribute, they propagate it without checking it. When the malformed
given attribute type. attribute arrives at a router that does recognize the given attribute
type, that router resets the session over which it arrived. Since
significant fan-out can occur between the attacker and the routers
that do recognize the attribute type, this attack could potentially
be particularly harmful.
The improved error handling of this specification could in theory
interact badly with some now-known weaker cryptographic mechanisms
should such be used in future to secure BGP. For example, if a
(fictional) mechanism that did not supply data integrity was used, an
attacker could manipulate ciphertext in any attempt to change or
observe how the receiver reacts. Absent this specification, the BGP
session would have been terminated, while with this specification the
attacker could make potentially many attempts. While such a
confidentiality-only mechanism would not be defined today, we have in
the past seen mechanism definitions that result in similar though not
as obviously exploitable vulnerabilities. [RFC7366] The approach
recommended today to avoid such issues is to prefer use of
Authenticated Encryption with Additional Data (AEAD) ciphers
[RFC5116] and (thus) to discard messages that don't verify.
In other respects, this specification does not change BGP's security In other respects, this specification does not change BGP's security
characteristics. characteristics.
11. Acknowledgements 11. Acknowledgements
The authors wish to thank Juan Alcaide, Deniz Bahadir, Ron Bonica, The authors wish to thank Juan Alcaide, Deniz Bahadir, Ron Bonica,
Mach Chen, Andy Davidson, Bruno Decraene, Rex Fernando, Jeff Haas, Mach Chen, Andy Davidson, Bruno Decraene, Stephen Farrell, Rex
Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Warren Fernando, Jeff Haas, Chris Hall, Joel Halpern, Dong Jie, Akira Kato,
Kumari, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Miya Kohno, Warren Kumari, Tony Li, Alton Lo, Shin Miyakawa, Tamas
Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen, Mondal, Jonathan Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter,
Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson, Ananth Eric Rosen, Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson,
Suryanarayana, Kaliraj Vairavakkalai, Lili Wang and Ondrej Zajicek Ananth Suryanarayana, Kaliraj Vairavakkalai, Lili Wang and Ondrej
for their observations and discussion of this topic, and review of Zajicek for their observations and discussion of this topic, and
this document. review of this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[IANA-BGP-ATTRS] [IANA-BGP-ATTRS]
"BGP Path Attributes", <http://www.iana.org/assignments/ "BGP Path Attributes", <http://www.iana.org/assignments/
bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2>. bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2>.
[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
skipping to change at page 17, line 7 skipping to change at page 17, line 22
Yamagata, "Internal BGP as the Provider/Customer Edge Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, September 2011. RFC 6368, September 2011.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793, December
2012. 2012.
12.2. Informative References 12.2. Informative References
[I-D.ietf-l2vpn-evpn] [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Encryption", RFC 5116, January 2008.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-11 (work in progress), October 2014.
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop", RFC Layer Reachability Information with an IPv6 Next Hop", RFC
5549, May 2009. 5549, May 2009.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012.
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.
Kodeboniya, "Multicast in Virtual Private LAN Service Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, February 2014. (VPLS)", RFC 7117, February 2014.
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7366, September 2014.
[RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro,
J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, February 2015.
Authors' Addresses Authors' Addresses
Enke Chen (editor) Enke Chen (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: enkechen@cisco.com Email: enkechen@cisco.com
John G. Scudder (editor) John G. Scudder (editor)
Juniper Networks Juniper Networks
Email: jgs@juniper.net Email: jgs@juniper.net
Pradosh Mohapatra Pradosh Mohapatra
Sproute Networks Sproute Networks
Email: mpradosh@yahoo.com Email: mpradosh@yahoo.com
 End of changes. 19 change blocks. 
37 lines changed or deleted 64 lines changed or added

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