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

[Minto Jeyananth <[e-mail]>]

Susan,

Thanks for the review. Please see inline [minto2]

From: Susan Hares <[e-mail]>
Date: Saturday, March 19, 2022 at 5:21 AM
To: Minto Jeyananth <[e-mail]>, 'Jeffrey Haas' <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
[External Email. Be cautious of content]

Jeff and Minto:
[WG chair hat off]
[Individual contributor hat on]

I have a few additional questions below.

Two high level questions:

1) What non-BGP use are you proposing for your protocol?

[minto2] None. Though, technically Link tlv (section 4.2.6) could be treated as non bgp parameter.


2) What is the normal rate of your timers?
[minto2] Protocol required that a sender should refresh advertise state before it expires.
In steady-state refresh, the sender shall refresh the states after the advertised lifetime goes below 2/3 of the time. For e.g if the advertised remaining lifetime is 900 seconds, then it may refresh for every 300 seconds +/- jitter.
In short-live fast-refresh mode, the sender will not consider the advertised remaining lifetime. And sender switches to a rapid timer, typically 250 milliseconds, for a second.

Thank you for your hard work on this protocol!

Sue


From: Idr [mailto:[e-mail]] On Behalf Of Minto Jeyananth
Sent: Friday, March 18, 2022 6:42 PM
To: Jeffrey Haas; [e-mail]
Cc: [e-mail]
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery


Jeff,
   Thanks for the review.  At a high level, the SA protocol design trade-off is given to simplicity(the requirement is to just bring up BGP).  Any higher-level complexity can be very well handled by BGP.

Please see inline [minto]. A couple of clarifications inline and will address the rest of the comments in the next version of the draft.  Again thanks for the thoughtful review.


From: Jeffrey Haas <[e-mail]>
Date: Monday, March 7, 2022 at 10:24 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
[External Email. Be cautious of content]


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.
[Sue:  Is there extra state due to the service advertisement?
- Single-hop BGP and "loopback address BGP between directly connected
  speakers" are use cases.
[Sue: Please indicate where you find this information in the text.]
[minto2] Please see section 2.

“Receiver could use this information to bootstrap the single hop bgp and/or loopback address bgp between directly connected bgp speakers
“
- Advertised state is expected to be refreshed; it times out.
- Messages are transmitted peridically.
[sue]: What is your normal time frame.  Page 9 does not provide this information.
It states:  “A sender should periodically send PDU to refresh the advertised  information before the time expires.”
[minto2] This is same as point 2). Will add a section on next version.
-----

Protocol properties:

> - PDU messages are simple 1-octet type, 2-octet length TLV format.
[Sue: Type is 8 bits.  Do you see any future expansion for the non-BGP use case? ]]
[minto2] No. Message type also provide 8 bits. Message is provide logical grouping of TLVs.
>- 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.
Is the structure of the two PDUs due to the non-BGP use case?
[minto2] 2 messages. Base message provide base operation such as timer authentication etc … “
[minto2] excerpt from draft

“The document defines following messages.

1.    SA Base message

The SA Base message is mandatory message and mainly used for the

protocol operation.





2.    BGP service advertisement message

BGP Service Advertisement message provides transport information to

   bring up the bgp session.

“

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?
[minto] The message-id per message type will help in debugging per message level.
The individual field definitions should list whether they are mandatory or
optional.
[minto] will fix it in next version.


The Remaining lifetime field is 2-octets.  65k seconds is 1k hours. That's
overly long.  :-)

[minto] We always run into not enough size.  And 65k is 18hours.
[Sue: Why are you cycling so much?  What are the timer limits?]

- 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.

[minto] Yes. It is not explicitly mentioned in spec. But a stateless implementation, could simply discard subsequent pdu after it bring up  bgp.
[Sue:  It would be helpful to mention this in the specification.
[minto2] Will add it next version. In short this is same as  point 2) response.

- Expiry of records might want to interact with Refresh request?
[minto] Good suggestion. Will add it in some section in next version.
[Sue] How are you keeping track of the expiry of records in your implementation?
[minto2] A stateful implementation keep the peer’s advertised state until the remaining-life expire.

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?
[minto] Will add a new section on the refresh request and fast send.


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.
[minto] Will fix it in next version.


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.
[minto] Will fix it in next version.


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. :-)
[Sue: Do you  need the MSS of 4 bytes for some of your retransmission? }

[minto2] No. will fix it next version

-----

Protocol behavior:
- The procedure really needs to talk about some possible default timer
  values.
[minto] The preference be automatic. The value might change from fast(order of milliseconds) to steady state value based on local load.
[Sue: Could you explain how the preference might be automatic.
It would be helpful to explain this in the protocol.]

[minto2] Will add timer section in next version.

- 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".

[minto] will add a section in next version.
[Sue:] Does the refresh have a “pull”.

[minto2]  Refresh request TLV ask for the receiver to resend the pdu,



Thanks

-minto


- When specifying "all routers", include the multicast group in the text for
  clarity.
[minto] will fix it in next version.

- 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.
[minto] Will fix it next version.


-----

Misc:
- The document should really remove references to UDP port 179.  IANA hasn't
  assigned this.  It should simply be "TBD".
[minto] will fix it.

- 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.
[minto] ok. My initial thought, if a need special tlv code across all message then we can use it.


-minto

-----

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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$>
[2] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN2snlIPMw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN2snlIPMw$>


Juniper Business Use Only


Juniper Business Use Only