Subcodes for BGP Finite State Machine Error
draft-ietf-idr-fsm-subcode-03

[Ballot discuss]
I see that a small Seurity Section has been added to the new revision. This seems to address the specific example Ran gave, and also provides a reference for general BGP security considerations.

Ultimately, the Discuss is my point and not Ran's, but I remain surprised that this IETF last call comment was not addressed on the IETF mailing list and closed down with Ran. I will hold my Discuss a short while longer in the hope that this happens.


There was a last call comment from Ran Atkinson that said:

  I have read this short document and am familiar with its
  contents.  I am not a BGP implementer, instead I am a BGP
  user (as are several of my clients).

  Summary:  Security Considerations are missing

  The absence of any substantive "Security Considerations"
  is problematic and needs to be corrected prior to approval. 

  As an example, creating these sub-codes will greatly facilitate
  active probing of remote routers for "OS fingerprinting" or
  "BGP fingerprinting", which might be used in future to determine
  the manufacturer, software-version, and possibly hardware model
  of the remote router. 

  In turn, such fingerprinting can facilitate targeting attacks
  against security issues present in certain software versions
  or software+hardware combinations.

  I do not object to the principle of adding these sub-codes,
  but the practical operational security risks ought to be
  fully and clearly documented before this draft proceeds. 

Without agreeing or disagreeing with what Ran has said, I expect IETF
last call comments to be resolved through discussion on the IETF list
before te I-D is approved.

[Ballot discuss]
The IANA Considerations section states:

  IANA is requested to create the registry "BGP Finite State Machine
  Error Subcodes", within the "BGP Error Subcodes" registry, with
  Registration Procedures "Standards Action process or the Early IANA
  Allocation process".

As far as I understand it, "Standards Action" is a registration process (per RFC 5226) but there is no such registration process as "Early IANA Allocation". It is true that RFC 4020 defines procedures for early allocation of code points, but that does not mean that early allocation is a registration process. Given that early allocation is always possible when the registration process is "Standards Action", it is proper to remove the text " or the Early IANA Allocation process" from the quoted paragraph. Alternatively, you could say something like this:

  IANA is requested to create the registry "BGP Finite State Machine
  Error Subcodes", within the "BGP Error Subcodes" registry, with a
  Registration Procedure of "Standards Action" as defined in [RFC5226]
  (naturally, early allocation of such subcodes is allowed, in accordance
  with [RFC4020]).

[Ballot discuss]
There was a last call comment from Ran Atkinson that said:

  I have read this short document and am familiar with its
  contents.  I am not a BGP implementer, instead I am a BGP
  user (as are several of my clients).

  Summary:  Security Considerations are missing

  The absence of any substantive "Security Considerations"
  is problematic and needs to be corrected prior to approval. 

  As an example, creating these sub-codes will greatly facilitate
  active probing of remote routers for "OS fingerprinting" or
  "BGP fingerprinting", which might be used in future to determine
  the manufacturer, software-version, and possibly hardware model
  of the remote router. 

  In turn, such fingerprinting can facilitate targeting attacks
  against security issues present in certain software versions
  or software+hardware combinations.

  I do not object to the principle of adding these sub-codes,
  but the practical operational security risks ought to be
  fully and clearly documented before this draft proceeds. 

Without agreeing or disagreeing with what Ran has said, I expect IETF
last call comments to be resolved through discussion on the IETF list
before te I-D is approved.

---

I am unclear whether this document is intended to update RFC 4271. Is
the plan that all future BGP implementations need to include this work,
or is the inclusion optional? As currently presented, it is optional.

Upon approval of this document, IANA will create the following
sub-registry under "BGP Error Subcodes" at
http://www.iana.org/assignments/bgp-parameters

Registry Name: BGP Finite State Machine Error Subcodes
Registration Procedures: Standards Action or Early Allocation

Value Name
0 Unspecified Error
1 Receive Unexpected Message in OpenSent State
2 Receive Unexpected Message in OpenConfirm State
3 Receive Unexpected Message in Established State

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Subcodes for BGP Finite State Machine Error) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Subcodes for BGP Finite State Machine Error'
  as a 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 2011-12-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


  This document defines several subcodes for BGP Finite State Machine
  (FSM) Error that could provide more information to help network
  operators in diagnosing BGP FSM issues and correlating network
  events.





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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-fsm-subcode/


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

Proto write-up for draft-ietf-idr-fsm-subcode-02

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

The document shepherd for draft-ietf-idr-fsm-subcode-02 is Susan Hares.  Susan.Hares@huawei.com (or shares@ndzh.com). 
I believe this document is ready for forwarding to the IESG for publication.

      The document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

The document has been presented in two+ meetings of the IETF (IETF77/IETF78]. The document shepherd personally requested key implementers/architects at Cisco and Juniper to review the code for implementation. These architect/key implementers discussed the document with the authors.  In addition, the IDR chairs request that any IDR feature have two implementations that interoperate prior to forwarding. 

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML

No. The chairs believe this document has seen sufficient review in IDR for its scope. The document focuses on correcting error codes sent during BGP errors. The error codes are then exposed to the BGP operator via the CLI, message logs or other mechanisms.

This document has been implemented by the following two different BGP implementations: Huawei NE40E, NE80E, NE500E running VRP 5-R9, and the Quagga code (running on OPENBSD). The Quagga version of this code runs in the bgpd.8 code module and impacts the session.cand session.h routes. The person implementing it in Quagga was Claudio Jeker.  The log report from the interoperable run is attached in an appendix.

Both implementations correctly coded the “MUST” statements within the code base.

  (1.d) Do have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      the IPR issue.

No concerns. [checking disclosure]

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

It represents the concurrence of the working group.  The mail list had strong concurrence.  This draft is part of the general agreement of this being a “whole” in the previous error handling.  Please note that this draft is part of the IDR WG response to Grow requested revisions to the error handling in BGP. As such, this shepherd presented the general topic at IETF 82. 

(1.f) Has anyone threatened an appeal or otherwise indicated extreme  discontent? If so, please summarize the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No. This draft provides additional error reporting as the Grow working group requested.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type review

Data tracker finds no issues. Idnits is satisfied. [check this]

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

Split as required. No down-references. [check this]

(1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?

Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

This document defines a registry should be defined for BGP Finite Statement Machine Error Subcodes within the BGP Error Subcode registry. This registry is a subcategory under the BGP Error Subcodes.

[www.iana.org/assignments/bgp-parameters/bgp-parameters.xml]

The name for the registry is “BGP Finite Statemachine Error Subcodes.
The document defines four state variables to be the original values in this registry.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents.


Technical Summary
The IDR working group is revising the BGP-4 specifications to add additional error handling per the Grow Working Group’s request in draft-grow-ops-reqs-for-bgp-error-handling-02. This draft defines operational sub-codes for the BGP Finite State Machine Error that provide more information to aid network operators in diagnosing BGP FSM issues and correlating network events.

This BGP feature has been implemented in two separate implementation (Huawei VRP5-R9 OS and Quagga) which successful interoperated. 

Working Group Summary
The document is a product of the IDR working group. The document has working group consensus, and it is part of the IDR work in revising BGP error handling in response to GROW’s request. 

Document Quality
The document provides the necessary specification for implementers to use implement the additional error processing by providing a description of when to send the error codes (usage, section 3), and what error codes to send (Definition of error codes, section 2). 

The quality of the document is good with enough brevity to make it easy to understand.


Appendix A – log text demonstrating the code from the Huawei Router

Oct 24 2011 20:10:02-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[203]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=3, BgpAddressFamily=Public, ErrorData=01)
Oct 24 2011 20:10:02-08:00 Quidway %%01BGP/3/STATE_CHG_UPDOWN(l)[204]:The status of the peer 192.168.1.33 changed from ESTABLISHED to IDLE. (InstanceName=Public, StateChangeReason=Finite State Machine Error/Receive Unexpected Message in Established State)
Oct 24 2011 20:10:31-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[205]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=1, BgpAddressFamily=Public, ErrorData=04)
Oct 24 2011 20:11:06-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[206]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=1, BgpAddressFamily=Public, ErrorData=02)
Oct 24 2011 20:11:51-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[209]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=1, BgpAddressFamily=Public, ErrorData=05)
Oct 24 2011 20:12:23-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[210]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=2, BgpAddressFamily=Public, ErrorData=01)
Oct 24 2011 20:12:40-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[211]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=2, BgpAddressFamily=Public, ErrorData=02)
Oct 24 2011 20:13:03-08:00 Quidway %%01BGP/6/SEND_NOTIFY(l)[214]:The router sent a NOTIFICATION message to peer 192.168.1.33. (ErrorCode=5, SubErrorCode=2, BgpAddressFamily=Public, ErrorData=05)