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.
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.
Yes, getting the timing right for this approach would appear to be a very tricky issue to solve!
regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
