The main point is, if I am a provider and I get a packet, how can I be sure that some malicious entity in the middle has not modified the flow label so that it can avail of better QoS ? Second your assumption of not being able to handle flow label authentication may be too conservative in light of Moore's law and developments in optics. Third, not everybody works at the speed of 10GigE or OC-192 - there are networks that works at lower speed where it is entirely possible to do header processing in silicon even now. Fourth, you would still need to change a Proposed Standard - so while we are at it why not make it more complete.
Also unless there is a mechanism to verify the immutation of the flow label, just saying it is immutable is akin to making a law and having no way to enforce it. So my vote ( I am not sure how much it is worth) would be not to make it immutable unless we provide a way to verify the immutation. Subrata -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Brian E Carpenter Sent: Monday, January 07, 2002 2:15 AM To: Subrata Goswami Cc: [EMAIL PROTECTED] Subject: Re: Flow Label We've already discussed the weak trust model aspect. Basically nobody will be doing cryptographic authentication of the flow label at line speed, and if it isn't done at line speed what's the point? Brian Subrata Goswami wrote: > > The wording for immutability aside, to really enforce immutability > of the Flow Label , there must be a mechanism to verify that the > Flow Label has not been changed. As can be seen from the ICV computation > for IPv6 (RFC2402) even AH considers Flow label to be mutable. Hence there > needs to be a new IPv6 header option for Flow Label immutability. > > 3.3.3.1.2 ICV Computation for IPv6 > > 3.3.3.1.2.1 Base Header Fields > > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) > Source Address > Destination Address (without Routing Extension Header) > > Mutable but predictable > Destination Address (with Routing Extension Header) > > Mutable (zeroed prior to ICV calculation) > Class > Flow Label > Hop Limit > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles E. Perkins > Sent: Friday, January 04, 2002 9:33 AM > To: Brian E Carpenter > Cc: Margaret Wasserman; [EMAIL PROTECTED] > Subject: Re: Flow Label > > Hello Brian, > > Brian E Carpenter wrote: > > > > And, truth in advertising, we have heard two dissenting > > views: > > > > a) that the field should be defined as MUST BE ZERO, i.e. > > the MAY clause below gets deleted > > I would say that MAY is a lot better. It suggests the truth, > which is that people are going to try to figure out ways to > use the flow label. It also motivates immutability. Otherwise, > it is possible that some router vendors could simply zero out > the field -- if it MUST BE ZERO, then zeroing it preserves > immutability... We wouldn't want that. > > > b) that the 3rd MUST should be SHOULD, i.e. immutability should > > be default instead of mandatory. > > Any future technique for using the flow label would, if it violates > immutability, be viewed as obsoleting this part of the specification > anyway. So I would hope for a MUST here. Language suggesting that > it is merely the default would allow for a tunable know in the user > interface labeled thusly: > "Flow Label treatment (default: do not change): " > to be filled in by the system administrator. Possible other values > selectable by the operator could be "randomize", "ones-complement", > "store current time", ... (?). I don't know why anyone would do > this, but I think we ought to be pretty clear about prohibiting it > at least for now. > > Regards, > Charlie P. > > > > > Brian > > > > Margaret Wasserman wrote: > > > > > > Hi George, > > > > > > Yes, we are "humming" in agreement to the proposal that we > > > replace section 6 of RFC 2460 with the following text: > > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > > source to label sets of packets. Nodes that do not support > > > > the Flow Label field MUST set the field to zero when originating a > > > > packet, and MUST ignore the field when receiving a packet. All > routers > > > > MUST pass the field on unchanged when forwarding a packet. > > > > > > > > This specification does not further define the meaning of the > > > > Flow Label. > > > > > > > > > > And that we delete Appendix A from RFC 2460. > > > > > > Actually, we probably won't update RFC 2460. We'll probably > > > just publish a separate RFC that updates 2460. > > > > > > Margaret > > > > > > At 02:01 PM 1/3/02 , [EMAIL PROTECTED] wrote: > > > >Just a quick question from an interested lurker: Are these hums of > > > >acquiescence in response, specifically, to the idea that an originating > > > >node may set the flow label to any value, and that nodes forwarding > > > >packets will leave that value alone? -- George Mitchell > > > > -------------------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
