At Mon, 28 May 2007 17:03:47 -0400,
Joe Abley <[EMAIL PROTECTED]> wrote:
> I have made some edits. Note that I am hoping to reach consensus on
> the changes to -00 which will produce -01 so that once -01 is
> submitted, it is ready for working group last call.
The 01-candidate doesn't completely address my previous comments.
Some of the comments may be controversial, but I believe at least some
others are supported by a majority of the wg (and should be
addressed before a WGLC).
- section 3.1
IPv6 implementations are no longer required to implement RH0 in any
way.
I don't understand why we bother to say this. Isn't it enough to
state "IPv6 nodes MUST NOT originate IPv6 packets containing RH0."?
- section 3.2
This section doesn't address my previous comments: I believe we should
specify the behavior when a node receives RH0 with segment left being
0; we should also specify whether an ICMPv6 error should be returned.
I believe we should at least clarify these points before a WGLC.
I also pointed out the following sentence could be still ambiguous:
IPv6 nodes MUST NOT process RH0 in packets addressed to them.
I suggest modifying this sentence to:
IPv6 nodes MUST NOT process RH0 in packets whose destination address
in the IPv6 header is an address assigned to them.
- section 4
I'm not sure if a protocol specification document is the appropriate
space for operational considerations especially when the
considerations contain some normative text (like "strongly
discouraged). One possible compromise is to move the discussion to an
appendix. This may sound excessive formalism, however, so I don't
insist on the adoption of this comment.
- section 5
IMO, this section contains too many details that are not directly
related to the deprecation action, make the document unfocused, and
could even make it misleading (even though I respect authors' effort
of writing up the summary). I suggest we take more focused approach
as this version took for the abstract and introduction. I
specifically propose the following revised text for a replacement of
the entire section (+ subsections):
========================= from here =========================
The purpose of this document is to deprecate RH0. It has been
shown to have undesirable security implications as described in
[CanSecWest07]. Among such implications the most significant is an
amplified denial of service attack.
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].
This attack is particularly serious in that it affects the entire
path between the two exploited nodes, not only the nodes themselves
or their local networks. The same attack can be performed using
the IPv4 source route option, but the attack is much severer for
IPv6 because RH0 can contain a much more waypoints, which increase
the amplification factor. Ingress filtering [RFC2827] [RFC3704]
can mitigate the attack, but it is not widely deployed yet and is
not expected to be deployed soon.
The severity of the threat thus warrants a strong countermeasure of
deprecating the mechanism itself.
========================== to here ==========================
If we adopt this proposal I'd not have to care about other details of
this section, but here are a couple of specific comments to the text
itself in case my proposal is rejected:
- I think we should exclude the second paragraph of section 5.3 (about
the 'capacitive effect'). The effectiveness of this attack is not
so clear as the simple oscillation attack to me; the attacker would
have to control the timing of the packets (by either or both of the
transmission rate and the number of intermediate waypoints in RH0)
so that all the packets flow between the "capacitor" exit and the
target node at the same timing. As far as I know this attack is not
proved to be possible on real traffic unlike the simpler oscillation
and that's why the draft states it has been "postulated" rather than
"demonstrated". Describing the possibility of the attack is
interesting in a research paper, but IMO we should discuss things in
a normative protocol specification based on threats that are proved
to be possible.
- the following part of the third paragraph of section 5.3 is not
really technically correct:
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.
Even though the cansecwest paper may indicate so, the circuit
latency is actually irrelevant to the amplification factor (I
discussed this with the authors and they admitted that). The only
relevant point in this context is that it may be possible to attack
a longer path more effectively because the two consecutive waypoints
may effectively contain multiple (IPv4) links and the IPv6 hoplimit
is decreased only by one between them.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
