Subject: [Idr] BGP Attributes Flags problem, Capability solution proposed text

From: Jeff Wheeler <[email-masked]>
Date: Fri, 8 Feb 2013 15:34:06 -0500

I don't know how you folks normally get this done, but in the interest
of moving the process towards the capability solution, I have provided
some (very rough) text below.

Note that I personally would not support furthering this text without
obvious addition of boilerplate material, re-organization / re-wording
of some of the below text, etc.  I am just posting it to keep things
moving in a constructive way.  I think this language can be polished
to result in an effective technical (and political) solution that most
people can probably agree is the best way to solve the problem.

Abstract

This describes an extension to the BGP-4 [ref] protocol facilitating
the use of previously reserved bits in the BGP Path Attributes Flags
field of UPDATE messages.  These bits may be used to carry information
about Path Attributes.

Introduction

The BGP Path Attributes Flags carry information about their associated
attributes.  To date, they are used to differentiate between
well-known and optional attributes (Optional flag), to specify
handling of unrecognized optional attributes (Transitive flag), to
indicate end-to-end support for features which utilize particular
attributes (Partial flag), and to enable attributes with data longer
than 255 octets (Extended Length flag.)  Four additional flags bits
are reserved and have no standardized use.

Implementations vary on their handling of the four reserved bits.
Observed behaviors include
* zeroing out the bits when propagating them to BGP neighbors
* propagating the values unchanged
* closing the BGP session if any of these bits are set to 1
* intentionally or accidentally setting one or more bits to 1

This gives rise to several inter-operation problems which are
rectified by implementing this extension to BGP-4.  These problems
are:

The bits cannot reliably used today because it is unknown if transit
routers are resetting the value of the bits to zero.

Some routers close BGP sessions in response to 1 values in these bits.
 This has resulted in outages to some Internet networks [ref].

Significant confusion exists about the proper procedure for handling
these bits.  Some vendors strongly disagree about their appropriate
handling, and new policy language is needed to resolve these
potentially serious inter-op problems.

Capability

Support for the BGP Path Attributes Flags Extension feature must be
negotiated using BGP Capabilities [ref].  An implementation supporting
this feature MUST advertise Capability Code TBDcc when establishing
BGP sessions to neighbors.  It MUST NOT send flags extension bits to
neighbors who do not announce support for Capability Code TBDcc.

Update to RFC4271 Section 4.3 UPDATE Message Format, Path Attributes section:

The low-order four bits of the Attribute Flags octet are redefined by
this specification.

The three low-order bits are the Attribute Flags Extension Bits.  They
may be used to carry information about attributes.

The fifth bit [diagram needed to avoid confusion] is the Path
Attribute Flags Extension Present bit.  If any information is
contained in the Extension Bits, the value of the Flags Extension
Present bit MUST be set to 1.

The Attribute Flags Extension Bits, and Extension Present bit, MUST be
zeroed-out when sending or propagating attributes to neighbors which
do not support the Capability.  See updates to RFC4271 Section 5.x for
further details.

Update to RFC4271 Section 5 Path Attributes

New subsection 5.x Path Attribute Flags Extension Bits

When a neighboring BGP speaker does not announce the Path Attribute
Flags Extension Capability Code, that neighbor is not able to receive
extension bit information.  The value of the Extension Bits Present
bit, and the three extension bits, must be set to 0 when propagating
and/or sending attributes to such a neighbor.

The Flags Extension Bits, the three low-order bits of the Path
Attribute Flags octet, may be utilized to carry additional information
about attributes.  A BGP-speaker may signal information in these bits
provided that the Flags Extension Present bit, (binary nnnn1nnn), is
set to 1, indicating to receivers that a value is contained in one or
more of the extension bits.

When a neighboring BGP speaker announces the Path Attribute Flags
Extension Capability Code, that neighbor is able to receive extension
bit information.  When transmitting messages to such neighbors, the
value of the Flags Extension Present bit MUST be set to 1 if any data
is carried by the extension bits.  The Flags Extension Present bit
MUST NOT be reset to zero.

When receiving attributes from a neighbor supporting the Capability,
if an attribute has any extension bits set to 1, the implementation
MUST check the value of the Extension Bits Present bit.  If the
Present bit is 0, the implementation SHOULD log a diagnostic message
including the attribute type code and any NLRI or MP_NLRI [ref]
contained in the UPDATE, and MUST treat the attribute as if all the
extension bits were 0, and MUST NOT propagate these bits to other BGP
neighbors without modification.  The implementation is free to make
use of the bits, and to transmit such used bits to neighbors
supporting the Capability, but if data is carried in the bits, it MUST
set the Extension Bits Present bit to 1 when transmitting the
attribute to other neighbors.

IANA Considerations

A BGP Capability Code shall be allocated to indicate support for the
BGP Path Attributes Flags Extension feature, defined by this
specification.

No procedure is defined for allocation of the path attributes flags
extension bits at this time.

Security Considerations

Implementing this specification reduces exposure to a
denial-of-service vulnerability that may be present in some BGP
networks due to inter-operation problems with use of the BGP Path
Attributes Flags reserved bits.

No other security implications are known at this time.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 8 Feb 2013 15:41:01 -0500

> routers are resetting the value of the bits to zero.

Also, sorry to respond immediately to my own post, but I want to
expand on this particular text and provide a reference.

The IP Explicit Congestion Notification (ECN) (RFC3168) bits have this
same problem.  They were taken from what was originally the Type of
Service (ToS) field in the base IPv4 specification.  Routers were and
still are free to reset these bits to 0 unless they support ECN, in
which case, I believe they must not(?) reset them.

ECN went through a couple of revisions.  The current specification
uses two bits, a 1 value in either bit carries information, but a 0
bit does not necessarily carry information.  That is because transit
routers might reset them to 0.  Basically, two bits, which are capable
of encoding 4 possible values (00b, 01b, 10b, 11b) are used but they
can only reliably carry positive values for two independent conditions
(01b or 10b) or three values if used together (01b, 10b, 11b).

Any future use of the reserved bits would encounter the same
difficulty, because some existing BGP implementations reset them to
zero.

My proposal solves this by setting aside one of the bits to indicate
if any of the other three bits can be relied on.

I wanted to provide this reference to ECN because I believe it is an
example of a similar problem which had a different solution which was
appropriate for ECN's encoding into the ToS field.  I do not think the
"ECN approach" is needed for these bits in BGP, though.

Thanks for reading,