On 8-Jun-2007, at 11:21, Tony Hain wrote:
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.
Yes. I do not currently see how this prevents the amplification
effect, however, except in corner cases where the round-trip latency
between A and B is very low and the B-facing interface at A is of
very low bandwidth.
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.
Seems to me that every denial-of-service attack against a single
point victim experiences serialisation delay somewhere along the
line, but that doesn't seem to mean that denial-of-service attacks
don't deny service.
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.
There was code in the CanSecWest slides.
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.
I agree, and it was not my intention to imply that they could. I will
see whether I can make that more clear in the text (thanks).
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.
The point of the section is that a single client can arrange for
packets with a single destination to be routed to different anycast
nodes at will, not that the same packet could be made to arrive at
multiple anycast nodes.
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.
I will change the text. I don't agree that the text as-written was
designed to generate hysteria (and as I wrote it, I should know :-)
but I agree that the text as it stands is woolly and could do with
being made more clear.
Joe
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
