On 7-Jun-2007, at 12:40, Tony Hain wrote:
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,
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.
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).
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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
--------------------------------------------------------------------
