Hi Stephen, Please see inline.
Original From: StephenFarrell <[email protected]> To: 肖敏10093570; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月10日 14:46 Subject: [Last-Call] Re: Secdir last call review of draft-ietf-bfd-unaffiliated-echo-11 Hiya, On 10/10/24 03:16, [email protected] wrote: > [XM]>>> No, B is NOT able to any validation, B simply loops > Unaffiliated BFD Echo packets back to A. As Erik Auerswald has > indicated, this kind of DoS attack can happen without Unaffiliated > BFD Echo, i.e., this kind of DoS attack is irrelevant to > Unaffiliated BFD Echo. Well, in that case ISTM the potential DoS is not dealt with properly in this spec. That's I guess a thing the IESG can handle, so we don't need to bottom out on it between us. [XM]>>> OK, that's fine. > So IMHO what we can do is to ask the real-A > to include some form of authentication. I don't really get what you're saying there, sorry, as there is no point in "including some form of authentication" unless a relevant party validates that. Again though, the IESG can figure this out so we don't need to. [XM]>>> I mean that when the real-A sends Unaffiliated BFD Echo packets, an Authentication Section as defined in Section 4.1 of RFC 5880 SHOULD be included in the Unaffiliated BFD Echo packet. By this means, if DoS attack by a bad-A happens, when the real-A receives both Unaffiliated BFD Echo packet from itself and the spoofed BFD Echo packet from the bad-A, the real-A can use the Authentication Section to do filtering. Best Regards, Xiao Min Cheers, S. -- last-call mailing list -- [email protected] To unsubscribe send an email to [email protected]
