Subject: Re: Preliminary report on flow label hash algorithms

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Jun 2011 15:52:33 -0300

On 06/01/2011 02:13 AM, Brian E Carpenter wrote:
> In summary: the algorithm suggested in the Appendix to
> draft-ietf-6man-flow-3697bis-04 doesn't perform very well
> on real packets, and I have an improved version to suggest.

Sorry if I'm missing something: Any reasons for which you chose a
different algorithm from the one described in
draft-gont-6man-flowlabel-security?

The algorithm in the aforementioned I-D has already been well tested for
randomizing TCP port numbers, timestamps, and sequence numbers. -- and I
don't think there's a real need to reinvent the wheel.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jun 2011 10:09:03 +1200

Fernando,

My to-do list included running your algorithm against the
same datasets. However, I just looked at your draft again and
it seems to be underspecified - you do not define what functions
F and G are. And I think it's stateful, because of the statement
"if(three-tuple is unique)".

All we are discussing is a non-normative suggested algorithm,
so this is not critical for the draft to go forward IMHO.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Jun 2011 20:19:37 -0300

Hi, Brian,

On 06/01/2011 07:09 PM, Brian E Carpenter wrote:
> F and G are.

To some extent, this was intentional. -- Although I do agree I should
have noted (non-normatively) that MD5 would be a good choice for F().

As for G(), one could use MD5(), or even something simpler.

> And I think it's stateful, because of the statement

Not sure what you mean. The specs themselves argue that a flowid
shouldn't be reused if it's already in use. So one could envision that
the flowid used for a communication instance is stored in the
corresponding TCB, and that's how it is checked.

Anyway, the same algorithm could be used without performing that check,
and simply having faith in the algorithm on the fact that collisions
will not occur. :-)

> so this is not critical for the draft to go forward IMHO.

It looks like such an algorithm would belong to a separate document --
particularly if the suggestion is going to be "non-normative". i.e., a
separate document could evaluate different algorithms, in a similar way
we have done so for transport protocol port number randomization.

-- BTW, still wondering what could be a sensible way forward for
draft-gont-6man-flowlabel-security.

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Jun 2011 12:01:24 +1200

> As for G(), one could use MD5(), or even something simpler.

OK.

> shouldn't be reused if it's already in use. 

That was RFC3697. RFC3697bis is more relaxed about this point, because
it isn't an essential property for load balancing. If uniqueness
is a hard requirement, you're definitely forced into a stateful
model, but that is out of scope for 3697bis.

> So one could envision that

Or that they don't matter too much...

> we have done so for transport protocol port number randomization.

Yes, the topic is quite complex and I can think of many more tests I
could run, if my time was infinite. All we really need for now is a
not-completely-lame algorithm as an illustration for 3697bis.

> draft-gont-6man-flowlabel-security.

What I have learnt doing these tests is that it's complex (as noted)
and maybe it's too soon to know the best approach.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jun 2011 07:48:52 +1200

A small update on this:

1. David Malone found a bug in my C code, which changes the conclusion.
Of the algorithms I tried, the one designated #2 apparently performs best
of the three, once the bug is fixed. I can't complete the tests and post
an updated report until mid-July, due to travel.

2. From the feedback I've received, it's clear that there is great scope
for experimenting with various algorithms to find the best one. Assuming
we leave an example algorithm in the draft, the text needs to make this
clear. We can wait for the Area Director's review before deciding what
to do about this.

Regards
   Brian

On 2011-06-01 17:13, Brian E Carpenter wrote:
> This doesn't affect the normative text in the draft, so I
> believe it can be fixed.
> 
> The full story, with fonts, tables and pictures:
> 
> http://www.cs.auckland.ac.nz/~brian/flowhash.html
>