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 <[email protected]> wrote: > Greg, > > The actual idea of a remote system is farcical for this mode. U-bfd the > system is only talking to itself. > > Jeff > > On Oct 15, 2024, at 16:22, Greg Mirsky <[email protected]> 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, > Greg > > On Tue, Oct 15, 2024 at 2:17 PM Jeffrey Haas <[email protected]> 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?) >> >
