Hi Stephen, On Thu, Oct 10, 2024 at 07:45:50AM +0100, Stephen Farrell wrote: > 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. What is the "potential DoS"? I do not understand what attack you see, could you try to describe it more clearly? I'll try again to describe why I do not see a DoS attack enabled by Unaffiliated BFD Echo: 1) Unaffiliated BFD Echo is a protocol spoken by a single system, let's call it "real-A", with itself. This system, "real-A", does not answer protocol packets, thus it does not reflect them. This is not a request/response protocol. A probe (called "BFD Echo") is sent out and either received or not received by the sender. Thus "real-A" does not answer spoofed packets from any "bad-device-A". Thus "bad-device-A" cannot reflect BFD Echo packets via "real-A". 2) "Real-A" creates BFD Echo packets, sends them to a directly connected router (device B in figure 1 of draft-ietf-bfd-unaffiliated-echo-11), and checks if it receives them back from the router. The router does not know that it forwards BFD Echo packets, because its forwarding function only works on IP. Thus this "reflection" is not introduced by Unaffiliated BFD Echo, but by IP [RFC791]. Sending IP packets to a router with the expectation that the router forwards them towards their destination is the basic operation of IP networks. > >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. If "real-A" receives its own packets it can assume that IP packets can be transported from "real-A" to the router and also from the router to "real-A". If a "bad-device-A" spoofs packets that reach "real-A", and "real-A" cannot determine those packets are spoofed, it might be tricked into regarding IP forwarding from and to the router to work even when it does not. This may create a DoS situation if it prevents "real-A" from failing over to another router. This spoofing does not require the monitored router, it can be done via a link common between "real-A" and "bad-device-A" or via another router directly connected to both "real-A" and "bad-device-B". Using BFD authentication allows "real-A" to discriminate between its own messages and those of "bad-device-A". This allows "real-A" to ignore spoofed messages and correctly detect an IP forwarding problem. Br, Erik -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
