Hi Spencer, many thanks for the most helpful suggestion. I will use it with a minor modification:
s/multipath/multipoint/. Regards, Greg On Tue, May 29, 2018 at 10:05 AM, Spencer Dawkins at IETF < spencerdawkins.i...@gmail.com> wrote: > Mirja and I do read these reviews, but don't usually comment on them while > the authors and reviewers are still chatting. But, on one point ... > > On Tue, May 29, 2018 at 5:23 AM Bob Briscoe <i...@bobbriscoe.net> wrote: > >> Greg, >> >> On 26/05/18 20:49, Greg Mirsky wrote: >> > > [snip] > >> NEW TEXT: >> >> Use of shared keys to authenticate BFD Control packet in multipoint >> scenarios is limited because tail can spoof the head from the >> viewpoint of the other tails. Thus, if shared keys are used, all >> tails MUST be trusted not to spoof the head. >> >> [BB]: Normally a MUST is applied to implementations. It would be rather >> odd to require users/operators to satisfy a spec requirement, particularly >> requiring them to trust each other. I think this should be written as an >> applicability statement not a normative requirement. >> > > Bob is formally correct here, but it may be useful for me to say that I do > see "requirements" language used to provide guidance about security and > about operational considerations (as here). > > If I understand Bob's suggestion to be something like > > NEW > > Shared keys in multipath scenarios allow any tail to spoof > the head from the viewpoint of any other tail. For this reason, > using shared keys to authenticate BFD Control packets in multipoint > scenarios is a significant security exposure unless all tails can > be trusted not to spoof the head. > > that would also work. > > "Do the right thing", of course. > > Spencer > > >
