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

From: Lars Eggert <[email-masked]>
Date: Wed, 23 Jan 2008 17:53:43 +0200

Hi,

thanks for submitting an update of the port randomization draft as a  
-00 WG document. However, looking at a diff between the last  
individual version and the new -00 WG version, not all comments seem  
to have been addressed. My earlier email was summarizing some of them:

On 2007-10-3, at 3:15, ext Lars Eggert wrote:
> You should also review the comments that have been made on the list  
> and incorporate them into the revision. For example, several people  
> suggested that the document should more prominently recommend one  
> randomization scheme (or a small number of alternatives). The  
> analysis of the pros and cons of currently implemented schemes that  
> is the bulk of the current document should maybe become an  
> informative appendix.

The document is still very much discussing a number of different  
options without making a clear recommendation. Please consider  
restructuring the text such that it briefly outlines the desired  
characteristics of a port randomization scheme, followed by a detailed  
description of the approach suggested as an IETF recommendation. A  
description of other possible schemes could follow, or be moved to an  
appendix. In other words, one scheme should be a SHOULD, and zero or  
more others may be MAYs.

As for which option to recommend - assuming there is no clear winner  
from a security point of view - it would probably be useful if we'd  
pick something that at least some of the major stacks already  
implement. The survey of open source stacks seems to hint at option 2,  
but I'd like to know what Windows, MacOS and some other commercial  
stacks implement before we settle on that.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Jan 2008 16:07:02 -0200

At 01:53 p.m. 23/01/2008, Lars Eggert wrote:

>options without making a clear recommendation.

My take was that this was the WG feeling. Earlier versions 
recommended the hash-based approach. But we got feedback (e.g., from 
Mark Allman) that the doc would be better off discussing the pros and 
cons of the different approaches, without pushing any particular 
randomization scheme. That is, it was my intention to make changes in 
the draft so that it did not make any clear recommendation. (As far 
as *I* am concerned, I would recommend the hash-based approach).

However, if you consider it appropriate, I will proceed as you suggest bellow:

>Please consider

Ok, will do.

>implement.

Consider both security and interoperability, my take is that the 
hash-based approach is the best. And, FWIW, the hash-based approach 
is implemented in Linux (and I'm planning to submit a patch for 
FreeBSD that implements this approach, too).

>The survey of open source stacks seems to hint at option 2,

Windows (at least till XP) does not implement port randomization. It 
implements the traditional BSD incremental approach. Not sure what 
MacOS does, but I would expect them to implement the traditional BSD 
scheme, too.

Kind regards,

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

---

From: Mark Allman <[email-masked]>
Date: Fri, 25 Jan 2008 09:01:49 -0500

> appendix. In other words, one scheme should be a SHOULD, and zero or

Why do we need a SHOULD in this space?  The set of algorithms have
tradeoffs.  Let people make their own tradeoffs.  This is an internal
TCP issue, not something TCPs have to agree on.  So, why do we need to
get to consensus on which option people should use unless there is a
very clear line between "good" and "bad" (which my sense is there is not
because it all depends on how paranoid you want to be, how much state
you are willing to keep, etc.).

allman

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Jan 2008 19:25:08 -0200

>you are willing to keep, etc.).

FWIW, one issue that was recently raised in another list (which IIRC 
I forwarded here) is that all algorithms which result in an 
incremental sequence can be "exploited" to get an idea about the 
number of outgoing connections the client performs. In, this respect, 
the "completely ramdom approach" (rather than the hash-based 
approach) would be slighlty "safer".

IMHO, the benefits of the hash-based approach outwheigh those of the 
"completely-random" approach. That's why the previous version of the 
draft argued in favor of that approach over the others (well, also 
because Michael's original version of the draft only described the 
hash-based approach).

But I do agree with you that the "SHOULD" could be limited to "SHOULD 
randomize the selection of ephemeral ports", and that the 
randomization scheme might be left up to the implementation. (That 
is, the draft would limit itself to recommending port randomization 
and discussing the pros and cons of each scheme).

As far as I am concerned, I just wonder how to proceed with the draft 
(should we keep it as is? should we switch back to recommending the 
hash-based approach (or recommending any other specific scheme)?)

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Mon, 28 Jan 2008 09:51:36 +0200

Hi,

> you are willing to keep, etc.).

I agree with you that maybe a single SHOULD is too narrow, given that  
several algorithms fullfil the requirements a randomization schemes  
needs to have. I'm fine with recommending a small number of  
algorithms, and maybe even saying that "anything else that similarly  
fullfils the requirements MAY be implemented."

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.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Jan 2008 06:38:24 -0200

>seem to be more appropriate.

How about something along the lines of "transport protocols SHOULD 
implement ephemeral port randomization", and recommending a few 
alternatives for port randomization (hash-based, "completely-random", etc.)?

Thanks,

---

From: Lars Eggert <[email-masked]>
Date: Mon, 28 Jan 2008 10:43:26 +0200

> alternatives for port randomization (hash-based, "completely- 

That's a good suggestion, but I'd like the document to define  
"ephemeral port randomization" in a bit more detail, i.e., say which  
features of a randomization algorithm are desirable and which ones  
aren't.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Jan 2008 06:50:17 -0200

At 06:43 a.m. 28/01/2008, Lars Eggert wrote:

>>alternatives for port randomization (hash-based, "completely- random", etc.)?
>

Yea, that was in the queue of changes for the next revision 
(already), along with some changes proposed by some folks from 
full-disclosure and other mailing lists.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Mon, 28 Jan 2008 08:54:13 -0500

> 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