Subject: Re: Usage of IPv6 flow label

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Dec 2000 09:54:31 +0100

In your previous mail you wrote:

   - figure out a way to make the other option in Alex's draft:
   
         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|  Server Port Number| H-to-H protocol|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   suitable for use by policy-driven diffserv classifiers. 
   
=> can you explain why it is not enough to use the SPI in place of
higher layer selectors?

[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: Jim Bound <[email-masked]>
Date: Fri, 01 Dec 2000 12:02:19 -0500

brian,

I like this better.

if leftmost bit is set in flowlabel then it can be used for diffsv and
alex strategy or port numbers or whatever you want for layer 4
switch/diff/etc...

if leftmost bit is not set then client sets it and is used as itojuns
api suggests and jochen.  and the orginal intention in SIP and IPv6.

fred baker proposed this sometime ago when thoughts generated using it
for mpls.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 11:07:28 -0600

Francis,

>    - figure out a way to make the other option in Alex's draft:

The SPI doesn't have the semantics. A QOS classifier needs to *know*
the port and protocol numbers; that's how it takes its decisions.
For example you might put traffic with protocol number 30 in a
different class from traffic with protocol number 41.

Alex's idea of using "server port number" is in fact
interesting, since it would allow you to classify traffic
on its original well-known port #, without having to rely
on dynamically assigned port #s for classification.
I'm beginning to think he may be right. But I suggest
allocating 11 bits to the port number and 8 to the
protocol number, so that we can cover at least
some of the registered ports (up to 2047). But the flow
label isn't long enough for everything we need.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Dec 2000 19:21:54 +0100

> => can you explain why it is not enough to use the SPI in place of
   
   The SPI doesn't have the semantics.

=> I disagree, the SPI has the semantics we'd like to give to it.

   A QOS classifier needs to *know*
   the port and protocol numbers; that's how it takes its decisions.

=> I can't see a deep difference between a QoS classifier and
a SPD entry.

=> and you might use a different SPI... I can't see why it is
possible to associate to some kind of flow a 24 bit pseudo-random
number (the flow label) and not a 32 bit pseudo-random number
(the SPI).

=> I don't like the idea to have an official cover-channel
with the flow label: security people won't buy this.
They'd like to hide things then they can express their policy
(ie. what they accept to reveal) into the SPD then the choice
of SPIs...

   But the flow label isn't long enough for everything we need.

=> the SPI is 32 bit long (:-)!
   
Regards

PS: I am in no camp. I believe Jim/Itojun/... are right but the
flow label is not protected by AH then a router may rewrite it.
As it is not a stack it should be rewritten only closed to the source
(ie. if you want to rewrite it anywhere you should encapsulate packets
before, the decapsulation will restore the original flow label).
In the future I can see two cases:
 - the flow label is set by the source (first camp)
 - the flow label is set by an edge router (with the DiffServ definition
   of what is an edge router) because the source box (or its user) is
   too dumb to deal with QoS/..., according to the edge router manager.
I think we'll get a mixed situation.
--------------------------------------------------------------------
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: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Dec 2000 14:48:06 -0500

> => I disagree, the SPI has the semantics we'd like to give to it.

When reasonable key management protocols are in use, IPSEC SPI's are
pseudo-random, chosen by the receiver, and securely communicated to
the sender via the key management protocol.  

The use of random spi's is one of the defenses against off-path
denial-of-service attacks.. an off-path attacker forging source
addresses cannot easily guess a valid SPI, and so packets with invalid
SPI's can be quickly discarded without requiring any cryptographic
processing.

What semantics do you think you can impose on something like that?

					- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 14:23:43 -0600

Francis,

The bits used by a QOS classifier are *not* pseudo-random. They are
actual port numbers and protocol numbers. You are comparing apples
amd oranges.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Dec 2000 23:56:10 +0100

=> the only problem is "chosen by the receiver" because the first
packet will reveal the SPI to on-path attackers.

=> they can be only discarded if you know valid SPIs, ie. by the receiving
node (which can be overloaded just by a big number of packets) or if
a firewall has the needed knowledge (ie. there is a protocol which gives
new SPIs to it).

=> just associate a QoS to a SPI and send the information (ie. how to
classify packets (addresses, ..., SPI) and the QoS) to the classifier
(which is by definition on-path).
 Another solution is to ask the receiver to be less random (again the
info will be spread only on-path).

Regards

PS: I assumed in my previous mail than the trade-off was between flow
labels and SPIs. If we considered that flow labels *can't* replace
a part of famous 5-tuples then of course the same consideration
applies to SPIs.
PPS: Bill, as a IPsec person, would you like to have upper layer protocol
and port revealed in flow labels?
--------------------------------------------------------------------
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: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Dec 2000 18:27:49 -0500

> (which is by definition on-path).

That could be brute-forced into working if someone invented such a
protocol.  However, it seems that you could accomplish the same goal
by having the originator of the traffic mark the diffserv bits of the
packet "appropriately", with the classifier merely having some policy
saying which nodes are allowed to send ipsec traffic with various
markings, possibly translating the markings appropriately.

> info will be spread only on-path).

I doubt that this option would be acceptable to the ipsec community.

> and port revealed in flow labels?

No, that leaks information useful to someone doing traffic analysis;
I'd rather let the node doing the ipsec encapsulation mark it with a
much coarser-grained QoS class.

(besides, I'd just hack my implementation to let you configure the
"most favorable treatment" port number in the flow label..)

					- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 17:30:47 -0600

Francis Dupont wrote:
...
> (which is by definition on-path).

Wrong model. That requires signalling; diffserv doesn't have signalling.

This works for RSVP as itojun explained, but it doesn't work for diffserv.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Dec 2000 17:04:09 -0600

> markings, possibly translating the markings appropriately.

This doesn't necessarily work when you cross an ISP/ISP boundary. 
We can't assume that appropriate SLAs exist at all ISP boudaries; 
the only method that is sure to work is if each ISP can re-classify 
the traffic at its ingress. Believe me, we have thought about this 
*a lot* in diffserv.

   Brian

---

From: Steve Deering <[email-masked]>
Date: Mon, 4 Dec 2000 08:27:00 -0800

>This works for RSVP as itojun explained, but it doesn't work for diffserv.

I'm getting confused.  The Flow label is intended for intserv, so why
are you talking about subverting it (or the SPI) for diffserv?

If diffserv requires en-route inspection of the 5-tuple in order to set
the DSCP bits (and therefore you are trying to overload the Flow Label
with port semantics in order to avoid the cost of finding the ports),
that ought only to be done near the source edge (where parsing multiple
headers is less onerous), if at all, because of the ease with which one
could lie about one's port numbers to obtain better service.  Are core
routers really going to provide different qualities of service to packets
based on an easily "forged" 8-bit integer?

I thought core routers classified packets for diffserv packets according
to the arrival interface and the arriving DSCP bits, *not* the 5-tuple.

Steve

---

From: Steve Deering <[email-masked]>
Date: Mon, 4 Dec 2000 08:33:33 -0800

>   too dumb to deal with QoS/..., according to the edge router manager.

If the Flow Label is set by something other than the source node, how
do you guarantee its uniqueness, over the topological scope in which
it must be unique?  Do you need to invent a protocol between the routers
on a LAN to divvy up the Flow label space?  What happens when the LAN
partitions, then routers in the different partitions assign duplicate
Flow Labels, and then the partition heals?

Steve

---

From: Steve Deering <[email-masked]>
Date: Mon, 4 Dec 2000 08:38:25 -0800

At 8:27 AM -0800 12/4/00, Steve Deering wrote:
>Are core routers really going to provide different qualities of service
>to packets based on an easily "forged" 8-bit integer?

Oops, that was supposed to be 16-bit integer (a port number).

Steve

---

From: Jim Bound <[email-masked]>
Date: Mon, 04 Dec 2000 12:40:46 -0500

>Flow Labels, and then the partition heals?

Obviously I agree with Steve and this is a killer point.  Recall in dec
when we pushed the CE bit and it would only work exactly as Steve states
won't work above.  It never got used or deployed.  It needs to come from
the source and honored by the routers.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 04 Dec 2000 12:43:07 -0500

>to the arrival interface and the arriving DSCP bits, *not* the 5-tuple.

This was my "impression" too.  And why I stated to Brian I am happy with
the DCSP bits but not what I am hearing else can be done????

thanks Steve for saying this more clearly.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Dec 2000 14:40:54 +0100

it must be unique?

=> is a pseudo-random value enough? It is very expensive to get an
absolute guarantee even on the source node itself...

   Do you need to invent a protocol between the routers
   on a LAN to divvy up the Flow label space?  What happens when the LAN
   partitions, then routers in the different partitions assign duplicate
   Flow Labels, and then the partition heals?
   
=> this can happen. I didn't say the edge router stuff is the best or
even good, just this has happened for IPv4/IntServ and this would happen
for flow labels too, and this is not (IMHO) bad enough to prohibit this.

Thanks

PS: this is a maginal sub-thread, the important one is how to reclassify
(and remark) packets in the core between two domains...
--------------------------------------------------------------------
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: Alex Conta <[email-masked]>
Date: Wed, 06 Dec 2000 11:54:54 -0500

Francis Dupont wrote:
> [...]

Francis,

If I understand you correctly, you think it is not good to have the
flow-label carry "in clear" information which is also carried in parts
of the
transport header, which is hidden through encryption.

Well, the source and destination, are in clear.... But, if one wants to
protect
the flow label, then the packet can be encrypted in tunnel mode, to hide
everything in the IPv6 maim header.

Alex

---

From: Alex Conta <[email-masked]>
Date: Wed, 06 Dec 2000 12:12:04 -0500

If I recall correctly, the DEC bit didn't need allocation, so I do not
follow the analogy you're making to the "flow label" allocation.

Alex

P.S. the DEC bit was used by early DECNET versions, but I am not sure if
it was not dropped
in DECnet Phase 5, when OSI network protocols replaced the proprietary
DECnet ones. A similar, but somewhat extended mechanism exists in Frame
Relay networks:  BECN & FECN.

---

From: Alex Conta <[email-masked]>
Date: Wed, 06 Dec 2000 12:48:15 -0500

If the topological space on which a label is unique is reduced, ala
MPLS, to a one-hop link, and the label distribution is using TCP, ala
MPLS, the collision of the label space in case of LAN 
partioning/healing is an interesting problem.  It can be handled, I
think, assuming, the first and the last hop of a communication, in
several ways:

a. there is no collision because 
	- the label allocation continues undisturbed after
partitioning/healing, and 
	- only the originally LAN designated router does the allocation. 

   The "one-hop" TCP connection for Label Distribution that exists
between each host and the 
   LAN router in the pre-partioning stage, becomes a "two or more hops"
connection during the          "partioned" stage, to come back to the
"one-hop" form after "healing".

b. at partitioning, the newly designated routers and their dependent
hosts do, ala MPLS:
	- break old peering, with deallocation of labels 
	- create new peering, with reallocation of labels
   at healing, the process is repeated.

	This process affects only the next-hop to the host, and thus does not
affect the rest of         the path.

c. designated routers divide the label space, as you said, to prevent
collision after potential partioning/healing. 

Alex

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Dec 2000 19:07:49 +0100

If I understand you correctly, you think it is not good to have the
   flow-label carry "in clear" information which is also carried in parts
   of the transport header, which is hidden through encryption.

=> I am afraid that the paranoic security guy (and usually he is)
will simply say: flow label is supposed to be a pseudo-random number,
someone is using it as a cover channel, just reset it to zero.
I agree this will be a silly attitude but in fact the flow label was
not designed to do that (for years we don't use it and now we fight
for keeping it for us :-).

=> I am not a IPsec == VPN person. My real concern is I'd like to keep
the flow label for IntServ, and to give to DiffServ more flexibility
(ie. more/enough bits). I have no opinion about MPLS...

Thanks

---

From: Jim Bound <[email-masked]>
Date: Wed, 06 Dec 2000 20:54:53 -0500

>follow the analogy you're making to the "flow label" allocation.

My analogy was that unless all nodes along the path support the method it
does not work.

regards,
/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Dec 2000 13:36:27 -0600

Catching up after some delay and being able to discuss this
in person with Francis yesterday...

> are you talking about subverting it (or the SPI) for diffserv?

Because diffserv has a problem if it needs to re-classify encrypted
traffic, since the port & protocol #s are hidden. However, the idea
of an extension header is *much* better than subverting the flow
label.

> based on an easily "forged" 8-bit integer?

No, as has been said this will happen (if at all) in border routers.
Theft of service is an issue - we don't want to pay authentication
overhead in a real-time classifier. But traffic policing can take
care of most cases. See RFC 2474 and 2475.
> to the arrival interface and the arriving DSCP bits, *not* the 5-tuple.

Absolutely. It's only at the borders. 

So the model that probably works is an optional extension header that
can be used for encrypted packets where the source doesn't mind exposing
the port and protocol #s. However, people building classifier hardware
may have something to say about this in terms of real time efficiency.

  Brian

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 07 Dec 2000 13:37:24 -0500

I haven't seen a convincing case why even inter-ISP classifiers need
to know the inner port numbers or inner ip addresses for encrypted
traffic.

If I were implementing the hypothetical extension header, I'd have to
provide policy knobs which determine whether it gets added to outbound
traffic; while i'm there, in the interests of reducing traffic
analysis, I might as well add a knob which lets the policy rule
specify what goes in the extension header (independant of the actual
inner traffic), and naturally, in the interest of interoperability,
there's no way that the receiver would enforce a relationship between
the extension header and the actual packet traffic (because it doesn't
actually matter to the end system and flies in the face of the "be
liberal in what you accept" principle).

Given that, I don't see what the extension header actually buys you..

The inter-ISP classifier can still reclassify based on a 3-tuple
(outer-src,outer-dst,outer-proto=ESP), and at the ISP boundary can
still deliver differentiated services to customers who want (and pay
for) priority handling of encrypted traffic based on the destination
address of a packet received from a peer using an unknown diffserv
tagging scheme; and, even if you do know the tagging scheme, you still
likely have to use the inbound tag in conjunction with other selectors
to determine the tag used within your network..

If there's demand for multiple classes of handling for encrypted
traffic between a single pair of hosts, then both customers will be in
a position to pressure their ISP's to play nice together and agree how
to label traffic on the inter-ISP link.

					- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 13:38:55 -0600

Bill,

You describe accurately what we get by changing nothing: encrypted traffic
will be subject to a less rich set of QOS policy options than
unencrypted traffic.

  Brian