[Idr] BGP Auto-Discovery Protocol State Requirements

[Jeffrey Haas <[e-mail]>]

https://tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations-00

To avoid cluttering the adoption call thread, this is sent separately.

Section 2.3 lists the following requirements.  This thread is to discuss
them.

: BGP Session Transport State:
: o  IP addresses
: o  Transport security parameters
: o  GTSM [RFC5082] configuration, if any
: o  BFD [RFC5880] configuration, if any
: 
: BGP Session Protocol State:
: o  AS Numbers
: o  BGP Identifier
: o  Supported AFI/SAFIs
: o  Device Role

A valid criticism I'll take as editor of the document is the session
protocol state section should have had additional material noting that it
may be procedurally optional.  Whether it's optional depends on the desired
behavior of the protocol.  The proposals to date in most cases cover one or
more of these items and tend to universally lack justification as to why
they're in a given document - or not.  

The following attempts to discuss the motivations from design team
discussion during 2021.

-----

To get to a stage where BGP can even send an OPEN message, you have to 
be able to get TCP to connect.  This state is covered by the BGP Session
Transport State.

IP address: MANDATORY
BGP can't come up without knowing what the IP address is.

This state may be carried explicitly in the protocol, or potentially derived
from the protocol transport.  For example, the source address of the
discovery protocol, if it uses IP.  

Even if it uses IP, there are design choices:
- Do you require a discovery protocol message in the address family of the
  peer?  For example, IPv4 discovery message to carry only IPv4?

  + This doubles messages if you support v4 and v6.

- What do you do about mixed-mode peering, e.g. RFC 5549?

---

Transport security parameters: MANDATORY
That parameter may be "NONE" and thus plain TCP.  

If you're requiring TCP-MD5, TCP-AO, or something a bit more exotic like
IPsec, the TCP state machine may not even advance unless you're using the
correct parameters.  

Keychain hints may be needed if you want to use one of these.  

---

GTSM: MANDATORY
If you're using GTSM for your sessions, TCP may not even establish unless
it's on.

Robert points out existing security considerations about using GTSM.
They apply here as well.

---

BFD Configuration: OPTIONAL?

Some BGP implementations don't let their sessions come up or stay up if
there's a mis-match in BFD between the systems.

See draft-ietf-idr-bgp-bfd-strict-mode.  Making support for this draft
mandatory would let this state requirement be dropped.

======================================================================

Once you have the capability of bringing up a BGP session, you have to
decide if you even want to.  There are at least two design choices, each
with specific consequences:

1. The implementation is willing to determine if a peer is acceptable or not
   based on the information exchanged in the BGP OPEN message.  Call this
   "discover at OPEN".  A further implication of this mode is the
   implementation must be willing to service incoming sessions that may drop
   just so they can figure out if they find each other mutually agreeable.
   This becomes a scaling discussion.

2. The implementation wants to know the properties of its potential peer to
   decide if it wants even try to bring up a session.  This enables "peer
   selection".

   The good property is that the peer sending such messages doesn't have to
   service sessions only to immediately drop them.

   The bad property is that this increases disclosure of some BGP
   information to parties that may not eventually be permitted to peer.
   (Security consideration.)

---

A concomitant consideration for implementations using either strategy is the
retry mechanism.  Presume that upon discovering a BGP speaker using the
auto-configuration mechanism that either participant decides that it doesn't
want to continue peering.  Simple examples may be wrong AS number (relevant
for data center fabrics), existing peering session on a different link
(resolved by BGP Identifier), or mis-match in capabilities.

When things aren't acceptable, how should you retry?

1. If you use "discover at OPEN", you have to figure out how often to try to
   bring up a session to see if things have changed.  Perhaps you require a
   manual reset after some interval.  Either way, you're repeatedly trying to
   establish a session and thus it's a scaling consideration.

2. If the peer selection criteria is present in the auto-discovery
   mechanism, the discovering peer can simply wait until it discovers sessions
   with acceptable properties.

   Such a mechanism does introduce the edge case where the discovered
   session's propeties may not match those in the BGP OPEN message.

Auto-discovery protocols need to document how retry will be expected to
work.  The security and transport ADs will want the considerations dealt
with prior to moving to RFC.

-----

The typical state for session selection are the AS Number(s), BGP
Identifier, and supported AFI/SAFIs.  Multiple of the proposed protocols
carry this state.

Device role should not have been in the MUST state, but discussion on how to
auto-configuration is deployed specifically for BGP datacenter fabrics has
raised questions that point to some form of this repeatedly.  This items is
understood to be a contentious point and was going to require IDR list
discussion.


-- Jeff