Joe Abley wrote: > ... > That's a valid editorial point, thanks. > > > and it is only one > > packet at a time that has to wait for reception before being > > reflected back. > > No, that's not the case. Packets constructed with an RH0 extension > header containing intermediate addresses A and B, N times (so, for > example, if N=5 then RH0 contains ten addresses, A B A B A B A B A B) > can be injected into the A-B cyclotron as rapidly as the path between > the origin and A allows, without ever waiting for a response.
And as soon as they are at A the packets have to wait for head of line blocking to get to B. > > So long as the injection rate is higher than 1/(N*T) where T is the > round-trip delay between A and B, the traffic impact between A and B > will exceed that between the origin and A, N-fold. > > > The total traffic volume over a given path may be higher, but this > > is not a > > multiplication of the number of streams. > > It's a multiplication of the amount of traffic being carried, though. > The ability to cause 88Mbit/s of traffic in a remote network with > only 1Mbit/s of effort is surely an amplification effect (and surely > a concern). So fix the spec so there is only one RH0 allowed. Killing it does not prevent exploitation of the network. If exploitation is such a threat then we need to kill off ICMP because it is a much more widely used attack vector than routing headers. > > >> 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. > > No, not at all. The victim address in this case is a destination > address, not a source address. Due to serialization delay the victim will never be the destination. It might be the upstream router queue from the destination, but the nice mathematical theory about instantaneous convergence falls flat when reality strikes in the form of bit serialization. > > My understanding of the CanSecWest authors' thinking with respect to > this particular technique is that the number of (A, B) waypoints in > the RH0 header would be varied such that for every one packet that > entered the A-B cyclotron, you could achieve N packets leaving > simultaneously, each having been round the A-B loop a different > number of times. Unless they vary the actual A & B with the destination behind a richly connected fabric, the packets will never converge at exactly the same time. Even if they did vary A & B, the packets can't exit simultaneously because they have to queue up to get over that interface. > > Maximising the output of such a capacitor would require tuning the > RH0 extension header construction according to the observed round- > trip latency between A and B which seems non-trivial, but at the same > time not impossible. Converging packet streams onto an interface queue is much simpler using an army of zombies in a ddos attack. Why would anyone waste time trying to game a dynamic state where the tuning would have to be precise, and would easily be disrupted by 3rd party traffic on the path? Unless someone can provide the working code, this does not belong in any document because it is just conjecture. > > Note that I have not explored the details of this with the CanSecWest > presenters, however; it's possible that they were thinking of > something different (and equally plausible that there's a fault with > my logic, above). You essentially described the same thing Geoff Huston did, so I suspect your reading is not flawed. Their premise on the other hand is because the reality of interface queuing and clocking invalidates the claimed result of a simultaneous arrival. > > >> 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, > > Right, but the round-trip path latency does (see above). > > >>> 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. > > Not with widespread RH0 support; that's the point this section > attempts to make. With RH0 support a single origin can send packets > which will arrive at different anycast nodes, regardless of the > natural (no-RH0) node that would normally receive the traffic. The world should tremble in fear ... a single node can send individual packets to more than one destination ?!?!?!?! This section is still worded wrong. Any single packet will always go to a single destination. Use of RH0 does not result in a single packet arriving at multiple anycast destinations. The entire title of 5.4 is wrong, anycast is not defeated, the packet still arrives at one-and-only-one of the anycast instances. Depending on where the RH0 target is, that MAY be a different instance that would occur without the routing header. Clearly the reason this text was put in was someone wants the entire world to be forced into their policy model where nodes are not allowed to route around a broken instance of an anycast service. Flash crowd containment still happens, it just may be that a different instance of the service feels the pain than what was expected. Load distribution is the goal for anycast, even in the flash-crowd-containment scenario. Clearly somebody doesn't like the idea that the end user should have the ability to select an instance if the local one is broken, so again I say this entire effort is not about fixing brokenness, it is about power and control over the lowly end user. > > >>> 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. > > I have not yet understood your point (or you have not understood > mine). I'm not convinced that we have a problem in 5.4, yet. The existing language effectively says that packets to an anycast dst which have an RH0 header will arrive at multiple instances. I know you are trying to say that 'the source node gets to select the anycast instance', but that is not what this says, and if you said it the way I did it would not generate the hysteria needed to get consensus. > > > 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. > > I am sympathetic to the problem; if I had a magic wand that would > allow press coverage of technical issues to be (a) accurate and (b) > fully understood by all who read it, I would wave it :-) > > However, this seems orthogonal to the technical issue. The issue at hand is that RH0 should be limited to 1 or 2 to avoid the bounce problem. Other than that this is all about control which is also a non-technical issue, so exactly why are we doing this again? > > > 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. > > There's a long history of "-is-evil-" being used in document names in > the IETF, and it's common argot amongst operators when describing > things that have unpleasant side-effects (see, for example, the > recent, huge NANOG thread on NAT, where NAT was declared as being > evil about every three messages). I am aware of that, and those almost always start as non-technical 'I want control' nonsense. As for the nanog thread on nat, the other 2 of 3 messages were defending nat as the savior of the universe and absolutely necessary in IPv6 networks. NANOG has stopped being a useful technical reference because it is all about religion. > > You know this, of course. I feel your frustration, and I appreciate > that one more reason not deploy IPv6 amongst operators of any share > is not something that is going to make for a happy fun day for you. > However, I don't think that blaming my earlier document name for non- > deployment of IPv6 in this case is reasonable. Lack of deployment of IPv6 has nothing to do with IETF documentation. It is all about the unwillingness of the 'guru cult' to risk their status by trying to learn something different. The desperation is becoming more apparent though as the reality of the end of IPv4 storms over the horizon. RH0 is not a threat if limited to 1 or 2. I can't come up with a reason for more than one, but I am willing to believe there are use cases. > > > 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 > > ... > > The well-known exploit in this case was judged by this working group > to have minimal demonstrated application in the real world, and non- > trivial risks associated with its availability, hence the decision to > deprecate. That is because it's applicability is to an environment that can't get formed until there is sufficient deployment of IPv6 to force the point that alternative aggregation models to PA and swamp PI are required. Metro/geo in addition to PA/PI will allow scaling capabilities to the masses, but making those work requires at least a one hop RH0. > > If you think that judgement of consensus by the wg chairs was wrong, > then that seems like something best taken up with them; this document > is a reaction to that consensus, not a proponent of it. Hopefully I will get some time in the next couple of weeks to draft an alternative viewpoint related to fixing RH0. Claiming that consensus was reached in the middle of press and mail list hysteria is a stretch. At the same time there is precedent in the SL fiasco. > > > Section 7 > > This presentation resulted in widespread publicity for the risks > > associated > > with RH0. > > > > s/publicity/hysteria > > It seems like it would be unusual to see one without the other. > > > Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
