Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-port-randomization-00.txt

From: Joe Touch <[email-masked]>
Date: Mon, 04 Feb 2008 06:45:44 -0800

Why not make it BCP? This doesn't spec a change that both ends need to
coordinate, or even a change that affects the protocol itself anyway.

Joe

Mark Allman wrote:
|> But for a PS document, I think there needs to be a recommendation
|> made. Otherwise, if this is only to be a survey, Informational would
|> seem to be more appropriate.
|
| I didn't know (or had forgotten) that this was tracked as PS.  I am not
| sure what I think about that.  I look at this sort of like the syn
| cookies document (informational), since it is about an internal
| implementation function.  If going PS means we have to pick one
| algorithm then I think we should go informational.  We may all have our
| leanings about which algorithm is "best", but it seems to me that these
| algorithms are all similar enough and provide the same sorts of
| high-order protection that picking *one* is going to be both tough and
| useless.  I don't think that is something the IETF should spend energy
| on.
|
| I think Fernando's notion of saying port randomization SHOULD be done in
| some fashion and then simply sketching the ways it could be done is
| fine.  I like Lars' added notion that providing a small framework for
| what constitutes a reasonable solution to this problem is fine, too.
|
| allman
|
|
|
|

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Feb 2008 16:54:56 +0200

> coordinate, or even a change that affects the protocol itself anyway.

Sounds reasonable, especially if we aren't recommending one specific  
algorithm but instead are recommending a set of properties that an  
algorithm should have.

Lars

---

From: Mark Allman <[email-masked]>
Date: Mon, 04 Feb 2008 09:56:27 -0500

> algorithm but instead are recommending a set of properties that an

Yep.  If the "randomize ports, please" is the BCP and not the exact
method for doing it then I'd be in favor of that path.

allman

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Feb 2008 18:08:59 +0200

> method for doing it then I'd be in favor of that path.

OK, so to wrap this thread up: I understand the WG consensus to be to  
change the "Intended Status" of the next revision to BCP, and re-focus  
the main part of document on what the desired properties of a port  
randomization scheme are. A separate section can then informally  
present several concrete examples that have all or at lerast most of  
the desired properties. Ideally, these examples are based on what  
current stacks already implement.

Fernando, is this clear? Do you think you can revise the document  
before the cutoff?

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2008 20:32:19 -0200

At 02:08 p.m. 20/02/2008, Lars Eggert wrote:

>randomization scheme are.

Two comments on this issue:

* The revised draft should make a statement such as "TCP 
implementations SHOULD randomize their ephemeral port numbers" or the like?

* I'm still meaning to perform some tests with each of the algorithms 
described. My take is that the hash-based algorithm leads to less 
collisions, and would like to get some real numbers on this issue. If 
that's the case, then std track (instead of bcp) might be a better 
path. Would it be appropriate to delay the std track -> bcp change till then?

>Fernando, is this clear? Do you think you can revise the document

Yes, sure.

Thanks,

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 21 Feb 2008 13:25:04 +0200

Hi,

> implementations SHOULD randomize their ephemeral port numbers" or  

I think it should - it's a document that says "the best current  
practice with regards to selecting port numbers is to randomize them  
with a scheme that has these properties..."

> * I'm still meaning to perform some tests with each of the  
> algorithms described. My take is that the hash-based algorithm leads  
> to less collisions, and would like to get some real numbers on this  
> issue. If that's the case, then std track (instead of bcp) might be  
> a better path. Would it be appropriate to delay the std track -> bcp  
> change till then?

We can always change it back to a PS later, if your planned evaluation  
of the various schemes convinces the WG that one is significantly  
better than the others. (Aside: I'm not convinced that "fewer  
collision" is a meaningful metric for that.) But until then, please  
make the changes that the WG has come to consensus on.

Thanks,
Lars