Hi Joe,
> The stream is not amplified, it is still a single stream,
That's a valid editorial point, thanks.
The amount of traffic is amplified. I dont see a reason to say that
the amount of traffic is not amplified. The amount of processing is
amplified too.
Thanks,
Vishwas
On 6/7/07, Joe Abley <[EMAIL PROTECTED]> wrote:
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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
