Geoff Huston wrote: > >> This technique can also be used as a more general traffic > >> amplifier, > >> accumulating attack traffic in-flight between two well-connected > >> but > >> mutually-distant waypoints and then finally delivering it > towards a > >> third party once the RH0-directed oscillations for each packet > are > >> complete. 7-fold amplification has been postulated using this > >> "capacitive effect" [CanSecWest07]. > > > > The discussion about 3rd party implies this is related to spoofing. > In any > > case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, > unless it is > > being reflected back to the source. The traffic is not accumulated, > it is > > reflected back over the same paths multiple times. The postulation is > > irrelevant and without looking it up (just going on 'capacitive'), > likely > > related to latency creating the ability to 'store a large volume of > data'. > > That is just wrong, because the packet is not replicated or stored > beyond a > > single instance in flight. There is at most one instance in flight, > in only > > one direction at a time. The longer the latency, the lower the total > number > > of bit times in any given period that a single RH0 reflection can > impact. > > The total number of bit times for the stream will be the same > independent of > > latency, but they will be spread out over time as the delay goes up. > > > you are right that no packet gets duplicated in this scenario and > ultimately the number of packets in equals the number out. But the > attack relies of the technique of stuffing packets in over an extended > interval and then releasing them all towards the destination in a much > shorter time interval.
This makes no sense. The latency is the same for the entire packet chain, so the delay between the first and last should be the same at the exit, modulo normal queuing jitter. > > My understanding of this form of "capacitance attack" was to send the > first N packets with X number of address pairs in the routing header, > the second set of N packets with Y address pairs in the routing header > (where Y is less than X) and so on. If you get the numbers just right, > then all the packets get released to the destination address at the > same > time - i.e. discharging all the traffic to the ultimate destination in > the routing header address pair "capacitor" at the same time. Well one might try, but reality is that the last hop will just queue the pile and they will arrive serially based on link speed if they are not dropped. Also, unless X & Y are different paths for each time interval, the preceding set of N will be tying up the link queues to preclude the subsequent ones from moving. > > > Yes, getting the timing right for this approach would appear to be a > very tricky issue to solve! I think it is more than timing. It would appear that one needs to choose an appropriate set of X & Y alternative pairs to keep serialization delays from getting in the way of the plan. It is much simpler to tell the army of zombies to ddos a site than it is to figure out the right set of X & Y pairs along with the right number of bounces for each set of N. The FUD over this supposed threat is just feeding the hysteria. As I said earlier, it is reasonable to limit the number of waypoints in the RH0 path. I don't know the right number, but to support the simple scenario of selecting transit across a metro/geo fabric I could be convinced that 1 is right. Others may have different use cases with slightly more. In any case, a small number of waypoints does not raise the threat of dos due to bouncing significantly more than the threat of back-to-back packet dos. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
