Kathleen, > On May 2, 2016, at 7:48 PM, Manav Bhatia <[email protected]> wrote: > > Hi Kathleen, > > DISCUSS: > ---------------------------------------------------------------------- > > This should be pretty easy to address. In the security consideration > section, the following recommendation appears: > > o SBFDReflector MUST NOT look at the crypto sequence number before > accepting the packet. > > Could you please add text to say what happens (what attacks are possible) > if this is looked at? There is nothing to stop the crypt sequence number > from being looked at, right? Is there a way to actually prevent that? > > > SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer state, > and is thus incapable of doing the crypto-sequence checks. It has no idea of > last sequence number that it had seen from a BFD peer, and hence CANNOT > compare the new sequence number. Its for this reason that we mandate that the > reflectors MUST NOT look at the sequence numbers. >
Further to this, the SBFDReflector can be receiving S-BFD packets from multiple SBFDInitiators. Hence, the authentications can be used from BFD but not the sequence numbers. > We cant prevent a peer from looking at the sequence number -- thats an > implementation specific issue. The implementation is violating the standard. > Not sure what we can do to prevent that. > > Does this help? > We could also explain the rational behind this requirement a bit better. Would that help? Thanks, — Carlos. > Cheers, Manav >
signature.asc
Description: Message signed with OpenPGP using GPGMail
