Software Version Capability for BGP
draft-abraitis-bgp-version-capability-14

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-abraitis-bgp-version-capability-05. If any part of this review is inaccurate, please let us know.

IANA has a question about this document.

We understand that when this document is sent to us for processing, we will perform a single registry action. Specifically, we'll add the following entry to the Capability Codes registry at https://www.iana.org/assignments/capability-codes:

Value: TBD (First Come First Served range)
Description: Version Capability
Reference: this document
Change Controller: IETF

As noted at the top of the registry, the IETF will be the Change Controller for all future Capability Code registrations.

Thank you,

Amanda Baber
Lead IANA Services Specialist

draft-abraitis-bgp-version-capability has been presented to the ISE for
publication as an Informational RFC in the Independent Stream.

Quite a lot of time has been spent trying to decide whether this should
be marked as Experimental or Informational. To some extent this work is
an experiment, but (as noted in Section 4.1) this has been implemented
in Free Range Routing, and (as noted throughout the document) the
mechanisms defined here can be deployed on the open Internet without
impacting other implementations. Thus, the only "experiment" would be to
decide whether this extension is useful.

This document has been discussed in IDR (the appropriate working group
for BGP extensions) where a number of opinions were expressed ranging
through:
- this is handy
- there are scurity concerns
- using an NMS would be a better approach
- you have to be aware that software can be updated without interupting
  the sesison
- it is impractical and of limited use
- there might be other ways of doing this
- there may be overlap with draft-ietf-idr-operational-message which
  expired in 2012

However, the IDR WG did not have enough interest in adopting the work
and did not respond to an email from the ISE offering them the
opportunity to step in. This position was cross-checked by the ISE with
John Scudder, one of the IDR chairs.

The document makes a request for an allocation from the FCFS portion of
a registry. This document stands as the reference and explanation for
the code point. No further material is demanded by the document that
created the registry (RFC 5492). Note that the registry is currently
being updated by draft-ietf-idr-capabilities-registry-change - that
update does not remove the availability of FCFS assignments.

Along the way, the ISE did two reviews and commissioned a review from
Jeff Haas, a BGP expert. More review than there is draft! The reviews
are presented below, and the author updated the document accordingly.

==ISE First review==

Experimental or Informational?

Sorry that we are flip-flopping on this question, but after talking with
John Scudder and re-reading your draft, I think that Informational is a
better position. That is, you are describing a mechanism and an assigned
code point, and that is it - no need for an experiment, it is what it
is.

That means...

- Change the Intended Status to Informational
- Delete the second sentence from the Abstract
- Delete or rewrite the second paragraph of the Introduction
- Delete section 2

(You end up with an even shorter draft ;-)

---

Section 3

Please use the more recent version of this boilerplate:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

You will need to add RFC 8174 to your references.

---

You need to add RFC 5492 to your references as you use it in Section 4.

---

I think you should make it very clear in Section 4 that the encoding of
the Version is unstructured and implementation-specific, but intended to
be human-readbale.

---

In Section 5 you have...

  The Version capability SHOULD only be used for displaying the version
  of a speaker in order to make troubleshooting easier.

Why is this "SHOULD" and not "MUST"? If you use "SHOULD" you are
allowing other possible uses, and you need to say why/how an
implementation might vary this.

---

In Section 5, please use an address from the reserved documentation
address spaces. For example, 198.51.100.0/24.

---

Section 6

OLD
  IANA is requested to assign a capability number for the Version
  Capability in this document from the BGP Capabilities Codes registry.
NEW
  IANA maintains the "Border Gateway Protocol (BGP) Parameters"
  registry with a subregistry called "Capabilities Codes".  IANA is
  requested to assign a capability number from the First Come First
  Served range for the Version Capability in this document as follows:

  Value | Description      | Reference
  ------+-------------------+------------
  TBD  | Vesion Capability | [This.I-D]
END

---

Section 7

The text here is not going to be good enough. You actually have to
address the security issues with your new capability.

Things to note include:
- Specific verisons of routing code may be known to have vulnerabilites.
  Therefore, announcing what version of code is running on which routers
  may improve an attacker's chances of success.
- Advertising which versions of code and from which vendor it comes may
  facilitate a number of social-engineering attacks.
- Modifying the information advertised by a router might lead to attacks
  including bogus software upgrades and also might mask the causes of
  faults in the network.

You need to describe how these attacks are mitigated:
- How is the information kep hidden from sniffers?
- How is the information kept with a domain of trust?

By all means discuss other issues as well :-)

You will probably want to reference other documents that already address
BGP security mechanisms.

==Jeff Haas==

The capability limits the length of the display to 255 octets of valid UTF-8
characters.  The BGP optional parameters field in which capabilities are carried
without further extension can hold 255 octets of information (RFC 4271 §4.2).  This
means the longest possible capability value is 253 octets.  (RFC 5492 §4).  The
primary reason to highlight this is that without extension, the length of a version
string is sufficient to eat space that is normally used to permit BGP to operate by
exchanging the things it can do.  This means the field is effectively a DoS against
the critical stuff. 

What do you do when you need to encode important stuff?  Do you truncate the string?
No guidance is offered.

A path out of this specific issue is given here:
https://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-05  In my opinion, it'd be
wise for anyone looking at implementing this feature to require support for
ext-opt-param to be negotiated before trying to put in non-essential operational
stuff.

Encoding comment (draft-abraltis §3): the version length is likely unnecessary.  Why
not just use the capability length?

UTF-8 issues/considerations:
UTF-8 is the right way to send this stuff.  IETF is desperately in need of some
general purpose boilerplate for putting this stuff in a protocol since it forces
each draft to try to get it right.

In §3 of the draft, the "Version length" is listed as "The number of characters in
the Version".  The definition of a character in UTF-8 is a valid multi-byte sequence
from 1 to 4 octets.  Does this mean that the Version Length is intended to encode
the length of such UTF-8 characters, or the octet length of Version?  (See above
about should this just be the Capability Length) 

RFC 8203 tries to get a number of critical considerations correct here.See §6 in
there where it gives pointers to a number of encoding considerations.  By
indirection, this also covers the issues of what to do when a UTF-8 sequence is
truncated and you have an invalid character.  This RFC also mentions the lack of a
terminating NUL character and that the full length is to be derived from the
supplied protocol length.

Operational considerations:
Routers may be upgraded without necessarily bouncing BGP sessions.  (E.g. NSR.)  It
is thus possible for active software revision to change without the end user being
notified in this extension.

Security considerations:
The draft covers a lot of reasons you likely don't want to disclose this stuff.  It
even gives a bit of guidance, without RFC 2119 style normative keywords, that you
might want to let this be enabled for iBGP, but perhaps not ebgp?

In my personal opinion, this document should recommend that the version string is
NOT advertised by default, and MUST require explicit configuration to advertise.
And even when that configuration is explicitly provided, it should be required
per-neighbor.

The document also offers zero guidance about giving out this information as part of
unsolicited attempts to peer.  A number of BGP implementations basically provide
wildcard port 179 listens and will get through the BGP handshake before hanging up
on you.  During that handshake, you may disclose this information.

My personal read on this feature:
If you're in a trust boundary where you are welcome to this information, you
probably have access to it by a different means.  And that might include LLDP or
CDP.  Why put it in BGP?

If this is for ebgp speakers between different non-cooperating (customer/provider)
relationships, their security people will likely give you an address in the heated
afterlife of your choice for asking to turn this on.

My final personal analysis is that after the issues raised above are cleared that
the document could be published.  However, no one in their right mind should
implement it.

==ISE Second review==

You should get into the habit of running idnits before you submit a new
version of your draft. (https://www6.ietf.org/tools/idnits/)


The current revision of your draft generates the following warnings...

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 3 instances of too long lines in the document, the longest one
    being 18 characters in excess of 72.

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'RFC8174' is mentioned on line 76, but not defined

  == Missing Reference: 'RFC5492' is mentioned on line 79, but not defined

  == Missing Reference: 'RFC5082' is mentioned on line 197, but not defined

  == Unused Reference: 'RFC3552' is defined on line 218, but no explicit
    reference was found in the text

---

Abstract

s/speaker's version/speaker's routing daemon version/

---

Abstract and Introduction

Add a second paragraph...

This BGP capability is an optoinal advertisement.  Implementations are
not required to advertise the version nor to process received
advertisements.

---

Introduction

  In modern data center designs, we tend to have conventional hosts
  participating in the routing process.  And the fleet of hosts has
  different versions of routing daemon.

The term "host" is now conventionally used to mean "any node that is
not a router" [RFC2460]. I don't think that hosts participate in the
routing process. You could say "node" or (posisbly better) you could
say "router".

---

Introduction

OLD
  This means that
  troubleshooting is a crucial part to quickly identify the root cause.
NEW
  This means that
  knowing which versions of the routing daemons are running the various
  nodes in the network can be a crucial factor in quickly identifying
  the root cause of any protocol or network problems.
END

---

Introduction

Move the following text up from Section 3

  Such protocols like LLDP, CDP can provide the same information as
  well, but in containerized environments, it's very hard and NOT
  RECOMMENDED run background processes.  To minimize operational costs
  it would help having all the necessary information in place.

But rewrite it as...

  Information about the version of the routing daeon could also be
  exchanged in protocols such as LLDP and CDP.  However, in
  containerized environments, it is very hard and not recommended to
  exchange this information between background processes.  Therefore,
  and to help minimize operational costs, it is helpful to exchange
  the routing daemon information between BGP peers directly.

---

2.

Please start with this extra paragraph...

  Although this document is not an IETF Standards Track document, it
  makes use of the terminology from BCP 14 in order to clearly state
  the implementation behaviors.

---

3.

I think we need to completely rewrite this section for clarity and
precision.

OLD
3.  Version Capability

  The Version Capability is a new BGP capability [RFC5492].  The
  implementation is specific to the vendor.  The version is
  unstructured and can be defined in any format the vendor decides.

  The length of the version SHOULD be limited to 64 bytes.  This is the
  limit to allow other capabilities as much space as they require.  The
  version MUST NOT be empty.

  This capability is OPTIONAL.  The vendor MUST implement a capability
  switch to enable or disable it.

  In case you reached 255 bytes of capabilities, you can disable this
  capability.  The capability is designed more to non-production
  environments where you need more visibility for troubleshooting
  purposes.  It's RECOMMENDED to turn it only inside a single
  Autonomous System domain or Autonomous System Confederations.

  Such protocols like LLDP, CDP can provide the same information as
  well, but in containerized environments, it's very hard and NOT
  RECOMMENDED run background processes.  To minimize operational costs
  it would help having all the necessary information in place.

                  +--------------------------------+
                  |    Version Length (1 octet)    |
                  +--------------------------------+
                  |      Version (variable)        |
                  +--------------------------------+

                                Figure 1

  Version Length:

      The number of characters in the Version

  Version:

      The Version encoded via UTF-8
NEW
3.  Version Capability

  Capabilities avdertisements with BGP are defined in [RFC5492].  They
  utilise the BGP Capabilities Optional Parameter that contains one or
  more triples .
  This document defines a new BGP capability, the Version Capability,
  with Capability Code TBD and Capability Length and Capability Value
  as described below.

  The inclusion of the Version Capability is OPTIONAL.  If an
  implementation supports inclusion of the capability, the
  implementation MUST include a configuration switch to enable or
  disable its use, and that switch MUST be off by default.

  The Version Capability is intended principally more to non-production
  environments where more visibility is needed for troubleshooting
  purposes.  It is NOT RECOMMENDED for use outside single Autonomous
  System domain or Autonomous System Confederations.

  An implementation that does not recognize or support the Version
  Capability but which receives one MUST respond as described in
  [RFC5492] by ignoring the option.  An implementation that wishes to
  complain that its neighbor does not support the Version Capability
  MAY use the 'Unsupported Capability' Error Subcode of a Notification
  message as described in [RFC5492].

  The triple for the Version Capability is as follows:

  Capability Code

    TBD by IANA

  Capability Length

    The Capability Length for the Version Capability MUST be greater
    than zero.  A value of zero SHALL be treated as an encoding error
    and the entire triple MUST be ignored.

    The Capability Length SHOULD be no greater than 64.  This is the
    limit to allow other capabilities as much space as they require.

  Capability Value

    The Capability Value field is encoded in UTF-8 [RFC3629].  It is
    unstructured data and can be formatted in any way that the
    implementor decides.

3.1.  Capabilities Length Overflow

  As defined in [RFC5492] the total length of capabilities that can be
  carried by the BGP Capabilities Optionl Paramter is 255 bytes.  If an
  implementation is constructing a BGP Capabilities Optional Parameter
  and its length exceeds 255 bytes, it is RECOMMENDED to exclude the
  Version Capability.  An implementation may optimally achieve this by
  making the Version Capability the last capablity triple to add to the
  Parameter, and only adding it if there is sufficient space to do so.

---

4.

OLD
  The Version capability MUST only be used for displaying the version
  of a speaker to make troubleshooting easier.  You have a bunch of
  routers with a number of upstreams each.  All of them are with a
  different operating system and routing daemon installed.  Assuming
  that a specific feature is not working or a bug which is not fixed in
  an appropriate version, would allow us to quickly identify the
  pattern which versions are affected.

  Enabling this capability REQUIRED bouncing all existing BGP sessions.
  It MUST be explicitly configured to advertise the Version capability.
NEW
  The Version Capability MUST only be used for displaying the version
  of a BGP speaker's router daemon to make troubleshooting easier.

  Consider a group of routers each with a number of upstream nodes, and
  suppose that each router has a different operating system and
  different routing daemon at a different version installed.  Assuming
  that a specific feature is not working or that there is a bug which
  has not been fixed in a particular version of the code, knowledge of
  hte routing daemon versions would allow an operator to quickly
  identify the pattern of which versions are affected.

  Enabling (i.e., turning on) this capability requires bouncing all
  existing BGP sessions, and the feature MUST be explicitly configured
  before an implementation advertizes the Version Capability.
END

---

4.

Please split the example into a new subsection "4.1 Example Usage"
because we need to make it clear that the example is non-normative.

---

4.

I think that Figures 2 and 3 don't actually need captions as they run on
as examples in the text.

---

4.

The line length problems reported by idnits are all in Figure 2
I understand it is a problem reproducing text output from FRR when that
output exceed the line length, but we have to fix this some how.

---

Table 1 needs to mirror the registry maintained by IANA at
https://www.iana.org/assignments/capability-codes/ so I think you should
have...


  +-------+-----------------+-------------+-------------------+
  | Value |  Description  |  Reference  | Change Controller |
  +-------+-----------------+-------------+-------------------+
  |  TBD  |    Version    | [This.I-D]  |      IETF        |
  |      |    Capability  |            |                  |
  +-------+-----------------+-------------+-------------------+

Note that [This.I-D] is how we handle self-references.

---

Section 6 also needs some work to smooth out the English and to group
together the issues with their solutions.

OLD
6.  Security Considerations

  The Version Capability can be treated as sensitive information, thus
  it would be easier for an attacker to exploit by knowing the specific
  version of the BGP speaker.  This information can be gathered in BGP
  OPEN messages.

  The Version Capability MUST be configurable with a vendor-specific
  knob to be able to enable or disable the capability.  The vendor
  might implement to disable this capability per neighbor.

  It would be safe to enable this for iBGP or inside the same tenant
  where you have full control and the BGP speaker is behind exit
  points.

  The Version Capability information can be gathered in BGP OPEN
  messages.

  Modifying the information advertised by a router might lead to
  attacks including bogus software upgrades and also might mask the
  causes of faults in the network.

  Advertising which versions of code and from which vendor it comes may
  facilitate a number of social-engineering attacks.  A lot of BGP
  implementations leave TCP/179 open and this could lead to sensitive
  information disclosure.  This capability is NOT RECOMMENDED for eBGP
  use.

  Sensitive information leaks can be minimized by using the [RFC5082]
  mechanism or firewalls to filter out TCP 179 port from untrusted
  networks.  This capability can be disabled per neighbor, thus the
  sensitive information can't be disclosed to untrusted neighbors.
NEW
6.  Security Considerations

  The Version Capability should be treated as sensitive information: it
  could be easier for an attacker to exploit the system if they know
  the specific version of a BGP speaker.  This information could be
  gathered by inspecting BGP OPEN messages that carry the Version
  Capability defined in this document.  Using engryption to protect the
  information exchanged in BGP sessions SHOULD, therefore, be carefully
  considered when this feature is enabled.  Suitable encryption can be
  achieved by protecting the BGP session using TLS [RFC5246].

  Furthermore, knowledge of which versions of code is running on a
  given router and from which vendor it comes may facilitate a number
  of social-engineering attacks.  This further adds to the desire to
  protect this information through encryption.

  Modifying the information advertised by a router might lead to
  attacks including bogus software upgrades and also might mask the
  causes of faults in the network.  This can be mitigated by protecting
  the BGP session using TLS.

  Many BGP implementations leave TCP port 179 open in order to be able
  to establish sessions with new neighbors.  This could lead to an
  attack where a rogue BGP implementation attempts to open a session
  and learns the version information from the responding peer.



  The Version Capability MUST be configurable with a vendor-specific
  knob to be able to enable or disable the capability.  The vendor
  might implement to disable this capability per neighbor.

  It would be safe to enable this for iBGP or inside the same tenant
  where you have full control and the BGP speaker is behind exit
  points.


  This capability is NOT RECOMMENDED for eBGP
  use.

  Sensitive information leaks can be minimized by using the [RFC5082]
  mechanism or firewalls to filter out TCP 179 port from untrusted
  networks.  This capability can be disabled per neighbor, thus the
  sensitive information can't be disclosed to untrusted neighbors.
END

---

7.1

Please add [RFC3629] and [RFC5246] as normative references.

---

I don't believe that [FRRouting] is or should be a normative reference.
Please move it to 7.2