Subject: Revising Flow-Labels of RFC-3697 - A possible direction?

From: Rémi Després <[email-masked]>
Date: Thu, 9 Sep 2010 14:09:42 +0200

Hi all.

 Draft-gont-6man-flowlabel-security is based on the assumption that FL values are set as currently specified in RFC 3697, i.e. with a *stateful* algorithm that needs to keep track of flow establishments and terminations, and with FL immutability. 
 However, assuming that the aim of envisaged revision of RFC 3697 is to have FLs actually used, *stateless* FL assignments, with some restricted mutability rules, is in my understanding, a valuable approach. 

 With this stateless operation, FL values may be determined on a per-datagram basis. They may in particular be simple hashes of n-tuples that identify flows.
 A potential drawback is that, in rare occasions (i.e. bad luck with the hash algorithm), two simultaneous flows from a same source may have the same FL value although they have different n-tuples.
 But load balancing, which the intended purpose of FLs, only operates on flow aggregates.
 Thus, routing to the same path two flows from a same source has no more effect than doing it for two flows from different sources. The effect is negligible.

The best combination I personally get, considering past discussions on a potential RFC-3697 revision, is so far as follows:

 R1. Packet sources SHOULD set FLs to non-zero values that generally differ from a flow to another (e.g. with currently specified stateful algorithms, or with n-tuple hashes).

 R2. Packet sources MUST set FLs to zero otherwise. 

 R3. Intermediate nodes MAY replace null FL values by non-zero FL values, PROVIDED these non-zero values generally differ from a flow to another.
 
 R4. Intermediate nodes MAY replace non-zero FL values by non-zero FL values, PROVIDED these non-zero values generally differ from a flow to another. 

 R5. Intermediate nodes MAY replace non-zero FL values by null values ONLY IF found necessary for some identified policy-dependent security reason (e.g. in some managed firewalls).

 R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs of encapsulated packets in encapsulating packets.

 R7. Nodes that tunnel flow aggregates SHOULD set FLs of encapsulating packets that contain null FLs to a value that characterize the tunnel itself, and MUST set it to 0 otherwise.  

NOTE: Since most packets of a fragmented TCP datagram don't contain ports that identify the 5-tuple of their flow, computing new non-zero FL values implies operation at the datagram layer.

Criticisms and/or support of this approach, in general or in details, are solicited. 
The idea is to determine whether continuing to contribute in this direction is useful or not.

Regards,
RD

Le 13 août 2010 à 02:45, Fernando Gont a écrit :

> Folks,
> 
> I have just published an Internet-Draft entitled "Security Assessment of
> the IPv6 Flow Label" that analyzes the security implications of the Flow
> Label header field, and proposes a scheme to set the Flow Label that is
> compliant with RFC 3697, and compatible with
> draft-blake-ipv6-flow-label-nonce-02.
> 
> The I-D is available at:
> http://tools.ietf.org/id/draft-gont-6man-flowlabel-security-00.txt
> 
> Thanks!
> 
> Kind regards,
> Fernando
> 
> 
> 
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-gont-6man-flowlabel-security-00
> Date: Thu, 12 Aug 2010 15:07:50 -0700 (PDT)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> 
> 
> A new version of I-D, draft-gont-6man-flowlabel-security-00.txt has been
> successfully submitted by Fernando Gont and posted to the IETF repository.
> 
> Filename:	 draft-gont-6man-flowlabel-security
> Revision:	 00
> Title:		 Security Assessment of the IPv6 Flow Label
> Creation_date:	 2010-08-12
> WG ID:		 Independent Submission
> Number_of_pages: 20
> 
> Abstract:
> This document discusses the security implications of the IPv6 "Flow
> Label" header field, and analyzes possible schemes for selecting the
> Flow Label value of IPv6 packets.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> 
> -- 
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Sep 2010 15:31:07 -0300

Hi, Remi,

> Draft-gont-6man-flowlabel-security is based on the assumption that FL
> values are set as currently specified in RFC 3697, i.e. with a
> *stateful* algorithm that needs to keep track of flow establishments
> and terminations, and with FL immutability. 

Note: the only additional "state" in the algorithm is the counter.

As for keeping track of flows, as I've just noted to Steven, this is a
refinement. But you could probably live assuming that all flows
terminate in a period equal to the duration of the flow label space
(i.e., when the flowlabel space wraps and you'd reuse a flowlabel value,
the flow that was previously using that FL value has already terminated)

While I've assumed that RFC3697 holds when wrote draft-gont, FL
immutability is not a requirement for the algorithm to work.

> The best combination I personally get, considering past discussions
> on a potential RFC-3697 revision, is so far as follows:
> 
> R1. Packet sources SHOULD set FLs to non-zero values that generally
> differ from a flow to another (e.g. with currently specified stateful
> algorithms, or with n-tuple hashes).
> 
> R3. Intermediate nodes MAY replace null FL values by non-zero FL
> values, PROVIDED these non-zero values generally differ from a flow
> to another.
> 
> R4. Intermediate nodes MAY replace non-zero FL values by non-zero FL
> values, PROVIDED these non-zero values generally differ from a flow
> to another.
> 
> R5. Intermediate nodes MAY replace non-zero FL values by null values
> ONLY IF found necessary for some identified policy-dependent security
> reason (e.g. in some managed firewalls).

I'd make R3 through R5 a "SHOULD NOT.... but if you do, do it this way".
-- but could certainly with your "MAY", as stated.

> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs
> of encapsulated packets in encapsulating packets.
> 
> R7. Nodes that tunnel flow aggregates SHOULD set FLs of encapsulating
> packets that contain null FLs to a value that characterize the tunnel
> itself, and MUST set it to 0 otherwise.

Will give these last two another thought.

Thanks!

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2010 09:51:18 +1200

Rémi,

This is quite similar to one possible version of
draft-carpenter-6man-flow-update-04 that is spinning
around on my hard disk. But I really want to get clarity
(if not rough consensus) on the immutability thread before
being certain what we should propose.

I think the rules about tunnels should be completely separate,
and they are really the subject of the other draft,
draft-carpenter-flow-ecmp-02.

Regards
   Brian Carpenter

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Sep 2010 09:46:19 +0200

Hi Fernando,

Thanks for the fast reaction.
More below.

> immutability is not a requirement for the algorithm to work.

Note that my proposal doesn't exclude stateful algorithms (no objection to yours in particular).
It just authorizes stateless algorithms provided they are adequate for the load-balancing purpose.

> -- but could certainly with your "MAY", as stated.

About R3: If part of a network has the ability to identify 5-tuples and to compute FLs, replacing null FLs by non-zero FLs seems to me a completely acceptable choice.

About R4: If part of a network has the ability to identify 5-tuples and to compute good FLs, and has no confidence in upstream provided FLs, I see no objection to its replacing old FLs by supposedly better ones for its own load balancing (and, by the same token, for that of downstream networks that use upstream FLs).

About R5: I agree that SHOULD NOT would be better, with no objection to adding "unless found strictly necessary..."

>> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs encapsulated packets in encapsulating packets.
>> 

Look forward to it.

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Sep 2010 10:21:53 +0200

> being certain what we should propose.

It certainly makes sense before issuing the new version.
The idea is to try and identify clearly which consensus we talk about.
For this, a succinct expression of what we plan to get at the end, like the proposed R1 to R7, is intended to be helpful.

BTW, would you be personally satisfied if R1-R7 would reflect the final consensus?

> draft-carpenter-flow-ecmp-02.

Having all the FL information in one draft is IMHO more reader friendly, but I have no serious objection to the 2-draft approach that you seem to prefer.

RD

>> ...

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Sep 2010 15:18:44 +0200

Hi Brian and Rémi:

This set of rules recognizes that the flow label can be overridden to be used locally in a network according to the rules and policies that apply to this network. I'm all for it.
OTOH, the proposal assumes that the rules in place in that network are necessarily related to load balancing. There I have to disagree.

While this is certainly the most widespread usage of the FL that we know of today, I do not see the value of placing a constraint there.
But if the use is local and the local network can ensure that the contiguous routers that use it do so in a consistent fashion, there's no point telling them what they do with it.

You know that in the back of my mind I still wish to use the Flow Label as an alternate to the RPL HbH option. 
In a RPL network, we can afford to do load balancing based on classical tuple, but we need space for the datapath validation information. 
For all I know, it is a fair usage of the flow label, and this demonstrates that there's no one-size-fits-all definition of what to do with it.

In fact, I cannot see how we could agree on a global significance of the field at this point so keeping it local makes great sense.
What must be ensured is that if a router uses the FL in a certain fashion, then the next router understands it or ignores it leaving it untouched.

This means we should:
- define boundaries where the usage of a field must be consistent (one hop? One subnet? ISP boundaries?)
- allow network-local usages that are open but must be consistent with the network boundaries as specified above.
- propose some such recognized-valid usages (like: source application mapping flows or sessions onto FL, routers applying multi-topology routing tag, routers applying load balancing tags...)

At the end of the day, we should let the network designer decide what's most important for his network.

What do you think?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Thursday, September 09, 2010 11:51 PM
> To: Rémi Després
> Cc: Thomas Narten; 6man 6man; Steven Blake; Fred Baker (fred)
> Subject: Re: Revising Flow-Labels of RFC-3697 - A possible direction?
> 
> Rémi,
> 
> draft-carpenter-6man-flow-update-04 that is spinning around on my hard disk.
> But I really want to get clarity (if not rough consensus) on the immutability
> thread before being certain what we should propose.
> 
> I think the rules about tunnels should be completely separate, and they are
> really the subject of the other draft, draft-carpenter-flow-ecmp-02.
> 
> Regards
>    Brian Carpenter
> 
> >  Draft-gont-6man-flowlabel-security is based on the assumption that FL values
> are set as currently specified in RFC 3697, i.e. with a *stateful* algorithm that
> needs to keep track of flow establishments and terminations, and with FL
> immutability.
> >  However, assuming that the aim of envisaged revision of RFC 3697 is to have
> FLs actually used, *stateless* FL assignments, with some restricted mutability
> rules, is in my understanding, a valuable approach.
> >
> >  With this stateless operation, FL values may be determined on a per-
> datagram basis. They may in particular be simple hashes of n-tuples that
> identify flows.
> >  A potential drawback is that, in rare occasions (i.e. bad luck with the hash
> algorithm), two simultaneous flows from a same source may have the same FL
> value although they have different n-tuples.
> >  Thus, routing to the same path two flows from a same source has no more
> effect than doing it for two flows from different sources. The effect is
> negligible.
> >
> > The best combination I personally get, considering past discussions on a
> potential RFC-3697 revision, is so far as follows:
> >
> >  R1. Packet sources SHOULD set FLs to non-zero values that generally differ
> from a flow to another (e.g. with currently specified stateful algorithms, or with
> n-tuple hashes).
> >
> >  R3. Intermediate nodes MAY replace null FL values by non-zero FL values,
> PROVIDED these non-zero values generally differ from a flow to another.
> >
> values, PROVIDED these non-zero values generally differ from a flow to
> another.
> >
> >  R5. Intermediate nodes MAY replace non-zero FL values by null values ONLY
> IF found necessary for some identified policy-dependent security reason (e.g. in
> some managed firewalls).
> >
> >  R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs of
> encapsulated packets in encapsulating packets.
> >
> packets that contain null FLs to a value that characterize the tunnel itself, and
> MUST set it to 0 otherwise.
> >
> > NOTE: Since most packets of a fragmented TCP datagram don't contain ports
> that identify the 5-tuple of their flow, computing new non-zero FL values
> implies operation at the datagram layer.
> >
> >
> >> I have just published an Internet-Draft entitled "Security Assessment
> >> of the IPv6 Flow Label" that analyzes the security implications of
> >> the Flow Label header field, and proposes a scheme to set the Flow
> >> Label that is compliant with RFC 3697, and compatible with
> >> A new version of I-D, draft-gont-6man-flowlabel-security-00.txt has
> >> been successfully submitted by Fernando Gont and posted to the IETF
> repository.
> >>
> >> e-mail: [email-masked] || [email-masked] PGP Fingerprint: 7809
> >> 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >>
> >>
> >>
> >>

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Sep 2010 16:25:47 +0200

> OTOH, the proposal assumes that the rules in place in that network are necessarily related to load balancing. There I have to disagree.

That's where there is a problem.
If an intermediate network modifies the FL for a different purpose, and doesn't restore it at its exit, then downstream networks can no longer use FLs for load balancing as currently specified.
The whole purpose of RFC3697 is then defeated.

Note that intermediate networks have always been free to use FLs for their own usage PROVIDED they restore received values at exit. This is an internal matter.

The unavoidable choice seems to be between:
a) keep the currently defined purpose (load balancing), improve the specification (e.g., in substance, with something like the proposed 7 rules), and thus preserve *backward compatibility*.
b) now permit all traversed networks to freely modify FLs for their own purposes, and to leave arbitrary FL values at exit, thus *deprecating the current purpose* and losing backward compatibility.
c) officially deprecate the current purpose, and *reserve FLs for some future use TBD* 

The worse would be not to choose, defeating in practice all purposes.
Discussing the same points over and over again is just a waste of energy.

> In fact, I cannot see how we could agree on a global significance of the field at this point so keeping it local makes great sense.

If the choice is to preserve backward compatibility (BTW the choice for which I vote), I am confident that a consensus can be identified and documented.
The short 7 rules I listed are a tentative to capture what the current best consensus seems to be (I may be wrong, but it's worth trying).

> At the end of the day, we should let the network designer decide what's most important for his network.

Sure, but provided standards are still complied after their networks have been traversed.

> What do you think?

Expressed above.

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Sep 2010 16:02:55 -0300

Hi, Rémi,

>> As for keeping track of flows, as I've just noted to Steven, this
>> is a refinement. But you could probably live assuming that all
>> flows terminate in a period equal to the duration of the flow label
>> space (i.e., when the flowlabel space wraps and you'd reuse a
>> flowlabel value, the flow that was previously using that FL value
>> has already terminated)
>> 
> Note that my proposal doesn't exclude stateful algorithms (no
> objection to yours in particular). It just authorizes stateless
> algorithms provided they are adequate for the load-balancing purpose.
> 
I just wanted to clarify that the algorithm doesn't need additional
state (as sometimes "state" at layer-3 is deemed as a show-stopper :-) )

>>> R1. Packet sources SHOULD set FLs to non-zero values that
>>> generally differ from a flow to another (e.g. with currently
>>> specified stateful algorithms, or with n-tuple hashes).
>>> 
>>> values, PROVIDED these non-zero values generally differ from a
>>> flow to another.
>>> 
>>> R4. Intermediate nodes MAY replace non-zero FL values by non-zero
>>> FL values, PROVIDED these non-zero values generally differ from a
>>> flow to another.
>>> 
>>> R5. Intermediate nodes MAY replace non-zero FL values by null
>>> values ONLY IF found necessary for some identified
>>> policy-dependent security reason (e.g. in some managed
>>> firewalls).
>> I'd make R3 through R5 a "SHOULD NOT.... but if you do, do it this
>> way". -- but could certainly with your "MAY", as stated.
> 
> About R3: If part of a network has the ability to identify 5-tuples
> and to compute FLs, replacing null FLs by non-zero FLs seems to me a
> completely acceptable choice.

As I said, IMHO your "MAY" is acceptable. -- BTW, in R3 omit the
"generally" ;-)

> About R4: If part of a network has the ability to identify 5-tuples
> and to compute good FLs, and has no confidence in upstream provided
> FLs, I see no objection to its replacing old FLs by supposedly better
> ones for its own load balancing (and, by the same token, for that of
> downstream networks that use upstream FLs).

Same as above.

> About R5: I agree that SHOULD NOT would be better, with no objection
> to adding "unless found strictly necessary..."

I guess that if we make the above "MAY"s, this one could be a MAY, too.

>>> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero
>>> FLs encapsulated packets in encapsulating packets.
>>> 
>>> R7. Nodes that tunnel flow aggregates SHOULD set FLs of
>>> encapsulating packets that contain null FLs to a value that
>>> characterize the tunnel itself, and MUST set it to 0 otherwise.

I'd probably specify these last two in a different document, aimed at
tunnels.

However, I'd not that R6 and R7 seem to lead to inconsistency: according
to R6, the tunnel's FL reflects what's being transferred over the
tunnel. According to R7, the tunnel's FL characterizes the tunnel itself.

Thanks!

Kind regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Sep 2010 08:35:08 +1200

> For this, a succinct expression of what we plan to get at the end, like the proposed R1 to R7, is intended to be helpful.

The slight problem with that is until you analyse the implications
of each rule, and write it in RFC 2119 language, you can't be sure
that there is no inconsistency or indeterminancy.

> BTW, would you be personally satisfied if R1-R7 would reflect the final consensus?

Oh, I will be personally satisfied if we ever reach rough consensus on
any solution ;-)

    Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Sep 2010 10:31:05 +0200

> that there is no inconsistency or indeterminancy.

Agreed, the check is necessary.
We will have to do it.

> Oh, I will be personally satisfied if we ever reach rough consensus on

Then, it's a yes, but without an expressed personal preference.`
IMHO, the consensus is easier to detect if some preferences are expressed by those who care.

Best regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Sep 2010 11:01:01 +0200

Le 10 sept. 2010 à 21:02, Fernando Gont a écrit :

> As I said, IMHO your "MAY" is acceptable.

> -- BTW, in R3 omit the

"Generally" conveys the point that collisions are acceptable provided they are rare enough.
In my understanding, it has to apply in the same way in R1, R3, and R4.

"Generally differ from a flow to another" was intended to mean "differ from a flow to another with a good probability" (collisions are permitted, but only with a low probability).

If the substance is agreed, this should be made clear in resulting drafts.  

> I'd probably specify these last two in a different document, aimed at

I confirm that, despite my preference for a single document, I have no serious objection to 2 documents as proposed by Brian.

> tunnel. According to R7, the tunnel's FL characterizes the tunnel itself.

I see.
R7 could be made clearer with something like:
"R7 encapsulating packets that contain null-FL packets to a value that characterize the tunnel itself for flows of the aggregate that are not individually identified, and if they don't MUST set these FLs to 0. 

Thanks?

Best regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 2010 11:32:49 +1200

> You know that in the back of my mind I still wish to use the Flow Label as an alternate to the RPL HbH option. 

I can imagine how that might work as long as the packets concerned never
left the scope of RPL, but the results would be very strange
if such flow label values "escaped" to the rest of the Internet.

In any case, I think this door can be left open. However, since RPL with
the hop-by-hop option is in Last Call, it may become academic.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 2010 11:38:41 +1200

> R3. Intermediate nodes MAY replace null FL values by non-zero FL values, PROVIDED these non-zero values generally differ from a flow to another.

IMHO that isn't a strong enough condition, if we want load balancing to be
the preferred default usage. In fact it is one of the criticisms of 3697
that all it demands is a unique value, rather than a pseudo-random value.

>  R4. Intermediate nodes MAY replace non-zero FL values by non-zero FL values, PROVIDED these non-zero values generally differ from a flow to another. 

That makes the FL completely mutable. I don't detect consensus for that; as
people have said, we have diffserv for that, and 6 bits seems to be plenty...

>  R5. Intermediate nodes MAY replace non-zero FL values by null values ONLY IF found necessary for some identified policy-dependent security reason (e.g. in some managed firewalls).

I'd go a bit further - if a domain ends up using non-pseudo-random values,
they should be zeroed out before letting packets escape the domain.

     Brian

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Sep 2010 09:50:56 +0200

> that all it demands is a unique value, rather than a pseudo-random value.

I now understand that this wording is insufficiently precise, thanks.

Would it be more acceptable to replace "generally differ from a flow to another" by:
"have a low probability of collisions with those of other flows, be they from the same source or not."

In my understanding, a hash of n-tuples that identify flows, with or without a combination with a stateful counter, satisfies this constraint.

Is there something I still miss? 

> That makes the FL completely mutable. I don't detect consensus for that;

Mutable *within the constraint of the strong condition above* is different from *completely mutable*.

The reason for R4 is that, if some intermediate nodes that hve tools and the processing power available to re-compute good n-tuple hashes, their administrators may wish to increase confidence in their own load balancing by re-computating FLs. 
 
This behavior wouldn't IMHO be typical but, as it doesn't disrupt anything, it should at least be permitted.

> as

Diffserv code points having no relationship with the load balancing objective, they shouldn't IMHO have an impact on how to improve RFC 3697.

> they should be zeroed out before letting packets escape the domain.

I hope the consensus would be that no domain would be permitted to use non-pseudo-random values if not restoring original values at exit.
Otherwise, the value of setting FLs in sources would IMHO diminish to much.
 
As a matter of fact, I would personally be better satisfied if intermediated nodes *SHOULD NOT* replace non-zero values by null values.
Even better *MUST NOT*, but I got the impression that this was not acceptable to firewall people (=> to be checked?).

Regards,
RD