Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: Craig Dunk <[email-masked]>
Date: Mon, 17 Dec 2001 13:37:31 -0500

Tangent:

Does "readable when encrypted" extend to "modifiable when authenticated" or
are some policies required about what "recommended" uses are for the field?
This may be covered nicely by the phrase in a previous message that "...the
IPv6 flow label is *not* a routing label.".

Craig.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: December 17, 2001 1:06 PM
To: Michael Thomas; Margaret Wasserman
Cc: Brian E Carpenter; [email-masked]
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

Mike,

You forgot a third:

3) Readable when the packet is encrypted

Thus, QoS can be accomplished even if the
rest of the packet is encrypted.

            jak

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 17, 2001 8:21 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

> Margaret Wasserman writes:
>  > If I seem to be missing an important point or concept, please send
>  > some hints or pointers.
>
> Margaret,
>
> I don't think you're alone wondering what all the
> fuss is about with the flow label since it's
> fairly obvious that normal Intserv classifiers
> function equivalently. However, there's two fairly
> important things that the flow label brings to the
> party:
>
> 1) Speed
>
> Speed is primarily due to the fact that the flow's
> tag is in the IP header itself at a fixed
> location. This simplifies the processing --
> helpful for ASIC's -- as well allowing
> classification of problematic flows, such
> as IPsec and flows which contain destination
> options or other things which require that
> the header list be traversed.
>
> 2) Protocol independence
>
> RSVP normally uses a 5 tuple which implicitly
> expect a source and destination port. Other
> protocols either disagree (IPsec which requires
> classification based on SPI) or are undefined
> (SCTP...). Use of the flow label will allow us to
> deploy new protocols without having to come up
> with new RFC's to describe how to create its own
> flow classifier. Better, it will not require
> software/hardware upgrades in routers to be able
> to give QoS treatment to new IP protocols.
>
>      Mike
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2001 09:37:39 +0100

Yes, the flow label is explicitly excluded from AH. So it could be modified
en route and you can't authenticate its value. Assuming we decide to use
it as an end2end value, that could be viewed as a bug.

  Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Dec 2001 08:07:35 -0800 (PST)

> it as an end2end value, that could be viewed as a bug.

   That would be a pretty funny view. The only
   way to make it immutable would be to share a
   security association with each participating
   router along the way. I don't think we want
   to even vaguely contemplate going there.

	   Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2001 17:42:35 +0100

I agree; I meant that even at the receiving end you can't authenticate it,
let alone the intermediate hops.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org
--------------------------------------------------------------------
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]
--------------------------------------------------------------------