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

[Alvaro Retana <[e-mail]>]

On March 20, 2023 at 9:21:51 PM, Jeffrey Haas wrote:

Jeff:

Hi!

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


Ok -- then, why even mention multihop?  The text should either
indicate that the document only applies to single hop, or explain the
security risks.



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

The comparison then seems out of place and unnecessary.


Note that these are non-blocking comments.  I trust that you will do
the right thing to avoid unnecessary confusion.

Thanks!

Alvaro.