The facts you mentioned (checksum and AH calculation) are wellknown, but a clear reminder is certainly useful for those who forgot, or ignored that.
One of the comments pro "immutability" was that you cannot trust the flow label if it is not "immutable". But the no way to enforce or validate it -- possibly grotesque inconsistency -- is not why I am NOT for "immutability". The list of the flow setup and flow processing mechanisms is an open list: we do not know today all possible ways in which the flow label would be setup or used, in 10 or 20 years from now. Current or future flow setup and flow processing mechanisms, do now, or will, in the future, KNOW BEST the micro-details of the flow label usage. Therefore responsibility of the immutability/mutability of the flow label value should stay ALONE with those mechanisms. By leaving mutability alone, possible issues with checksum, and AH calculation can be really forgotten, or ignored. Alex Subrata Goswami wrote: > > 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] > --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
