Subject: [tsvwg] Port randomization RFC

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 5 Nov 2015 04:16:00 +0000

Lucy, as I just said I think you can simply refer to RFC6056.

https://tools.ietf.org/html/rfc6056

Lars

---

From: Tom Herbert <[email-masked]>
Date: Thu, 5 Nov 2015 13:35:22 +0900

> https://tools.ietf.org/html/rfc6056
Lars,

GRE/UDP (and all the other UDP encapsulations) are not selecting
source port numbers in the usual sense. The source port is chosen to
reflect the flow based of the packet being encapsulated, e.g. by a
hash over 4-tuple. This is needed to support ECMP mechanisms that work
by hashing over the 4-tuple.The salient properties are that this is a
stateless selection algorithm and always gives the same answer for a
flow going through a device. (also have a uniform distribution,
initialized with random hash key, etc.). There is no requirement that
two encapsulated flows map to different 4-tuples in the outer
encapsulation.

Tom

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 5 Nov 2015 04:43:05 +0000

> two encapsulated flows map to different 4-tuples in the outer

It's late in the week so I am getting stupider. Are you saying doing things according to RFC6056 won't work here, or are you saying it's overkill?

Thanks,
Lars

---

From: Tom Herbert <[email-masked]>
Date: Thu, 5 Nov 2015 13:58:23 +0900

> It's late in the week so I am getting stupider. Are you saying doing things according to RFC6056 won't work here, or are you saying it's overkill?

I think RFC6056 is about selecting a source port for traditional
transport protocol communications. For encapsulation, the source port
selection algorithm for source port entropy would loop free.
Essentially the simplest algorithms looks like:

port = HASH(inner_src, inner_dst, inner_sport, inner_dport) %
(max_ephemeral - min_ephemeral) +  min_ephemeral

The other way to think of this is that the source port is being using
as type of flow label. For instance the algorithm in Appendix A of
RFC6437 could be applied (deriving a 14 bit value instead of a 20 bit
one).

Thanks,
Tom

---

From: Lucy yong <[email-masked]>
Date: Thu, 5 Nov 2015 05:40:04 +0000

Thank Tom to clarify it. The requirement applies to the flow entropy value that SHOULD be in range of UDP ephemeral port. This is not about how to select a number for UDP src port.

We will tweak the text to make that clear.

Lucy Yong 

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2015 10:58 PM
To: Eggert, Lars
Cc: Lucy yong; [email-masked]
Subject: Re: [tsvwg] Port randomization RFC

On Thu, Nov 5, 2015 at 1:43 PM, Eggert, Lars <[email-masked]> wrote:
>> hash over 4-tuple. This is needed to support ECMP mechanisms that 
>> work by hashing over the 4-tuple.The salient properties are that this 
>> is a stateless selection algorithm and always gives the same answer 
>> for a flow going through a device. (also have a uniform distribution, 

I think RFC6056 is about selecting a source port for traditional transport protocol communications. For encapsulation, the source port selection algorithm for source port entropy would loop free.
Essentially the simplest algorithms looks like:

port = HASH(inner_src, inner_dst, inner_sport, inner_dport) % (max_ephemeral - min_ephemeral) +  min_ephemeral

The other way to think of this is that the source port is being using as type of flow label. For instance the algorithm in Appendix A of
RFC6437 could be applied (deriving a 14 bit value instead of a 20 bit one).

Thanks,
Tom