draft-ietf-idr-error-handling-15.txt   draft-ietf-idr-error-handling-16.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: April 27, 2015 Sproute Networks Expires: May 16, 2015 Sproute Networks
K. Patel K. Patel
Cisco Systems, Inc. Cisco Systems, Inc.
October 24, 2014 November 12, 2014
Revised Error Handling for BGP UPDATE Messages Revised Error Handling for BGP UPDATE Messages
draft-ietf-idr-error-handling-15 draft-ietf-idr-error-handling-16
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, because a session reset would impact
routes with the offending attribute, but also other valid routes not only routes with the offending attribute, but also other, valid
exchanged over the session. This document partially revises the routes exchanged over the session. This document partially revises
error handling for UPDATE messages, and provides guidelines for the the error handling for UPDATE messages and provides guidelines for
authors of documents defining new attributes. Finally, it revises the authors of documents defining new attributes. Finally, it
the error handling procedures for a number of existing attributes. revises the error handling procedures for a number of existing
attributes.
This document updates error handling for RFCs 1997, 4271, 4360, 4456, This document updates error handling for RFCs 1997, 4271, 4360, 4456,
4760, 5543, 5701 and 6368. 4760, 5543, 5701 and 6368.
Status of This Memo Status of This Memo
This Internet-Draft is submitted 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). 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 April 27, 2015. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 39 skipping to change at page 2, line 39
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Error-Handling Approaches . . . . . . . . . . . . . . . . . . 4 2. Error-Handling Approaches . . . . . . . . . . . . . . . . . . 4
3. Revision to BGP UPDATE Message Error Handling . . . . . . . . 4 3. Revision to BGP UPDATE Message Error Handling . . . . . . . . 4
4. Attribute Length Fields . . . . . . . . . . . . . . . . . . . 6 4. Attribute Length Fields . . . . . . . . . . . . . . . . . . . 6
5. Parsing of NLRI Fields . . . . . . . . . . . . . . . . . . . 7 5. Parsing of Network Layer Reachability Information (NLRI)
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Encoding NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Encoding NLRI . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Missing NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Missing NLRI . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Syntactic Correctness of NLRI Fields . . . . . . . . . . 8 5.3. Syntactic Correctness of NLRI Fields . . . . . . . . . . 8
5.4. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . 9 6. Operational Considerations . . . . . . . . . . . . . . . . . 9
7. Error Handling Procedures for Existing Attributes . . . . . . 10 7. Error Handling Procedures for Existing Attributes . . . . . . 10
7.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 11 7.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 27 skipping to change at page 3, line 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 as a session reset would received. This behavior is undesirable, because a session reset
impact not only routes with the offending attribute, but also other impacts not only routes with the offending attribute, but also other,
valid routes exchanged over the session. In the case of optional valid routes exchanged over the session. In the case of optional
transitive attributes, the behavior is especially troublesome and may transitive attributes, the behavior is especially troublesome and may
present a potential security vulnerability. The reason is that such present a potential security vulnerability. This is because
attributes may have been propagated without being checked by attributes may have been propagated without being checked by
intermediate routers that do not recognize the attributes -- in intermediate routers that don't recognize the attributes. In effect,
effect the attribute may have been tunneled, and when they do reach a the attributes may have been tunneled; and when they reach a router
router that recognizes and checks them, the session that is reset may that recognizes and checks the attributes, the session that is reset
not be associated with the router that is at fault. To make matters may not be associated with the router that is at fault. To make
worse, in such cases although the problematic attributes may have matters worse, in such cases although the problematic attributes may
originated with a single update transmitted by a single BGP speaker, have originated with a single update transmitted by a single BGP
by the time they encounter a router that checks them they may have speaker, by the time they encounter a router that checks them they
been replicated many times, and thus may cause the reset of many may have been replicated many times, and thus may cause the reset of
peering sessions. Thus the damage inflicted may be multiplied many peering sessions. Thus the damage inflicted may be multiplied
manyfold. manyfold.
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
skipping to change at page 7, line 4 skipping to change at page 7, line 4
can be in conflict with the enclosed path attributes, which can be in conflict with the enclosed path attributes, which
themselves carry length values. In the "overrun" case, as the themselves carry length values. In the "overrun" case, as the
enclosed path attributes are parsed, the length of the last enclosed path attributes are parsed, the length of the last
encountered path attribute would cause the Total Attribute Length to encountered path attribute would cause the Total Attribute Length to
be exceeded. In the "underrun" case, as the enclosed path attributes be exceeded. In the "underrun" case, as the enclosed path attributes
are parsed, after the last successfully-parsed attribute, fewer than are parsed, after the last successfully-parsed attribute, fewer than
three octets remain, or fewer than four octets, if the Attribute three octets remain, or fewer than four octets, if the Attribute
Flags field has the Extended Length bit set -- that is, there remains Flags field has the Extended Length bit set -- that is, there remains
unconsumed data in the path attributes but yet insufficient data to unconsumed data in the path attributes but yet insufficient data to
encode a single minimum-sized path attribute. In either of these encode a single minimum-sized path attribute. In either of these
cases an error condition exists and the treat-as-withdraw approach cases, an error condition exists and the treat-as-withdraw approach
MUST be used (unless some other, more severe error is encountered MUST be used (unless some other, more severe error is encountered
dictating a stronger approach), and the Total Attribute Length MUST dictating a stronger approach), and the Total Attribute Length MUST
be relied upon to enable the beginning of the NLRI field to be be relied upon to enable the beginning of the NLRI field to be
located. located.
For all path attributes other than those specified as having an For all path attributes other than those specified as having an
attribute length that may be zero it SHALL be considered a syntax attribute length that may be zero, it SHALL be considered a syntax
error for the attribute to have a length of zero. (Of the path error for the attribute to have a length of zero. (Of the path
attributes considered in this specification, only AS_PATH and attributes considered in this specification, only AS_PATH and
ATOMIC_AGGREGATE may validly have an attribute length of zero.) ATOMIC_AGGREGATE may validly have an attribute length of zero.)
5. Parsing of NLRI Fields 5. Parsing of Network Layer Reachability Information (NLRI) Fields
5.1. Encoding NLRI 5.1. Encoding NLRI
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: malformed attribute:
o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL
be encoded as the very first path attribute in an UPDATE. be encoded as the very first path attribute in an UPDATE.
o An UPDATE message MUST NOT contain more than one of the following: o An UPDATE message MUST NOT contain more than one of the following:
skipping to change at page 9, line 20 skipping to change at page 9, line 20
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.
skipping to change at page 15, line 39 skipping to change at page 15, line 39
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.
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, Rex Fernando, Jeff Haas,
Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Tony Li, Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Warren
Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Tony Kumari, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan
Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen, Shyam Sethuram, Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen,
Rob Shakir, Naiming Shen, Adam Simpson, Ananth Suryanarayana, Kaliraj Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson, Ananth
Vairavakkalai, Lili Wang and Ondrej Zajicek for their observations Suryanarayana, Kaliraj Vairavakkalai, Lili Wang and Ondrej Zajicek
and discussion of this topic, and review of this document. for their observations and discussion of this topic, and 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.
 End of changes. 14 change blocks. 
33 lines changed or deleted 36 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/