Joe Abley wrote: > Hi Tony, > > On 6-Jun-2007, at 19:31, Tony Hain wrote: > > > There is no 'amplification', so the abstract is just wrong. > > The candidate -01 contains the following text: > > A single RH0 may contain multiple waypoint addresses, and the same > address may be included more than once in the same RH0. This > allows > a packet to be constructed such that it will oscillate between two > RH0-processing hosts or routers many times. This allows a stream > of > packets from an attacker to be amplified along the path between two > remote routers, which could be used to cause congestion along > arbitrary remote paths and hence act as a denial-of-service > mechanism. 88-fold amplification has been demonstrated using this > technique [CanSecWest07].
The stream is not amplified, it is still a single stream, and it is only one packet at a time that has to wait for reception before being reflected back. The total traffic volume over a given path may be higher, but this is not a multiplication of the number of streams. > > 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. > > Various IPv6 transition mechanisms involve the transmission of IPv6 > packets through tunnels built on IPv4 infrastructure (e.g. > [RFC2893], [RFC3056]). Tunnels remain widely-used at the time of > writing for the transmission of IPv6 traffic over IPv4 networks. > The > use of such tunnels can result in IPv6 paths which include a small > number of routers apparently connected by very high latency > circuits > (tunnels). Such paths provide opportunities to keep packets in- > flight for longer, with corresponding increases in amplification > potential. This is absolute BS. The type of path has absolutely nothing to do with the 'opportunity' to exercise the exploit, and the fact that the packet is in flight longer actually lowers the volume of traffic over a unit of time. In any case the total number of bits is the same no matter what the latency is, so tunneling has absolutely no ability to 'increase' the amplification potential. > > That text attempts to summarise three techniques which, facilitated > by the widespread availability of RH0 processing, facilitates > amplification which could be used as part of a denial-of-service > attack. > > If you have objections to the text I quoted above, it would help me > if you could spell them out. I find it far easier to grasp objections > if they are grounded in specific text. > > > The crap in the document about an anycast destination being > > an amplification shows how little understanding there is about the > > concept. > > If you can find text that equates an anycast destination being "an > amplification", please point it out so I can remove it. 5.4 By including RH0 with a waypoint address within the catchment area of a remote anycast node, a single client can send traffic to multiple anycast nodes providing the same service, avoiding the isolation of such traffic to a single node which would otherwise result. The traffic will always go to one-and-only-one anycast node. It may not be the same one that would have been selected without RH0, but it will not go to multiple nodes. Also this is about routing around policy, which has the conveniently overlooked benefit that if the local anycast instance fails but the route still exists, the service is still available to those that use RH0 to find another. RH0 is a tool, it is not bad or evil, it is a tool that allows stating a specific waypoint. Any tool can be exploited for unintended uses, but that is not a reason to ban the tool. > > > Anycast == 'unicast to the nearest instance'. > > Indeed. I was one of the authors of BCP 126 and have some familiarity > with the concept. Unfortunately the text in 5.4 does not reflect that. > > > /rant > > I am getting really tired of the recent efforts by the telco world > > trying to > > kill off value to the end user, just because they get no direct > > benefit or > > perceive a direct threat to their dying model. > > rant/ > > I'm confused by your references to telco bias, and I'd appreciate > some clarification. That was a rant, related to multiple days of off list FUD from obstinate ISP types that want to remove any capability for IPv6 to allow the end users to exercise any control. Since this document is about killing off a technology that is required for a metro/geo business model, and it started life as *-evil-*, it automatically gets bucketed in with the ISP myopia about end users having any form of control. I have no problem limiting the number of RH0 segments, but killing it off is a knee-jerk reaction to a well known exploit. TCP-SYN can be exploited, but I don't see calls to deprecate TCP ... Section 7 This presentation resulted in widespread publicity for the risks associated with RH0. s/publicity/hysteria Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
