Jun-ichiro itojun Hagino wrote:
>
> >> 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?
As I said, you don't care: they will pay the appropriate tariff for the
PHB they request. It isn't the ISP's problem.
For the other points, I agree with Itjun and perhaps disagree with Alex -
there are some scary issues in playing with header length etc.
Brian
>
> >> - 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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Board Chairman, Internet Society http://www.isoc.org
"We shall need a number of efficient librarian types
to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
