Hi Jeff,
I think I understand the idea of the well-behaved U-BFD. But what guards U-BFD provides against an ill-intended system that uses U-BFD? For example, using draft-lin-bfd-path-consistency-over-sr to spoof packets? A system with enabled as U-BFD reflector will simply flood these packets onto unsuspecting node(s). Note, that would not be possibly using Echo BFD per RFC 5880 as there must be a BFD session in Up state over that SR Policy. AFAICS, Authentication of U-BFD does not mitigate that attack vector.
Regards,
Greg
On Tue, Oct 15, 2024 at 3:27 PM Jeffrey Haas <jhaas@xxxxxxxx> wrote:
Greg,The actual idea of a remote system is farcical for this mode. U-bfd the system is only talking to itself.JeffOn Oct 15, 2024, at 16:22, Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:Hi Jeff,AFAIK, in RFC 5880-based BFD, an encapsulated BFD packet will be validated according to RFC 5880. U-BFD has no consideration for validating a packet by the remote system.Regards,GregOn Tue, Oct 15, 2024 at 2:17 PM Jeffrey Haas <jhaas@xxxxxxxx> wrote:Greg,
On Tue, Oct 15, 2024 at 01:54:04PM -0700, Greg Mirsky wrote:
> Hi Brian, et al,
> I share your concern regarding U-BFD proliferation on the Internet. For
> example,
> https://datatracker.ietf.org/doc/draft-lin-bfd-path-consistency-over-sr/
> discusses using U-BFD over SR Policies, SRv6 and SR-MPLS, to monitor
> candidate paths. IMHO, that is a very troubling idea.
The troubling item is that it's possible to source SRv6 traffic remotely
across the Internet.
https://datatracker.ietf.org/doc/html/draft-raviolli-intarea-trusted-domain-srv6-03
describes the problem space and a possible mitigation.
What's next - complaints that you can encapsulate BFD in IP-in-IP or GRE
packets? MPLS? Oh wait we have that one...
-- Jeff (time to write the "packet encspsulated in Foo considered harmful" 1 April RFC?)
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
