Revised Error Handling for BGP UPDATE Messages
RFC 7606

Received changes through RFC Editor sync (changed abstract to 'According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.

This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.')

[Ballot comment]
I have to add my thanks to Stephen's for an exceptionally good shepherd writeup.  Thanks for taking the time to do that.

I agree with Brian's comment that the 2119 key words are inappropriate in Section 6, and that they should be changed to plain-English recommendations.

[Ballot comment]
This document was exceptionally clear to me, and I'm not skilled in the art of BGP. Thanks to everyone who had a hand in that.

[Ballot comment]

- The writeup is so good it almost convinced me to just
ballot no-obj and not bother reading the doc:-) Good job.

- There is a perhaps missing security consideration. I think
this kind of protocol behaviour argues that any kind of
BGPSEC encryption needs to use an AEAD ciphersuite.  (Which
we'd likely do these days anyway, so that's not a biggie.)
The reason is if say CBC or a stream cipher were used, then
an attacker could play with ciphertext is various ways that
might interact with this error handling behaviour so as to
expose information that is intended to be protected by the
BGPSEC mechanism. Such an attack would probably be
pooh-poohed by all but tin foil hat folks, but it could
still be worth noting (maybe in section 8?) and as we've
seen recently, many of the tin foil hat fears turn out to be
realistic, sadly.

I noted a few nitty nits:

- section 2: AFI/SAFI are used without expansion

- 3.d: "well-known mandatory attributes" sort of yells for a
reference, doesn't it.

- 3.e: "cases that specify" - specify where? I think you
mean in the updated RFCs but it might be nice to say that

- 5: NRLI is expanded after 1st use

[Ballot comment]
Thanks for your work on this draft. 
My only comment would be to see if you could break the first paragraph of the security considerations into a few sentences.  Maybe getting rid of the parens to help break out the additional sentences would help.

[Ballot comment]
Thank you for a clearly written document.  The only point I will make is that I do not think the 2119 keywords in section 6 are necessary.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-error-handling-18, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Revised Error Handling for BGP UPDATE Messages) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Revised Error Handling for BGP UPDATE Messages'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-03-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  According to the base BGP specification, a BGP speaker that receives
  an UPDATE message containing a malformed attribute is required to
  reset the session over which the offending attribute was received.
  This behavior is undesirable, because a session reset would impact
  not only routes with the offending attribute, but also other, valid
  routes exchanged over the session.  This document partially revises
  the error handling for UPDATE messages and provides guidelines for
  the authors of documents defining new attributes.  Finally, it
  revises the error handling procedures for a number of existing
  attributes.

  This document updates error handling for RFCs 1997, 4271, 4360, 4456,
  4760, 5543, 5701 and 6368.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Status of administrative actions:
Public IPR Call: 11/12 to 11/19/14
Routing Directorate Review status: Joel Halpern (11/18), QA review completed (9/4)
OPS Directorate status: Reviewer: Warren Kumari (11/16) done 
Gen-Art Pre-review: Pending,  10/14
IANA: No early review

Status of people
Type of draft: Proposed Standard.
The document shepherd is Rob Shakir.
The WG Chair responsible: Sue Hares  [John Scudder is co-author]
The responsible Area Director is Alia Atlas.

1. Status

The document describes revisions to the error handling behavior that is defined in the base BGP-4 specification (RFC4271). The motivation for changes to this behaviour is to avoid a single erroneous UPDATE message (or attribute within such a message) impacting an entire BGP-4 session (and hence all the NLRI that it carries). The document introduces the "treat-as-withdraw" mechanism, which treats the NLRI received within an erroneous UPDATE message as though they are withdrawn by the remote neighbor. Additionally an "attribute discard" approach is introduced. The document evaluates the existing BGP-4 attributes and defines new error handling behaviours for them. Errors for which the existing BGP-4 error handling behaviour is to be retained are also considered.

There is working group consensus amongst both network operators, and BGP-4 implementors that this mechanism is a useful Standards Track document to improve the robustness of the BGP-4 protocol, whilst also considering the correctness of routing information it carries.

2. Review and Consensus

There has been significant debate relating to the balance of different functionalities required between working group participants which seek to maintain established sessions (or retain NLRI during their failure), and those that consider the correctness of the protocol paramount. The document's intention was originally to address a point failure scenario observed within the Internet related to optional transitive attributes, but based on wider operational experience, the working group has extended the scope of the document.

The behaviours now included within the document have been subject to significant review over multiple cycles from both protocol experts, network operators, and protocol implementors contributing to the balance between approaches having been reached.

Operational requirements for the changes within the document have been discussed at length - and reviewed with GROW. Whilst there is some appetite for additional mechanisms for operators to maintain the integrity of their networks by compromising correctness of the routing information in their network - especially during catastrophic failures - this document does not reflect these additional requirements - which are subject to separate proposals to the working group.

Significant deployment experience has been gained for the changes described in the document. The shepherd is aware of four shipping commercial implementations of BGP-4 (Alcatel-Lucent SR OS, Cisco IOS, Cisco IOS XR, Juniper JUNOS), and one open source implementation (Quagga) have implemented the behaviours described in the document. The feedback from these implementations has helped to iterate the contents of the document, and reach consensus within the working group.

3. Intellectual Property

There have been no IPR disclosures on this document, or its predecessors (draft-scudder-idr-optional-transitive, draft-chen-ebgp-error-handling).

[TBD: binal pole pending.

4. Other Points

There are no downrefs for this document.

5. IANA
There are no requests on IANA that need consideration.

1. Summary

Status of administrative actions:
Public IPR Call: 11/12 to 11/19/14
Routing Directorate Review status: Pending, Reviewer Joel Halpern  (10/20-11/19), QA review completed (9/4)
OPS Directorate status: Pending,  Reviewer: Warren Kumari (10/28 - 11/19)
Gen-Art Pre-review: Pending,  10/14

Status of people
Type of draft: Proposed Standard.
The document shepherd is Rob Shakir.
The WG Chair responsible: Sue Hares  [John Scudder is co-author]
The responsible Area Director is Alia Atlas.

1. Status

The document describes revisions to the error handling behavior that is defined in the base BGP-4 specification (RFC4271). The motivation for changes to this behaviour is to avoid a single erroneous UPDATE message (or attribute within such a message) impacting an entire BGP-4 session (and hence all the NLRI that it carries). The document introduces the "treat-as-withdraw" mechanism, which treats the NLRI received within an erroneous UPDATE message as though they are withdrawn by the remote neighbor. Additionally an "attribute discard" approach is introduced. The document evaluates the existing BGP-4 attributes and defines new error handling behaviours for them. Errors for which the existing BGP-4 error handling behaviour is to be retained are also considered.

There is working group consensus amongst both network operators, and BGP-4 implementors that this mechanism is a useful Standards Track document to improve the robustness of the BGP-4 protocol, whilst also considering the correctness of routing information it carries.

2. Review and Consensus

There has been significant debate relating to the balance of different functionalities required between working group participants which seek to maintain established sessions (or retain NLRI during their failure), and those that consider the correctness of the protocol paramount. The document's intention was originally to address a point failure scenario observed within the Internet related to optional transitive attributes, but based on wider operational experience, the working group has extended the scope of the document.

The behaviours now included within the document have been subject to significant review over multiple cycles from both protocol experts, network operators, and protocol implementors contributing to the balance between approaches having been reached.

Operational requirements for the changes within the document have been discussed at length - and reviewed with GROW. Whilst there is some appetite for additional mechanisms for operators to maintain the integrity of their networks by compromising correctness of the routing information in their network - especially during catastrophic failures - this document does not reflect these additional requirements - which are subject to separate proposals to the working group.

Significant deployment experience has been gained for the changes described in the document. The shepherd is aware of four shipping commercial implementations of BGP-4 (Alcatel-Lucent SR OS, Cisco IOS, Cisco IOS XR, Juniper JUNOS), and one open source implementation (Quagga) have implemented the behaviours described in the document. The feedback from these implementations has helped to iterate the contents of the document, and reach consensus within the working group.

3. Intellectual Property

There have been no IPR disclosures on this document, or its predecessors (draft-scudder-idr-optional-transitive, draft-chen-ebgp-error-handling).

[TBD: binal pole pending.

4. Other Points

There are no downrefs for this document.

5. IANA
There are no requests on IANA that need consideration.