Subject: Re: Flow Label

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jan 2002 15:09:10 +0100

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 ? 

You can't, any more than you can be sure the DSCP hasn't changed, or that
somebody isn't playing games with port numbers to fool your classifier.

The ISP's defence against this is that more QoS will result in a higher bill.
So the ISP actually doesn't care; they get paid accordingly.

   Brian
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Jan 2002 13:45:04 +0700

Date:        Tue, 8 Jan 2002 21:28:11 -0800
    From:        "Dr. Subrata Goswami" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Here we go again, I guess first we need to make sure
  | what immutability really is. The proper semantic of
  | something immutable is that it can not be changed -
  | as when you ship a CD that is only readable.

Yes, though we perhaps aren't using it in quite that sense, more
in the "must not be changed" rather than "can not be changed".

  | With an IPv6
  | packet that is not possible unless every router vendor
  | and IP stack vendor is some how forced to do that.

But that's certainly not true.   We don't have to force them, we just
need to tell them what is right.   That's all the IETF ever really does.

  | Even the IP address fields are mutable as any intervening router
  | can change (and they do in case of NAT).

Yes, exactly.   Yes and (NAT set aside for a minute) the IP address fields
have just the properties that we are really aiming for here.   That is,
they aren't changed by random routers along the path - packets get delivered
with the same addresses in them that they had when they left the source
(or did, pre NAT).  And that was achieved without AH existing yet to
validate things - the routers simply didn't alter the fields.

That's what is desirable here.

But then, along came the need for NAT (as evil as it is, there must be
a pretty strong case for it, given its widespread use).   Implementing that
meant that the address field, which previously had never been altered,
now needed to be changed by routers.   Had there been any enforcement of
the immutability of the addresses, then there would have been no way to
add NAT to the net (which might have been good, or bad, but for sure the
net now would be nothing like it is if not for it).

  | So the only way
  | to enforce immutability is to add something like the AH so
  | that anyone who is concerned with the Flow Label can be
  | sure that no router in the middle has tempered it.

If there was any reason to enforce it, that would be correct.  But there
isn't - so we don't need this.

And if we did, then there'd be no possibility later to come up with some
new use which requires the field to be mutable (and argue about it a lot
in the IETF and perhaps eventually agree to it).   At this stage in the
evolution of the flow label, completely cutting off that possibility is
unreasonable.

In practice, if actual immutability is required by applications that use the
flow label, then what will "enforce" the immutability is the screams of the
users at the router vendors/operators if they start playing about with the
data.   Just as would happen if (aside from the explicitly configured NAT,
and even that generates plenty of screaming) routers started randomly
changing IP addresses.

If there's never an application actually deployed that cares, then why would
anyone else?  In that case, if someone decides to alter the field, no-one
would notice - and there's no reason to go and add a mechanism just to detect
something that no-one cares about anyway.

kre

---

From: Alex Conta <[email-masked]>
Date: Mon, 07 Jan 2002 15:13:51 -0500

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 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-masked]
> [mailto:[email-masked]]On Behalf Of Brian E Carpenter
> Sent: Monday, January 07, 2002 2:15 AM
> To: Subrata Goswami
> Cc: [email-masked]
> 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-masked]
> > [mailto:[email-masked]]On Behalf Of Charles E. Perkins
> > Sent: Friday, January 04, 2002 9:33 AM
> > To: Brian E Carpenter
> > Cc: Margaret Wasserman; [email-masked]
> > 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-masked] 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
> > > > >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jan 2002 15:16:30 +0100

kre is correct IMHO, and we won't get any further by repeating
this loop again.

However there is one qualification on kre's final comment:
> ...if someone decides to alter the field, no-one

The field could theoretically be abused as a signalling channel by malicious
people - detecting this might be of value in some circumstances. 

  Brian

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 8 Jan 2002 23:12:05 -0800

Well I would not recommend settling something with screams.
Making the Flow Label immutable would infact need more than
screams.

I can not see how by just saying something is immutable going
to help. It would infact be the ground for more confusion,
uncertainty, doubt and vendor specific interpretations. I would
also recommend adopting the semantics of immutability from the
AH RFC 2402  - I guess that is where the word immutable first
appears.

Also, as you know AH is completely broken by NAT.  Why has
NAT become popular ? I can only guess: a quick and dirty fix
for IPv4 address scarcity; some firewall benefits.

The

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Robert Elz
Sent: Tuesday, January 08, 2002 10:45 PM
To: Dr. Subrata Goswami
Cc: [email-masked]
Subject: Re: Flow Label

  | With an IPv6

  | So the only way

If there's never an application actually deployed that cares, then why would
anyone else?  In that case, if someone decides to alter the field, no-one
would notice - and there's no reason to go and add a mechanism just to
detect
something that no-one cares about anyway.

kre

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 8 Jan 2002 21:28:11 -0800

Here we go again, I guess first we need to make sure
what immutability really is. The proper semantic of
something immutable is that it can not be changed -
as when you ship a CD that is only readable. With an IPv6
packet that is not possible unless every router vendor
and IP stack vendor is some how forced to do that. Even
the IP address fields are mutable as any intervening router
can change (and they do in case of NAT). So the only way
to enforce immutability is to add something like the AH so
that anyone who is concerned with the Flow Label can be
sure that no router in the middle has tempered it.

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Robert Elz
Sent: Tuesday, January 08, 2002 7:08 PM
To: Alex Conta
Cc: Subrata Goswami; Brian E Carpenter; [email-masked]
Subject: Re: Flow Label

    Date:        Mon, 07 Jan 2002 15:13:51 -0500
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

  | One of the comments pro "immutability" was that you cannot trust the
  | flow label if it is not "immutable".

I didn't ever see that argument.   What I saw was that you can't rely upon
it if it isn't - but not from the point of view of the recipient, from the
point of view of the sender.   That is, if the value might be changed to
any random thing, what's the point of setting it all, ever?  It would just
be meaningless bits (imagine a router forwarding a packet through an
encrypting tunnel, and seeing some mutable bits - ones it is allowed to
alter - and filling them with a random value in order to make cryptanalysis
more difficult).

  | 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.

I think in this case, you really favour making the field immutable, but
unverified.   If it were truly mutable, it would never be able to be used
for any of those uses, as no-one could ever rely upon any value they set
remaining intact to the point where it was supposed to be used (the "router"
in my previous paragraph might be a link level bridge type object - even
imagine a NIC that sees this mutable field and uses it to send to the
destination a count of the number of times it deferred because of a busy
link before sending the packet...)

If some future spec wants to make the field mutable, then as long as we
have not done anything silly (like modify the current AH rules) to prevent
it, then that spec will be able to do that - and with a good chance of
being able to rely upon the value only being changed as the future new spec
actually says should happen.

  | By leaving mutability alone, possible issues with checksum, and AH
  | calculation can be really forgotten, or ignored.

This amounts to "make it immutable, don't change AH, and explain in the
doc that AH explicitly doesn't include the flow label, to leave open the
possibility that some later spec might specify conditions under which the
field can be changed".   Until this later spec appears though, I don't think
we need to anticipate its requirements, and waste time here debating
whether or not those unknown future requirements are a good thing or a
bad thing.

All we need to do now is avoid doing something truly silly like revising
AH to have it include the flow label.

The only plausible "mutable" argument I can see remaining for now is to have
a case where the source host says "I don't care what is in this field, I
am not setting it to anything".   I haven't yet even seen an argument as
to why that value has to be immutable (by definition it has no meaning to
anyone).   So, I'm still in favour of allowing that.   But not so much as to
object to a doc that doesn't include it - after all, no-one will ever care
if
that value is changed, so if anyone wants to do so, they can, regardless of
what this new spec on the flow label claims.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Jan 2002 10:08:28 +0700

object to a doc that doesn't include it - after all, no-one will ever care if

kre