Subject: draft-gont-6man-flowlabel-security-00

From: Shane Amante <[email-masked]>
Date: Mon, 08 Nov 2010 22:28:36 -0700

Hi,

At the mic at 6man today, I brought up a concern wrt this draft. 
Specifically, the way I currently read this version of the draft, if 
there are several [dozen] "flows" between the _same_ {source_IP, 
destination_IP} 2-tuple, it appears they will end up with _same_ 
flow-label value.

As I read the current text:
---snip---
    Flow Label = counter + F(Source Address, Destination Address, Secret 
Key)

    where:

    counter:
       Is a variable that is initialized to some arbitrary value, and is
       incremented once for each flow label value that is selected.
---snip---
... there isn't anything that I've read that the "counter" is 
incremented for each, new {protocol, src_port, dst_port}.  Can you 
clarify if I've missed this in the existing text?

Again, to restate my goal, in the future, it would be ideal if we could 
on routers _only_ use {src_ip, dst_ip + flow_label} as input-keys for 
the LAG + ECMP hash algorithm.  Unfortunately, if this draft is 
proposing to exclude the granularity of {protocol, src_port + dst_port} 
we won't be able to get there.

Thanks,

-shane

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Nov 2010 04:55:08 -0300

Hi, Shame,

Please find my comments inline...

> destination_IP} 2-tuple, it appears they will end up with _same_

No. See bellow.

> clarify if I've missed this in the existing text?

The text you quoted says "[counter] is initialized to some arbitrary
value, and is incremented once for each flow label value that is
selected.". That means that right after a "Flow Label" is selected for
each of your dozen flows, "counter" will be incremented.

FWIW, "protocol" doesn't matter -- the "Flow Label" needs to be unique
on a (src IP, dst IP basis).

> we won't be able to get there.

draft-gont ensures uniqueness on a (src ip, dst ip) basis, which in turn
means that it is unique for (src ip, dst ip, dst port) (the converse
would not be true). -- e.g., see "Table 1" in the I-D.

Different flows between a set of (src ip, dst ip) get different Flow
Labels (despite their port numbers). -- so you *can* use (src ip, dst
ip, flow label) for LAG + ECMP.

Put in other words, what you're currently getting is actually
*more*¨than what you're asking for! ;-)

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Shane Amante <[email-masked]>
Date: Tue, 09 Nov 2010 01:16:51 -0700

Fernando,

On 11/9/2010 12:55 AM, Fernando Gont wrote:
> selected.". That means that right after a "Flow Label" is selected
> for each of your dozen flows, "counter" will be incremented.
>
> FWIW, "protocol" doesn't matter -- the "Flow Label" needs to be
> unique on a (src IP, dst IP basis).

But, this *reduces* the amount of entropy I get today by looking at the 
whole 5-tuple.  And, it means that I can't just use the 3-tuple of 
{src_ip, dst_ip, flow_label} as input-keys for LAG/ECMP.  Specifically, 
at time t1 if I have two flows that start up between the same 2-tuple:
1)  FTP: 9 Gbps
2)  WWW: 9 Gbps
... both of the above flows will have identical {src_ip, dst_ip, 
flow-label}.  When they arrive at my router, if that 3-tuple are the 
only input keys they *will* end up on the same 10 Gbps component-link in 
a LAG and result in congestion of that component-link.

OTOH, if you're proposed algorithm said that 'counter' was incremented 
once when the FTP flow was started and incremented a second time when 
the WWW flow was started (or, a similar mechanism), then that would 
provide unique flow-label values for the two flows and, consequently, a 
unique 3-tuple of {src_ip, dst_ip, flow_label} to be used by 
intermediate routers.  As a result there is a high probability that 
intermediate routers would hash them onto different component-links in a 
LAG/ECMP and there is little risk of congestion.

-shane

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2010 21:30:07 +1300

Just to be crystal clear:

Fernando's algorithm is strictly compatible with RFC3697 and with the future
RFC3697bis (based on today's WG discussion). But it is compatible
with a policy that says "all simultaneous and overlapping
sessions between the same two IP addresses are treated as a single flow."

If you want to treat each new pair of sockets between those two
hosts as a separate flow, even when they overlap in time, you
need to include the whole 5-tuple. Or equivalently, generate a new
label with Fernando's algorithm each time there is a socket open() call.

If, in accordance with the draft we adopted today, the label is
created by a router, the only way to satisfy Shane's requirement
is to use the whole 5-tuple.

Regards
   Brian Carpenter

On 2010-11-09 21:16, Shane Amante wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Nov 2010 05:45:14 -0300

Hi, Shane,

Thanks so much for your feedback! -- Please find my comments inline....

> whole 5-tuple.  

Please define the specific scenario you're talking about.

> And, it means that I can't just use the 3-tuple of
> flow-label}.

No. "counter" will be different for each of the flows!

Please take a look at the table I referenced in my previous e-mail. It
clearly shows that in the scenario you're describing, the Flow Label
corresponding to each of the flows (FTP & WWW) would be different.

> the WWW flow was started (or, a similar mechanism),

Yes. This is what the document proposes.

> then that would

This is exactly what this document is proposing. Is there any particular
wording that is causing confusion?

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Nov 2010 05:52:49 -0300

Hi, Brian,

> sessions between the same two IP addresses are treated as a single flow."

Would this really make sense if we intend that the Flow Label be used
for ECMP/LAG?

> is to use the whole 5-tuple.

Shane's requirement == each 5-tuple gets a different "Flow Label"?

-- If that's the case, the router can still apply the algorithm
specified in draft-gont to achieve that.

Thanks!

Kind regards,

---

From: Shane Amante <[email-masked]>
Date: Tue, 09 Nov 2010 02:37:23 -0700

Hi Fernando,

On 11/9/2010 1:45 AM, Fernando Gont wrote:
> corresponding to each of the flows (FTP&  WWW) would be different.
>
>
>

The part that is confusing to me is *when* does an implementation run 
your pseudocode to fetch a new flow-label value?  If I look at the 
following pseudocode in the draft:
---snip---
         do {
             flowlabel = (offset + counter) % 1048576;
             counter++;

             if(three-tuple is unique)
                 return flowlabel;

            count--;

         } while (count > 0);
---snip---
... the way I read the above, when it runs it /will/ return a unique 
3-tuple of {src_ip, dst_ip, flow_label}.  However, it's /not/ clear 
*when* an implementation MUST execute the above pseudocode.

Based on the following text:
---snip---
    Considering that the Flow Label is a 20-bit field, and that Flow
    Label values must be unique for each (Source Address, Destination
    Address) pair at any given time, it might make sense to simply
    randomize the Flow Label value for each new flow.
---snip---
... in particular, the part that says: "Flow Label values must be unique 
for each (Source Address, Destination Address) pair", implementations 
would most definitely would read that as saying they only need to 
execute your pseudocode when they detect the existence of a new {src_ip, 
dst_ip} tuple.  IOW, they would /not/ run your pseudocode when the same 
{src_ip, dst_ip} tuple opens up several different sockets at the same 
time, where each socket connection would have a unique 5-tuple.

-shane

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Nov 2010 07:05:35 -0300

Hi, Shane,

> *when* an implementation MUST execute the above pseudocode.

... when you need to select a new FL. That is, when a new flow is
created. e.g., when a new TCP connection is to be established, or when a
new UDP socket is created.

> time, where each socket connection would have a unique 5-tuple.

Ok, I see your point, and will try to clarify this. -- I'm right now
heading to the social :-), but will post some proposed update sometime
later today (or tomorrow) for you to check and let me know whether it
addresses your concern.

Does this sound reasonable?

Thanks so much!

Kind regards,

---

From: Shane Amante <[email-masked]>
Date: Tue, 09 Nov 2010 06:29:44 -0700

Hi Fernando,

> new UDP socket is created.

[...]

> Does this sound reasonable?

That would be great.  I look forward to reading your proposed text. 
Thank you very much!

-shane

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 Nov 2010 10:42:07 -0300

Hi, Shane,

> That would be great.  I look forward to reading your proposed text.

Ok. Here's the text that I've included right bellow the formular:

---- cut here ----
This scheme should be used when a new flow is to be created (e.g., when
a new TCP connection is to be created). Once a Flow Label value for such
flow is selected, the Flow Label field of all the IPv6 packets
corresponding to that flow would be set to the selected value (until the
flow is terminated).
---- cut here ----

And I have also included this paragraph right bellow the pseudo-code:

---- cut here ----
This algorithm should be executed when a new flow is to be created
(e.g., when a new TCP connection is to be created). Once a Flow Label
value for such flow is selected, the Flow Label field of all the IPv6
packets corresponding to that flow would be set to the selected value
(until the flow is terminated).
---- cut here ----

Please let me know if this addresses your concerns.... (and if this
doesn't, please feel free to provide hints and/or text that would
address your concerns).

Thanks!

Kind regards,

---

From: Shane Amante <[email-masked]>
Date: Thu, 18 Nov 2010 21:59:12 -0700

Hi Fernando,

Thanks for responding.  See below.

> corresponding to that flow would be set to the selected value (until the

Upon further reflection, I think it would probably be best that your draft point toward the forthcoming RFC3697bis document, where the latter will normatively prescribe[1]:
a)  What constitutes a "flow" -- already in draft-carpenter-6man-flow-update-04 (Section 4); and,
b)  When new flow-labels are to be created -- possibly [more than] a bit vague in draft-carpenter; and,
c)  What 'uniqueness' characteristics there are with respect to flow-labels, e.g.: a source node SHOULD maintain unique flow-label values among a 5-tuple -- not in draft-carpenter from what I can tell or, at best, extremely vague.
... in order that we're not creating confusion between the two, (or more), different drafts/specs.  More specifically, I believe it would be good to ensure the properties list above, in (a) through (c), are (to the largest extent possible) common to avoid further ambiguity wrt the flow-label.

Specific to your draft, what would you say to replacing the text you have with the following:
---snip---
This scheme should be used to generate a new flow-label value at the time a new flow is created, (for instance, when a new transport connection is about to be established).  Please refer to RFC3697bis for the conditions that precipitate the generation of a new flow-label value.
---snip---

In addition, assuming you agree with this general direction, it would likely mean you could further simplify your draft by [eventually] eliminating the first few paragraphs in Section 3 draft-gont-6man-flowlabel-security, where you quote requirements from RFC 3697 as to a flow label's properties.  Instead, when a RFC 3697bis becomes available, you could most likely state something at the beginning of Section 3 like "Please refer to RFC3697bis with respect to the properties that constitute a flow-label value."  You could then continue with the existing discussion in your draft on how flow label reqmt's are similar to TCP port numbers, etc.

Thanks Fernando for your understanding.

-shane

[1] We probably need to revisit the language in draft-carpenter-6man-flow-update-04, Section 4, that will [likely] constitute a new RFC3697bis as to these three points.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Nov 2010 03:43:00 -0300

Hi, Shane,

Thanks so much for your feedback! -- Please find my comments inline...

>> ---- cut here ---- This scheme should be used when a new flow is to
>> be created (e.g., when a new TCP connection is to be created). Once
>> a Flow Label value for such flow is selected, the Flow Label field
>> of all the IPv6 packets corresponding to that flow would be set to
>> the selected value (until the flow is terminated). ---- cut here
>> ----
> 
> Upon further reflection, I think it would probably be best that your
> draft point toward the forthcoming RFC3697bis document, where the
> latter will normatively prescribe[1]:

IIRC, the Brian's I-D will aim at Informational, and only then ill it be
folowed by a formal revision of RFC 3697. -- that's why draft-gont
references RFC 3697 (the only normative specification so far). -- I
guess it could provide an Informational pointer to Brian's document to
provide hints about where things are going towards, though.

> a)  What constitutes a "flow"
> -- already in draft-carpenter-6man-flow-update-04 (Section 4); and, 
> b)  When new flow-labels are to be created -- possibly [more than] a
> bit vague in draft-carpenter; and, c)  What 'uniqueness'
> characteristics there are with respect to flow-labels, e.g.: a source
> node SHOULD maintain unique flow-label values among a 5-tuple -- not
> in draft-carpenter from what I can tell or, at best, extremely
> vague. ... in order that we're not creating confusion between the
> two, (or more), different drafts/specs.  More specifically, I believe
> it would be good to ensure the properties list above, in (a) through
> (c), are (to the largest extent possible) common to avoid further
> ambiguity wrt the flow-label.

You mean I should also describe the "requirements" in Brian's I-D?

> Specific to your draft, what would you say to replacing the text you
> have with the following: ---snip--- This scheme should be used to
> generate a new flow-label value at the time a new flow is created,
> (for instance, when a new transport connection is about to be
> established).  Please refer to RFC3697bis for the conditions that
> precipitate the generation of a new flow-label value. ---snip---

The only issue here is that, as mentioned above, there's no such thing
as RFC3697bis, yet. -- What if, say, I simply remove the example of
"e.g., when a new flow is created", and simply state that "the
definition of what a flow is is out of the scope of this document", or
the like?

What do others think?

> In addition, assuming you agree with this general direction, it would
> likely mean you could further simplify your draft by [eventually]
> eliminating the first few paragraphs in Section 3
> draft-gont-6man-flowlabel-security, where you quote requirements from
> RFC 3697 as to a flow label's properties.  Instead, when a RFC
> 3697bis becomes available, you could most likely state something at
> the beginning of Section 3 like "Please refer to RFC3697bis with
> respect to the properties that constitute a flow-label value."  You
> could then continue with the existing discussion in your draft on how
> flow label reqmt's are similar to TCP port numbers, etc.

You I could remove the requirements summary, and include pointers to RFC
3697 and Brian's I-D?

-- FWIW, I'm open to changes... just want to double-check that these
changes reflect wg consensus.

What do others think?

Thanks!

Kind regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Nov 2010 10:23:47 +1300

Fernando,

Well, one point is that there is surely no rush to publish your
draft, given the current level of usage of the flow label,
so we can take the time to ensure that the normative references
are correct in the end.

I have a list of things to do on the way to 3967bis, of which
the first one is moving house next week, so there will be a little
delay before the draft is revised according to the discussion
in Beijing.

Regards
   Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Nov 2010 23:41:56 -0300

> so we can take the time to ensure that the normative references

Agreed. - My thought was that it could be published along with 3697bis...

So I'd personally not work on the "requirements" section, particularly
because it needs to (and will) reflect what is included in 3697bis.

Thanks!

Kind regards,

---

From: Shane Amante <[email-masked]>
Date: Sat, 20 Nov 2010 02:47:19 -0700

Fernando,

> because it needs to (and will) reflect what is included in 3697bis.

To close out this thread ... it sounds like we have a general agreement/understanding on when draft-gont-6man-flowlabel-security will create new flow-label values, but we'll pause on updating it until RFC3697bis is out there and then we can make sure both drafts are appropriately aligned.

Thanks!

-shane