Subject: RE: Flow label and its uses

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 16 Jan 2006 20:49:04 -0800

Hi Bora,

From my reading of documents the Flow Label is not very often used.

You can check the implementation report (fairly dated)
http://www.ietf.org/IESG/Implementations/ipv6-implementations.txt

And a more recent draft
http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty-bcc-flowla
bel-00.txt

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bora Akyol
Sent: Tuesday, January 17, 2006 6:12 AM
To: [email-masked]
Subject: Flow label and its uses

I am looking at pointers on how commonspread the usage of the "Flow
Label" field is in IPv6 (specifically end-node operating systems).

Any help would be appreciated,

Regards,

Bora

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 17 Jan 2006 09:46:44 -0800

Thanks Brian,

If this field is indeed not commonly used (presumably due to lack
of an API to take an advantage of it in end point OSs),
is it worth it to define it as "Reserved."

I don't want to raise a controversial issue here, but
this 'wild card' field presents some challenges in implementation
of v6 support without well understood applications.

Regards,

Bora

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, January 17, 2006 7:44 AM
> To: David Malone
> Cc: Bora Akyol; [email-masked]
> Subject: Re: Flow label and its uses
> 
> I've been a little disappointed not to see multiple drafts 
> proposing use cases within the rules set by RFC 3697. That 
> document was intended to set the baseline for flow label 
> based classifiers, but use cases are needed too.
> 
>     Brian
> 
> David Malone wrote:
> > On Mon, Jan 16, 2006 at 04:41:53PM -0800, Bora Akyol wrote:
> > 
> > Orla McGann did some measurements of this in her thesis:
> > 
> > 	http://www.redbrick.dcu.ie/~orly/thesis.pdf
> > 
> > Section 5.2.4 (page 101 of the PDF, numbered 91) has some live 
> > measurements of how many hosts were setting the flow label and some 
> > fingerprinting to determine what OS they were running.
> > 
> > 	David.
> > 
> 
> 
>

---

From: "Bora Akyol" <[email-masked]>
Date: Wed, 18 Jan 2006 10:47:08 -0800

> From: Pekka Savola [mailto:[email-masked]] 
<snip>
> > There has been significant time since RFC3697 and the lack of 
> > applications may indicate that this field (with the exception of 
> > NIMROD) may not have a use at all.
> 
> I've been watching this discussion with mild puzzlement.
> 
> There is (basically) nothing that the routers need to do with 
> the flow label.  Whatever they might end up doing with it 
> would likely mostly fall under the control plane, so it 
> doesn't need to be put in the hardware.
> 

Hi Pekka,

Did you get a chance to look over the proposal that is floating around
to use the flow label as a locally significant switching label?

Also, if the flow label can be used as an indication of 
classification at the source, then it can be used to 
decide preferential treatment in the network (hence the
20 bit DSCP extension proposal I guess -- which I have not read).

Regards,

Bora

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 20 Jan 2006 10:35:19 -0800

You are missing nothing.

Frankly, I don't believe in using this field as a locally significant
switching shortcut (like a label in MPLS). We have MPLS, we have VPLS,
we have their ethernet variants using information from the Ethernet
headers. I think we have enough tools to get the job done and we don't
need another tool.

This is why I think we should label this field as Reserved so that if we
run out of bits in the header for other apps, we can use these 20 bits.

Regards

Bora

> From: Durand, Alain [mailto:[email-masked]] 
> Sent: Friday, January 20, 2006 4:54 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: Bora Akyol; [email-masked]; [email-masked]
> There is something I never understood about the flow label... 
> In the case someone wants to used it when deep packet 
> inspection is not possible because of IPsec encryption, how 
> can one trust it as this field is NOT protected by IPsec?
> 
> What am I missing?
> 
>    - Alain.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Sat, 21 Jan 2006 12:51:48 +0100

So in an ideal world where everything behind the IPSec header is
encrypted (if that ever would be the case) .... then how to do
load-balancing as Brian suggest? Maybe the flow-label needs
to be *just* an identifier without further meaning? In that
case it does make sense that its unchanged between end-2-end.

I don't see why it has to be an extension to DSCP? DSCP provides
a mechanism to give an indication how the traffic would like to be treated
while flow label could give an indication of flow without knowing the upper
layer details. These are different operations i think.

G/

At 00:54 21/01/2006 -0800, Vishwas Manral wrote:
>Brian,
>
>That is exactly what I am trying to say too. For cases where we need to
>do deep packet inspection, if we could guarantee the flow label is not
>mutable etc it could be used. Examples of which could be IPsec, though
>it is not currently done that way.
>
>Regarding Alain Durand's question, I agree the field is just as mutable
>as the DSCP field or any other field in the outer header. Currently in
>IPsec to identify an outgoing SA we could use the protocol as well as
>port numbers (an SA for an application) and in a few cases we may not
>have all the inner header information. Having a flow Label helps in this
>case.
>
>We could have protected it using AH. However for backward compatibility
>reasons this is not done (as has been pointed out earlier by Fred).
>
>Using flow label could make the work of on-path devices which do deeper
>packet inspection in some cases easier.
>
>Thanks,
>Vishwas
>Sent: Friday, January 20, 2006 6:00 PM
>To: Vishwas Manral
>Cc: Pekka Savola; Bora Akyol; Fred Baker; [email-masked]
>Vishwas Manral wrote:
> >...  I am sure things like load balancing which require
> > deeper packet inspection can also be done.
>
>The whole point is that you will not need deep packet inspection
>if the flow label is set by the source.
>
>     Brian

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 22 Jan 2006 20:46:53 -0800

Hi Gunter,

Let me answer you, if I understand the questions you raise correctly.

Currently Load Balancing could be done based on the 5-tuple fields in
the packet. However in case the fields are not available we could fall
to some default criteria. With the flow-label present, we could instead
use the Source-IP, Destination-IP and the flow label. These would be
present in all IP packets.

I agree flow-label should be used as an identifier for a flow (as the
name suggests).

Thanks,
Vishwas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gunter Van de Velde (gvandeve)
Sent: Saturday, January 21, 2006 5:22 PM
To: [email-masked]
Subject: RE: Flow label and its uses

I don't see why it has to be an extension to DSCP? DSCP provides
a mechanism to give an indication how the traffic would like to be
treated
while flow label could give an indication of flow without knowing the
upper
layer details. These are different operations i think.

G/

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 26 Jan 2006 22:30:59 -0800

Hi Spencer,

I agree relying on the Flow-label when it traverses the unprotected
network may not be the best option. 

However in the tunnel mode case, I do not think that issue will arise;
besides at the tunnel tail egress we will not really check the
flow-label to identify an SA, but an SPI. DSCP fields are used the same
way already (we use it to identify an outgoing tunnel and don't use it
for identifying an incoming one).

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Monday, January 23, 2006 6:54 PM
To: [email-masked]
Subject: Re: Flow label and its uses

Hi, Vishwas,

The point I was trying to make was that since flow labels are
unprotected, 
you can use them unless you must trust them.

Having a device that alters flow labels for some random reason in the
middle 
of the network basically says we couldn't use flow labels to correlate 
packet captures taken at two points in the network. If we could trust
them 
(AH-protected), we could use them, but a per-packet AH operation to make

sure we can trust them isn't reasonable, in our situation.

Sorry if this wasn't clear.

Spencer

From: "Vishwas Manral" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Sunday, January 22, 2006 11:04 PM
Subject: RE: Flow label and its uses

Hi Spencer,

I may be missing the point; however I would like to understand what you
mean.

In IPsec for the SG-to-SG assume a case where we get a plain packet. By
processing fields in the packet (could be DSCP field, Source Destination
address, protocol field, upper header message type etc) we decide the
out going SA identified by an SPI. The packet reaches the tunnel tail
end and using the SPI we identify the incoming tunnel and authenticate/
decrypt the packet.

What I have been saying is that, just as we use fields in the plain
packet to identify an outgoing SA, we could (instead of using a 5-tuple)
use a flow label, which is available in all packets. The 5-tuple may not
be available in all IP packets.

It would be nice to understand how this is equivalent to setting the
"Security Bit"?

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Saturday, January 21, 2006 7:53 PM
To: [email-masked]
Subject: Re: Flow label and its uses

I'm out of the "deep packet inspection" business for now, but I did
spend
about 18 months building products in this space...

Although in a perfect world it would be lovely to know that flow labels
didn't change end-to-end, if that lovely thought requires a per-packet
AH
operation on middleboxes, it's probably beyond what people can build and

sell at affordable prices now, and (since end-to-end AH would be using
CPU
at each endpoint, while a middlebox verifying AH has to use its own CPU
for
all the packets it processes), Moore's Law doesn't seem all that helpful
in
planning for the future, either.

Maybe the RFC 3514 Security Bit from IPv4 should have an IPv6
counterpart
that says, "I promise that this packet is AH protected and hasn't been
dorked with, so you can believe the flow label"? That would help a
lot...

:-)

Spencer

From: "Vishwas Manral" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "Pekka Savola" <[email-masked]>; "Bora Akyol"
<[email-masked]>;
"Fred Baker" <[email-masked]>; <[email-masked]>
Sent: Saturday, January 21, 2006 2:54 AM
Subject: RE: Flow label and its uses

Brian,

Thanks,
Vishwas
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Friday, January 20, 2006 6:00 PM
To: Vishwas Manral
Cc: Pekka Savola; Bora Akyol; Fred Baker; [email-masked]
Subject: Re: Flow label and its uses

    Brian

---

From: "Bora Akyol" <[email-masked]>
Date: Mon, 30 Jan 2006 11:20:59 -0800

> However in the tunnel mode case, I do not think that issue 
> will arise; besides at the tunnel tail egress we will not 
> really check the flow-label to identify an SA, but an SPI. 
> DSCP fields are used the same way already (we use it to 
> identify an outgoing tunnel and don't use it for identifying 
> an incoming one).
> 

Hi

Does this mean that you are using the flow label in lieu of
the regular IPSEC SP match?

Thanks

Bora

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 31 Jan 2006 02:08:05 -0800

Bora,

> Does this mean that you are using the flow label in lieu
> of the regular IPSEC SP match?
All I am saying is just as we can have local and remote ports as
selectors; we can instead use Flow Labels along with the IP addresses
for the same purpose, if some assumptions can be made for the flow
label. 

Is my understanding wrong?

Thanks,
Vishwas
-----Original Message-----
From: Bora Akyol [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2006 12:51 AM
To: Vishwas Manral; Spencer Dawkins; [email-masked]
Subject: RE: Flow label and its uses

Hi

Thanks

Bora

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 31 Jan 2006 10:15:35 -0800

Flow label is not a field that is protected by IPSEC
hence I do not think you can use
this as a selector.

Unless you do modifications to IKEv2, you can not also let
the other end know what exactly the SP (security policy)
is based on.

Frankly, use of flow label as a selector would be a hack
to get around the problem of the full security policy lookup
in IPSEC at high speeds. The truth is that this has not
been a problem for at least 4-5 years now as long
as the selectors themselves are TCAM friendly.

Bora

> From: Vishwas Manral [mailto:[email-masked]] 
> Sent: Tuesday, January 31, 2006 2:08 AM
> To: Bora Akyol; Spencer Dawkins; [email-masked]
> > Does this mean that you are using the flow label in lieu of the 
> > regular IPSEC SP match?
> All I am saying is just as we can have local and remote ports 
> as selectors; we can instead use Flow Labels along with the 
> IP addresses for the same purpose, if some assumptions can be 
> made for the flow label. 
>