itojun,
As Brian already rightfully said, perhaps not with the same words, the
draft promotes the flow label format in the main text, which is the IANA
based value format. As Brian, I believe more in the IANA format. The
flow label formats in the Appendix are presented as possible choices,
each with its advantages and disadvantages, and as a record of such
choices. The draft states that in the Appendix.
The reason I am still arguing the Appendix formats, is for the sake of
fairness and accuracy.
Jun-ichiro itojun Hagino wrote:
> ....
>
> >> - 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.
>
> I guess you are too optimistic. if you are using align-picky
> architecture CPU for your router, I can panic your router by putting
> some value that is not align-friendly into flow label field as the
> extension header length.
>
Memory alignment became an access speed issue with certain 64bit
processor/memory architectures, because of the access in 32 or 64bit
"blocks", aligned at 32, or 64bit boundaries, thus possibly requiring
for a byte access, depending the position of the byte in the "block", a
shift of 8, 16, 24, or more bits. But this is far from anything you
describe.
I am afraid "memory alignment violation" is more a result of one's
imagination than reality.
> >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.
>
> I don't understand what you are trying to mean. regardless from
> read access or write access, your kernel can be tricked into:
> - accessing bits on a wrong boundary
> - accessing bits that are not a real port number
> I can trick the intermediate routers to believe that I'm using
> TCP port 80, while I'm actually using TCP port 22.
>
> >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.
>
> it is very different from IPv4 case. in IPv4 case, IHL field is the
> one and only field trustable, and there was no ambiguity. for IPv6
> extension header length, the actual value is detected only by chasing
> header chain. your addition (of extension header length into flow
> label field) is a non-trustworthy copy of the real value. if your
> router believes that the value in flow label field, your router will
> get tricked.
>
Ultimately, as Brian pointed out, the Network Provider will charge the
customer. The customer, if he/she is the culprit will pay, otherwise,
will pay, and chase the culprit.
For the sake of accuracy, for a flow label format that contains the
length and the host-to-host protocol id, the flow label value should be
set by the IPv6 stack, that is, the KERNEL. The user should only trigger
the use of the label, but the two values - length, protocol id - would
be set by the KERNEL, on "IPv6 output" code path. Both values are known
on packet transmission. The length can be calculated and cached or
stored in a field in the Protocol Control Block, or whatever structure
is representing the communication.
> >> - 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.
>
> I don't believe so.
>
> itojun
you are making it sound like there is NO RISK with the pseudo-random
number, and that is NOT TRUE.
Once a pseudo-random flow label has been generated and cached, the risk
of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random
flow label value.
Alex
S/MIME Cryptographic Signature
