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.ietf@xxxxxxxxx> 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 <ietf@xxxxxxxxxxxxxx> wrote:Greg,
On 26/05/18 20:49, Greg Mirsky wrote:[snip]NEW TEXT:[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.Use of shared keys to authenticate BFD Control packet in multipointscenarios is limited because tail can spoof the head from theviewpoint of the other tails. Thus, if shared keys are used, alltails MUST be trusted not to spoof the head..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 likeNEWShared keys in multipath scenarios allow any tail to spoofthe head from the viewpoint of any other tail. For this reason,using shared keys to authenticate BFD Control packets in multipointscenarios is a significant security exposure unless all tails canbe trusted not to spoof the head.that would also work."Do the right thing", of course.Spencer
