At Thu, 24 May 2007 17:07:49 -0400,
Joe Abley <[EMAIL PROTECTED]> wrote:
> I intend to circulate candidate text changes to this list before -01
> is submitted, in the interests of making -01 as close to finished as
> possible.
>
> 1. More description on what the potential problems with RH0 are.
> Whilst it appears there there is general agreement that a detailed
> treatment would best belong in a separate document, some stand-alone
> summaries in deprecate-rh0 would be useful.
>
> Illjitsch sent some text, and I had previously worked on some
> summaries of the issues presented at CanSecWest. I propose to add
> some suitable summary text to the Security Considerations section.
I agree that we should briefly describe 'why this' (if this item
intends that). Even if a normative spec is usually not so verbose
about rationale of specific behavior, I believe we must provide some
minimal level information on this for this document, especially
because this document attempts to deprecate existing specification;
implementors who are not involved in the whole discussion and just see
the resulting document won't be very much willing to modify their
implementations just by being told "do it".
Regarding the "rationale", I think the current draft actually
overstates the "problem". Although the source routing may cause
various possible concerns, most of them would not result in such a
strong action as complete deprecation as far as I understand them;
we're primarily taking this action due to the tradeoff consideration
between the threat level of the amplification attack and possible
benefit of the routing header.
So, for example, the abstract of the 00 text seems to overstate the
issue:
The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to perform remote network discovery, to bypass
firewalls and to achieve packet amplification for the purposes of
generating denial-of-service traffic. [...]
I'd rephrase this so that we can concentrate on the exact problem:
The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to achieve packet amplification for the purposes
of generating denial-of-service traffic. This document updates the
IPv6 specification to deprecate the use of IPv6 Type 0 Routing
Headers, in the light of the severity of this security concern.
I'd also update Sections 1 and 5 this way. I'd also like to clarify
that this is particularly severe for RH0 in that it can contain much
more waypoints than the IPv4 source route option.
I believe it's beneficial to concentrate on the real point because it
would answer counter arguments like "why disable-by-default is not
deemed sufficient" or "why we deprecate it while keeping IPv4 source
route option", etc.
> 2. More precise description of what deprecate means in the context of
> this document.
Yes, this would be good. I assume this also intends to clarify more
details about the processing behavior described in Section 3.2, e.g.
- what the receiving node should do if it receives a packet containing
RH0 with the segment left field being 0
- whether or not ICMPv6 error is returned when a node receives a
packet containing RH0
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
