[Note that I am not replying out of a desire to engage in advocacy;
you should read this more as editorial summaries of discussions that
have already happened here when the questions you raised were asked
before.]
On 6-Jul-2007, at 10:46, Christopher Morrow wrote:
I recognize that a host could still be used as a bounce-point, if the
router ignores the header though ... no real amp effect arises, unless
you can bounce between hosts across a router link in a meaningful
manner.
No, that's not the case. If you bounce traffic between two RH0-
supporting hosts, then all the routers between them need to do is
process the destination address in order for the remote congestion
effect to be possible.
This still is fixable with a simple filter (just like smurf or
other sorts of amplification attacks).
Right, to stop the traffic routers would need to examine the whole
chain of extension headers in each packet in order to see whether
there's a type-0 routing header in there, and apply suitable policy
in the event that one is found.
I think we heard from people that this is a lot of work to be done
(e.g. in an ASIC), and is contrary to the high-level design goal of
letting routers do their thing with minimal amounts of per-packet work.
So, to summarise: your proposal is that RH0 should not be deprecated,
but that it should be made optional? I'm not convinced that I
understand how that's going to prevent the "amplification over remote
paths" problem.
I'm not convinced that the problem is dire enough to warrant
completely removing the capability that we don't even have any idea
about usage of :(
I think the inference is that we are early enough in the IPv6
deployment cycle that if someone really is relying on RH0 support in
protocol stacks, there's sufficient time for a new (RH, something) to
be defined and implemented to provide whatever functionality is
required without posing a wider hazard.
I think the only use cases we have heard of here are (a) the
experimentation documented by Biondi/Ebalard in their CanSecWest
presentation, and (b) the ability to perform traceroutes from a
remote source. We did not hear from anybody with the perspective that
RH0 support was a critical aspect of IPv6 for them. I do not mean to
imply that the lack of such an opinion means that there's nobody who
holds that opinion, of course.
The pertinent questions are, I suppose, (a) whether there's a use-
case which would be profoundly crippled by the deprecation of RH0 in
the protocol specification, and (b) whether such a crippling would
pose a greater danger to the Internet at large than the risks of RH0
which have been documented.
The current best-known answers (wrt "remote traceroute") are (a) yes,
but it's functionality that the IPv4 Internet happily does without,
and hence (b) no.
Note too that several widely-deployed IPv6 stacks have already taken
the approach of effectively deprecating RH0. So there's a practical
consideration that if we decide to do something different, we are
diverging from deployed practice.
which? fbsd? obsd?
The WIDE-derived stacks have done this, which in practical terms
means *BSD plus Apple. Itojun may be able to clarify if you want a
more exact list of implementations and the changes they have decided
to make.
they took the large hammer approach for some
specious set of reasons? What about XP/MacOSX/Vista/Solaris/HP-UX ?
According to the CanSecWest slides, "Windows" (not sure which
versions) "implements a conservative default behaviour (drops en-
route packets)". I don't know what Solaris or HP/UX do. I see
committed patches for Linux which deprecate RH0, but I'm not
sufficiently in-tune with the Linux development process to know
whether any of those have been formally adopted in a mainstream kernel.
Whether or not their reasons were specious seems entirely subjective.
However, in the interests of avoiding that rat-hole, I think I will
constrain myself to technical considerations :-)
I still go back to the 'do we want to use the really big hammer here?'
question. I don't see this as being any worse than other amplification
vectors and we haven't talked seriously about deprecating any of
those, so why this one?
Which other amplification vectors did you have in mind?
Joe
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
