Alvaro, On Dec 14, 2022, at 10:11 AM, Alvaro Retana via Datatracker <[email protected]> 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
