[Last-Call] Re: Secdir last call review of draft-ietf-bfd-unaffiliated-echo-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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月09日 23:53
Subject: [Last-Call] Re: Secdir last call review of draft-ietf-bfd-unaffiliated-echo-11

Hiya,

On 10/9/24 07:41, xiao.min2@xxxxxxxxxx wrote:
> NEW 
> As specified in Section 5 of [RFC5880], BFD Echo packets may be 
> spoofed. Specifically for Unaffiliated BFD Echo, a DoS attacker may
> send spoofed Unaffiliated BFD Echo packets to the loop-back device,
> so some form of authentication SHOULD be included.

I'm still not clear if you do or do not mean that B SHOULD
be able to validate whatever authentication is included. If
B doesn't check then it seems the DoS won't be mitigated, or
am I still confused?

[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. So IMHO what we can do is to ask the real-A to include some form of authentication.


Best Regards,

Xiao Min

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux