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

[Jeffrey Haas <[e-mail]>]

Alvaro,

On Dec 14, 2022, at 10:11 AM, Alvaro Retana via Datatracker <[e-mail]> wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (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?

The operational difference is that if you can't use GTSM, you're enabling BFD sessions to be created multiple hops away, potentially with low requirements for authentication.  In the absence of authentication, BFD sessions can be created with asymmetric parameters such that an attacker can keep a session open with a small number of BFD packets while the system running the unsolicited procedures was busy sending packets at a much higher rate.

BFD procedures will prevent a session from moving to Up via blind packet injection due to Discriminators needing to be exchanged.

The possibility thus exists to utilize unsolicited BFD as a packet amplification attack.

Thus, it's not a generally good use case.

Strong authentication, as noted, may permit this to be a useful feature.  However, it's not the expected (nor deployed) use case.


> 
> (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?

S-BFD is a fancy ping mechanism.  Unsolicited BFD permits both sides to participate in actively testing the connection.  Different use cases.

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

It's hard to believe this is a serious comment.  "You'll know it when you see it?"  

That said, what words would you prefer to see here?

-- Jeff