[Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

[Jeffrey Haas <[e-mail]>]

Working Group,

As noted in another thread, we had a late entrant to the BGP
autoconfiguration options.  In an attempt to spur along discussion of the
L3ND proposal, I posted my analysis of that proposal in the same vein as the
discussions we'd had over the course of the various IDR interim meetings and
also as covered in the Appndices of draft-ietf-idr-bgp-autoconf-considerations.[1]

While draft-minto-idr-bgp-autodiscovery[2] had been presented and received
discussion at those interims, similar analysis as that in the design team's
document wasn't done.  The authors of L3ND have asked for similar treatment
for draft-minto.

Below, find my observations on the draft with questions and commentary
intermixed.  I finish this response with my high level analysis and personal
opinion on what these properties accomplish.

-----

Scoping Discussion:

- The proposal starts by noting that it covers more general discovery by
  labeling itself "Service Advertisement".  So, the scope is broader than
  simply BGP autoconfiguration state.
- Single-hop BGP and "loopback address BGP between directly connected
  speakers" are use cases.
- Advertised state is expected to be refreshed; it times out.
- Messages are transmitted peridically.

-----

Protocol properties:

- PDU messages are simple 1-octet type, 2-octet length TLV format.
- Two top-level PDUs defined:
  + Service Advertisement PDU
    * Defines "lifetime" properties of the advertisements.  A "time to live"
      field.
    * A Config sequence TLV.  Compare vs. "BGP Session Protocol State
      Version Number" in the requirements.
    * Authentication TLV. Provides authentication of Service Advertisements.
    * Refresh request TLV.  The only message that attempts to trigger
      another Service advertisement speaker to send messages.

Section 3's TLV format runs somewhat backwards from many RFCs:
- The top level TLV, the SA PDU, is shown last.
- The individual messages in an SA PDU is shown in the middle.
- The generic TLV structure is at the top.

Message ID, is per-message.  It's a little unclear how individual message
IDs within a given SA PDU is helpful.  Should the message ID be per SA PDU
instead?

The individual field definitions should list whether they are mandatory or
optional. 

The Remaining lifetime field is 2-octets.  65k seconds is 1k hours. That's
overly long.  :-) 
- This field should probably be bound to a much lower value for sending.
- Implementations may wish to bound the maximum time they're willing to
  keep.
- Expiry of records might want to interact with Refresh request?

The Refresh request procedure is under-specified.  Since it's the one
field that causes another SA speaker to respond, it should describe:
- What does responding to such a trigger do to the sender's timers for the
  message?
- What sort of rate limiting should be done for responding to the triggers?

Local address TLV:
- The flags and Res fields need the standard "MUST BE ZERO on send, SHOULD
  BE ignored on receipt" text.
- The flags field needs an IANA Considerations section.
- Preference doesn't have any normative text as to how it should be used.
- The contents of sections 4.2.1 and 4.2.2 blend together a bit.

Transport properties:
- Being at the top level of the SA message, the implication is that these
  apply uniformly to the Local Address in that message.

Security TTL:
- Currently specified as a zero-length flag.
- Some GTSM might require 254 rather than 255.  This is inconsistently
  flagged in many pieces of configuration state across IETF.

Security authentication:
- A selector for BGP's authentication mechanism.
- Has TCP-MD5 and TCP-AO
- Need an IANA registry.
- Not bound to any particular address in the Local Address field.  If
  security needs to vary, like any other attribute, it needs to go into a
  separate SA message.

MSS:
- 4 bytes is probably too big. :-)

-----

Protocol behavior:
- The procedure really needs to talk about some possible default timer
  values.
- The procedure indicates that it may refresh more frequently than the
  expiration time.  It should offer advice as to how often it may do so.  An
  example from BGP's holdtime would be to send at least once in 1/3 of that
  interval.  Other options could be to have two timers described: retention
  timer (placed in PDU) and transmit timer (configuration state).
- Fast transmit could use some procedure.  For example, transmit X times in
  Y interval.
  + The refresh TLV provides some ability to do a "pull".
- When specifying "all routers", include the multicast group in the text for
  clarity.
- The procedure argues that you can receive the same state in multiple
  encapsulations; i.e. IPv4 and IPv6.  Some discussion should be given as to
  how to recognize it's the same for puposes of "resetting state".  As an
  example, the Identifier field being the same.
- The transmit procedure supplies some of the "what is mandatory"
  description.  That should be clarified in the TLV descriptions.
- The procedure for handling the identifier vs. IP addresses should be
  clarified.


-----

Misc:
- The document should really remove references to UDP port 179.  IANA hasn't
  assigned this.  It should simply be "TBD".
- Code points should consider starting at 1 rather than 0.  (Jeff's
  opinion.)
- TLVs starting at > 16 should get some discussion as to why that number is
  being used.


-----

Security Properties:
Authentiction TLV for Service Advertisements contain:
<key-id (2-octets), Sequence number (4-octets), Hash/digest (variable)>

(Defined in §4.1.3, procedure in §5.4.)

- The procedure for management of key-ids is left as an opaque detail.  This
  would require implementations to have key id management that includes
  inputs for cipher and shared key.
- The Sequence number field has procedure somewhat similar to BFD's use of
  Sequence number in non-meticulous mode. (See RFC 5880, §4.3+.)
  + I suspect the sequence number comparison features should refer to 
    RFC 1982.  (And the authors of draft-minto may wish to refer to the
    Author list of that RFC. :-)
- The procedure for handling the hash over the PDU is missing many of the
  usual bits of procedure when such hash based mechanisms are done:
  - What value should the PDU's Hash/digest field be set to?
  - Where should the key be placed in the PDU for purposes of calculating
    the hash?
- What are the mandatory hash mechanisms?
  + Is there a benefit to including an authentication type along with just
    the key-id?  Doing so might help simplify procedure by making validation
    always able to determine TLV lengths based on input.
- The receiver procedure needs clarification as to what its desired security
  properties are.  For example, if the receiver expects to receive packets
  with the Authentication TLV, it should require one on receipt.  Otherwise
  there's possibility of an active attacker simply generating Service
  Advertisements without an Authentication TLV.

The mechanism is currently vulnerable to replay attacks.
- This can be somewhat mitigated by reasonable key rotation and limited key
  lifetime.
- Keys really need to be rotated as part of sequence number rollover.
- Sequence number increment procedures need to be bound to prevent certain
  scenarios where a later sequence number has been cached by an attacker and
  used to trigger the "this is a valid next number" and convince listeners
  to ignore the valid but appear to be stale packets.

For fresh starting receivers, they are vulnerable to replay attacks that
keep sequence numbers from synchronizing initially.
+ An epoch/generation value in addition to to the steps above could reduce
  the attack space.  
+ See for example TCP-AO's Sequence Number Extension concept.

The security TLV for the BGP session itself is incomplete.  While 
authentication TLV indicates TCP-AO/TCP-MD5, there needs to be a hint as to
what the connection properties should be.  Key-id, reference to keychain
RFC, etc.  Is ipsec planned for?


-----

Transport Layer Considerations:

- The feature uses (IP) UDP multicast.
- No transport reliability is implied.
- IP fragmentation is implied as the mechanism to deal with packets that are
  too large.
  + Link MTU will thus define how much state can be passed around.
  + Possibility is left in the design (via TBD TLVs) that fragmentation
    might be addressable in the future.

-----

Misc.:

- The document is in need of a spelling and grammar review.  In the interest
  of not cluttering functional analysis when the intent is clear, I will
  send comments on spelling and grammar separately to the authors.

-----

Jeff's read of the proposal:

The protocol is a "shout in the dark" type protocol.  In general, it doesn't
have any particular session layer.  Receivers may, or may not be listening.
For the most part, there is no expectation of a receiver with the expection
of the refresh TLV which is intended to elicit a response from other
senders.  (Compare vs. IGMP/MLDv2.)

Being sessionless, one of its big problems is that the state must be small
enough to fit into link MTU.  This is likely sufficient for many BGP
autodiscovery scenarios, although the question of massive numbers of
messages is raised in discussion about L3ND.

IP fragmentation is offered as a possible method to deal with too-large
messages, but fragmentation is often seen as an attack on IP infrastructure
and in many cases is explicitly filtered.  The draft discussses possible
procedures for extending support via additional TLVs.  If there's intent to
do that, such procedure should be specified early since it would tend to
manifest as one of a common set of prior solutions:
- Split it into a number of additional messages.  Compare vs. PIM Group Set
  Fragmentation.
- Provide a session-based protocol as the extension mechanism.  However,
  that opens attacks against sessions.  Compare possibly vs. LLDPv2.

The SA procedures can be exercised unidirectionally.  This means that a
device may volunteer to have BGP Speakers peer with it, but don't have to
have the rest of the network trying to peer with them.

The timer procedures are underspecified.  Similarlities can be drawn to RIP
and to some extent IGMP/MSDP.

Security procedures for the SA PDU need tightening, as noted above. 

The procedure for keying of BGP sessions is absent and needs text.  Since
the protocol has no privacy, exchanging BGP session keys directly in the
TLVs as cleartext cannot be suggested.

Being sessionless, there is no session infrastructure to be under attack.
The primary ready attacks against the infrastructure are volumetric attacks.
Such attacks beat up on the crypto involved at a cost related to the
strength of the cipher used to protect the validation of the packet.  These
attacks are mitigated, much as similar attacks on TCP-MD5 and TCP-AO, on the
mechanism relying on GTSM.  This restricts such attacks to on-link.

Configuration of security mechanisms are critical for this protocol.  In the
absence of required security, since this protocol advertises state to be
cached for BGP session configuration, unauthenticated messages can be used to:
- Flood the cache of SA state for all listening receivers.
- Cause those receivers to effectively attack hosts at TCP port 179 on the
  local network by trying to BGP peer with them, even if they're not BGP.

-- Jeff (who is up way past his bedtime...)

[1] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/
[2] https://datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery-01