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.
