Note that I agree wholeheartedly with this analysis. The scenario Stephen points out is a reflection attack, and thus potentially has a role in obscuring the attacker, but it is NOT an amplification attack. The device providing the looping service is simply acting as a forwarding router. The unaffiliated BFD instance has multiple opportunities to not pay attention to the spoofed traffic: - GTSM is recommended. This ideally would reduce the attacker to being on-link. - BFD authentication is recommended. This will avoid disrupting the unaffiliated session. - BFD authentication mechanisms that include a sequence number can reduce the attack space of an attacker trying to use the cryptographic mechanism as a CPU exhaustion attack. However, an on-link attacker may be able to observe the sequence number. -- Jeff > On Oct 10, 2024, at 6:00 AM, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx> wrote: > > 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
