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] > <mailto:[email protected]>> wrote: > >> Kathleen, >> >>> On May 2, 2016, at 7:48 PM, Manav Bhatia <[email protected] >>> <mailto:[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.
Thanks,
— Carlos.
> Thanks,
> Kathleen
>
>> Thanks,
>>
>> — Carlos.
>>
>>> Cheers, Manav
signature.asc
Description: Message signed with OpenPGP using GPGMail
