Sent from my iPhone
> On May 2, 2016, at 8:49 PM, Carlos Pignataro (cpignata) <[email protected]> > wrote: > > Hi, Kathleen, > >> On May 2, 2016, at 8:34 PM, [email protected] wrote: >> >> 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. > > Indeed — thanks. I added the following, ready in our working copy: > > @@ -916,7 +916,10 @@ > configured. > > o SBFDReflector MUST NOT look at the crypto sequence number before > - accepting the packet. > + accepting the packet. This is because the SBFDReflector does not > + maintain S-BFD peer state, and because the SBFDReflector can > + receive S-BFD packets from multiple SBFDInitiators. Consequently, > + BFD authentication can be used but not the sequence number. > > o SBFDReflector MAY look at the Auth Key ID in the incoming packet > and verify the authentication data. Excellent, thank you. I'll move it to a comment in the morning for the shepherd & AD to track when approving the draft. Best regards, Kathleen > > > Thanks, > > — Carlos. > >> Thanks, >> Kathleen >> >>> Thanks, >>> >>> — Carlos. >>> >>>> Cheers, Manav >
