>> 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.
but if you look at the number as PHB, you are trusting that the
originating system have put a meaningful, and correct, PHB.
how can you be sure that the originating system is not cheating?
>> - 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.
>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.
>> - 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
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
