Itojun,
You seem to ignore that both RFC 1883, and RFC 2460 themselves state
that the flow label definition has limitations. Since 1994-95, and 97-98
when those documents were written/reviewed, a lot more progress has been
made relative to QOS and labeling traffic, in terms of architecture,
specifications, and applicability.
You state that the current definition is perfect, or it suits you
perfect. But you do
not want to accept a win-win situation, which is a mechanism that
- does not eliminate what suits you, but also
- would suit others.
I am going to try to keep religion out, and respond to the technical
content of what you're saying whatever that may be - please see bellow.
Alex
>Jun-ichiro itojun Hagino wrote:
>
> >The traffic class field is not enough. If you have to re-classify traffic at
> >an administrative boundary, then by definition at that point the traffic class
> >field is inadequate; you need more information. The advantage that IPv6 has
> >is that even when the header is partly hidden by IPSEC, the flow label is
> >available to carry additional semantics. The actual proposal is to use the
> >PHB identifier which has end to end semantics.
>
> I heard the presentation differently. in IETF51 presentation Alex
> Conta made the following proposals, at least:
> - putting PHB value
> not trustworthy.
The PHB is as trustworthy as anything else, including the pseudo-random
value. If a user can set values as pleases, it can do that with the
pseudo-random number as well.
> - putting total extension header length
> if the originator lies about the value, intermediate routers
> can go panic.
I disagree.
"less than the size of the packet" is a simple, cheap, straight forward
validation test of the headers length, that would ensure that nothing
wrong can happen, regardless of memory being partioned and protected.
Even without the validation, the reduced number of bits available for
the length is forcing a reasonable limit on the length. The TCP/UDP
ports are accessed for "read", and the values are not used as pointers
or offsets. Assuming an implementation that enforces memory
partitioning, the "kernel" has most likely "read" access anywhere in
memory, so "memory access violation" is unlikely.
Also please note that the use of a total header length would not be
conceptually, and practically
different than IPv4. The IHL field in the IPv4 header includes the
length of the main header fields, and the IPv4 options. Some of the IPv4
options are of a variable length. A variable size IPv4 option
carries a field indicating the length. We knew how to implement this
back many years ago, right?, so we should be able to implement this
carefully for IPv6, if need be.
> - putting port/addr/whatever encoded
> if the originator lies about the value, theft-of-service
> happens.
As said above, the security risk is not higher than with the
pseudo-random number.
> none of these values are trustworthy, since originator can lie about
> those. because these values are not trustworthy, intermediate routers
> need to get those values by normal ways (by chasing extension header
> chain, or whatevr), and therefore, flow label value is just wasted.
>
> I particularly don't like the idea of putting total extension header
> length. as soon as it gets deployed bad guys can mount various attacks.
>
> So, back to my original posting, I vote for end-to-end pseudorandom
> 20bit value. intermediate router MAY use it to hash the traffic,
> that's all.
>
> itojun
S/MIME Cryptographic Signature
