Alvaro Retana's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-bfd-unsolicited-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document attempts to do two things: specify "unsolicited BFD" and define a
YANG model for its management.  I am happy to include both in the same
document, but the specification of the protocol mechanisms falls short and
results in a document that lacks clarity.  While YANG is the preferred
management mechanism, it should be possible to implement and manage the feature
without the model.

Most of my concerns are from Section 2 (line numbers from idnits):

154        Passive unsolicited BFD support MUST be disabled by default, and MUST
155        require explicit configuration to be enabled.  On the passive side,
156        the desired BFD parameters SHOULD be configurable.  The passive side
157        MAY also choose to use the parameters that the active side uses in
158        its BFD Control packets.  The "My Discriminator", however, MUST be
159        chosen to allow multiple unsolicited BFD sessions.

(A) "the desired BFD parameters SHOULD be configurable"

Which parameters are those?  The YANG model uses bfd-types:base-cfg-parms,
which only includes a basic set.  The point here is that this document's
specification part is incomplete because it doesn't specify which parameters
"SHOULD be configurable".

(B) The YANG model offers global and per-interface configuration options.  The
specification doesn't discuss hierarchical configuration or whether one type
should take precedence over the other.  [Related to Rob's DISCUSS.]

This point was discussed on the mailing list, where it was pointed out that
per-interface configuration should override global configuration [1], but that
discussion is not reflected in the document.

[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/GI_eNtxcEeh2_vTl9zfq7K6V1X4

171        When the passive side receives an incoming BFD Control packet on a
172        numbered interfaces, the source address of that packet MUST belong to
173        the subnet of the interface on which the BFD packet is received.  The
174        source address of the BFD Control packet SHOULD be validated against
175        expected routing protocol peer addresses on that interface.

(C) "SHOULD be validated"

What does validating the source address "against expected routing protocol peer
addresses on that interface" entail?  Is it just a comparison?  Please be
explicit on what the normative behavior should be.

When is it ok to not validate?  Why is this behavior recommended and not
required?

If the validation is performed, is there an expected action if the source
address does not correspond to an "expected routing protocol peer addresses on
that interface"?  Where does this "expected" list come from?  On a LAN, it
seems like any address would be valid since a router doesn't know the list of
IGP neighbors beforehand.

177        The passive side MUST then start sending BFD Control packets and
178        perform the necessary procedure for bringing up, maintaining and
179        tearing down the BFD session.  If the BFD session fails to get
180        established within certain specified time, or if an established BFD
181        session goes down, the passive side SHOULD stop sending BFD Control
182        packets and MAY delete the BFD session created until BFD Control
183        packets are initiated by the active side again.

(D) "If the BFD session fails to get established within certain specified
time..."

[nit] s/within certain specified time/within a certain specified time

Where does a "certain specified time" come from?  Is it configurable?  Does it
correspond to any of the state variables in rfc5880?

(E) "SHOULD stop sending BFD Control packets"

When is it ok not to stop sending BFD control packets?  Why would the node
continue sending packets if the session is not established (or goes down)?  Why
is this behavior recommended and not required?

185        When an Unsolicited BFD session goes down, an implementation MAY
186        retain the session state for a period of time.  Retaining this state
187        can be useful for operational purposes.

(F) Not exactly a contradiction, but confusing normative statements (between
this paragraph and the one before): "MAY delete" vs "MAY retain" for the same
event ("BFD session goes down").


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) I support Rob's and Lars' DISCUSS positions.

(1) The Introduction makes several claims that must be developed further or
eliminated to avoid further confusion.

(1a)

131        The procedure described in this document could be applied to BFD for
132        Multihop paths [RFC5883].  However, because of security risks, this
133        document applies only to BFD for single IP hops [RFC5881].

At first glance, I didn't see anything in rfc5883 that would prevent a node in
the passive role from following this specification.  What am I missing?

Aren't the security risks already addressed in rfc5883?

(1b)

135        Compared to the "Seamless BFD" [RFC7880], this proposal involves only
136        minor procedural enhancements to the widely deployed BFD itself.
137        Thus we believe that this proposal is inherently simpler in the
138        protocol itself and deployment.  As an example, it does not require
139        the exchange of BFD discriminators over an out-of-band channel before
140        BFD session bring-up.

Given that this proposal claims to be better (or at least simpler) than S-BFD,
what should an operator consider when deciding which to use?  Are they covering
similar use cases?  If this is so much better, why is rfc7880 not deprecated?

(1c)

142        When BGP Add-Path [RFC7911] is deployed at an IXP using a Route
143        Server, multiple BGP paths (when they exist) can be made available to
144        the clients of the Route Server as described in [RFC7947].  The
145        "unsolicited BFD" can be used in BGP route selection by these clients
146        to eliminate paths with "inaccessible nexthops".

I guess that this part ("inaccessible nexthops") refers to "unresolvable
routes" (from §9.1.2.1/rfc4271).  Is that the correct assumption?

First, please be consistent with the terminology.

The text above says that ""unsolicited BFD" can be used in BGP route
selection".  Where is the interaction of BFD (in general -- not just
unsolicited BFD) and BGP specified?

(2) I am confused by the indication that this document Updates rfc9314 because
no change is proposed to that RFC.  Instead, the YANG model augments the model
in rfc9314 with optional (to the base BFD) functionality.  In my opinion, this
is different than a formal Update, which is why rfc5880/rfc5881 are not tagged
as being Updated either.

[Because the use of the Updates tag is not clearly defined, then I'm not making
this comment part of my DISCUSS.]

(3) The "BFD Protocol Security Considerations" (Section 7.1) also needs work:

458        The same security considerations and protection measures as those
459        described in [RFC5880] and [RFC5881] apply to this document.  In
460        addition, with "unsolicited BFD" there is potential risk for
461        excessive resource usage by BFD from "unexpected" remote systems.  To
462        mitigate such risks, the following measures are mandatory:

[minor] For clarity, consider using rfc2119 language above: 
s/mandatory/REQUIRED

Note that the last two bullets are conditional statements, which may not be
aligned with the intent of making the measures mandatory.

464        *  Limit the feature to specific interfaces, and to single-hop BFD
465           with "TTL=255" [RFC5082].

GTSM is already required in rfc5880/rfc5881.  Does it need to be required again?

466        *  Apply "policy" to allow BFD packets only from certain subnets or
467           hosts.

[nit] s/allow BFD packets/process BFD packets

Given the statement in the Introduction about this document applying only to
single IP hops, it seems that "certain subnets" are unnecessary as all the
addresses on connected interfaces should fall on the same subnet.

468        *  Deploy the feature only in certain "trustworthy" environment,
469           e.g., at an IXP, or between a provider and its customers.

If this measure is mandatory, please expand on what a ""trustworthy"
environment" is.

470        *  Use BFD authentication, see [RFC5880].  In some environments, e.g.
471           when using an IXP, BFD authentication can not be used because of
472           the lack of coordination into the operation of the two endpoints
473           of the BFD session.  In other environments, e.g. when BFD is used
474           to track the next hop of static routes, it is possible to use BFD
475           authentication: this comes with the extra cost of configuring
476           matching key-chains at the two endpoints.  If BFD authentication
477           is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.