Hi, Thanks for the quick responses. See inline
Sent from my iPhone > On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) <[email protected]> > wrote: > > 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? > Yes, that would be helpful. I'm glad to see that this is not an issue. Thanks, Kathleen > Thanks, > > — Carlos. > >> Cheers, Manav >
