[Tsv-art] Tsvart last call review of draft-ietf-bfd-unsolicited-11

[Magnus Westerlund via Datatracker <[e-mail]>]

Reviewer: Magnus Westerlund
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

I have a couple comments focused around how to deal with overload or attacks
using unsolicited BFD.

1) Section 7.1
The formulations around the mitigations are poorly worded.
a) First the lead in to the bullet list states that this is mandatory but it
fails to use and RFC 2119/8174 words. b) "Limit the feature to specific
interfaces, and to single-hop BFD with "TTL=255"
     [RFC5082]." I would think that this sentence would rather state that one
     MUST use the RFC 5082 security mechanism for the BFD traffic. What is
     unclear to me from not having read RFC 5082 in detail is if this mechanism
     works well for this traffic or gets additional traffic into problems due
     to scoping which appear to be interface wide. Thus, are further
     clarifications on usage needed?
c) "Use BFD authentication, see [RFC5880]. In some environments, e.g. when
using an IXP, BFD authentication can not be used because of the lack of
coordination into the operation of the two endpoints of the BFD session. In
other environments, e.g. when BFD is used to track the next hop of static
routes, it is possible to use BFD authentication: this comes with the extra
cost of configuring matching key-chains at the two endpoints. If BFD
authentication is used, the Meticulous Keyed SHA1 mechanism SHOULD be used."
This mitigation usage is deployment dependent, thus better care in formulation
related to this is needed. This appears to be a MUST unless in this particular
situation and should be clearer. Also the actual support required for interop
appears a bit weak without having looked into RFC 5880 in detail. But only a
SHOULD support algorithm?

2) Not being an expert in BFD and its control parts it appears that there are
no mechanism for terminating an ongoing BFD session as the passive player in
case of any overload. It is even unclear if there are any other mechanism than
refusing to respond to a new session for the passive entity when getting
unsolicitied BFD. So it would be good if the document could be more explicit if
there are any action the passive entity can do if ending up with to many BFD
sessions? I understand the goal here is to limit the number of potential peers
as well as ensuring that they are trusted entities even before any packets are
sent, but are there really no method to stop the session?

3) Section 7.2:
So this section lays out the "knobs" that are sensitive. But it appears to not
really put any requirement on that one actually protects. Is this how things
usually are done i YANG modules?