Hi Stephen,
Please see inline.
Original
From: StephenFarrell <stephen.farrell@xxxxxxxxx>
To: 肖敏10093570;
Cc: secdir@xxxxxxxx <secdir@xxxxxxxx>;draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx <draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;rtg-bfd@xxxxxxxx <rtg-bfd@xxxxxxxx>;
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, xiao.min2@xxxxxxxxxx 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.
> 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
S.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
