Subject: [Tsvwg] Proposed changes for the port randomization draft

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 01:24:04 -0300

Folks,

I have tried to sum-up some of the changes that have been proposed, 
so that we can get input on these specific issues, and move the doc forward

#1: Document title
The current document title is "port randomization". As discussed on 
the list, this is a misnomer. Should we change it?
Possible alternatives could be:
a) "Port obfuscation"
b) "Ephemeral port obfuscation"
c) "On the obfuscation of ephemeral port numbers"
d) Leave the title "as is"

#2: Noting that randomization algorithms will usually lead to more 
collisions than sequential algorithms.
I plan to include a note on this (there's a really small comment in 
bullet #3 bellow). If you have any suggestions or objections :-), 
please yell. :-)

#3: TIME-WAIT issues
I'd be incorporating this text, that is based on text send (off-list) 
by Mark (expect for the last apra):
---- cut here ----
    The port selection algorithms sketched in this document (the 
non-sequential ones, in particualr)
    can result in collisions of the connection-id that could degrade
    the performance of connection startup. Retaining to the TIME-WAIT 
state on the
    client-side  to also keep track of the terminated connection for 
2*MSL after the
    connection is finished can help to avoid these collisions and 
thus eliminate the problem.
    In this way the host can ensure future ephemeral port selections 
will not collide
    with connections still in TIME-WAIT on the remote host (provided 
there are still connection-id's
    in the CLOSED state).  We do not specify how such state should be 
kept or even that it
    needs to be kept.  We simply note that some of the algorithms 
described in this document may
    produces collision-rates that may be deemed too great to depend 
on probabilistic mechanisms
    to prevent collisions.

    A number of stacks have implemented heuristics on the ISNs of new 
connection-requests to allow
    the creation of new incarnations of previous connections that 
were in the TIME-WAIT state [RFC793]. Other
    stacks have implemented the same type of heuristics with the TCP 
Timestamps option.
    [draft-gont-tcpm-tcp-timestamps].
---- cut here ----

#4: I will also include a pointer to (Faber, Touch, Yue, Infocom 
1999) and RFC 1337 somewhere as a pointer toa  discussion of the 
TIME-WAIT issues.

Please comment on the above specific changes....

Thanks!

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: Wed, 12 Nov 2008 08:37:40 -0500

> so that we can get input on these specific issues, and move the doc

I sent a whole list of comments a while back.  A bunch of them were just
editorial stuff.  But, the bigger issues are that algorithms 3 & 4 are
underspecified in that they are missing hash algorithm recommendations
and/or table size recommendations.

But, really, I'd just suggest looking at my email from Sep/8.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 10:39:30 -0300

>But, really, I'd just suggest looking at my email from Sep/8.

All of your proposed changes are already in the pipeline (I am 
already working on them). I was just asking about the last changes 
that were proposed on-list.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Nov 2008 10:18:52 -0800

Fernando Gont wrote:
> Folks,
> 
> I have tried to sum-up some of the changes that have been proposed, so
> that we can get input on these specific issues, and move the doc forward
> 
> #1: Document title
> The current document title is "port randomization". As discussed on the
> list, this is a misnomer. Should we change it?

See my other note on this. I think describing this in direct relation to
RFC 1948 is a win, including playing on its title.

> bullet #3 bellow). If you have any suggestions or objections :-), please
> yell. :-)

That sounds sufficient.

> #3: TIME-WAIT issues
> I'd be incorporating this text, that is based on text send (off-list) by
> Mark (expect for the last apra):
> ---- cut here ----
>    connection is finished can help to avoid these collisions and thus
> eliminate the problem.
>    In this way the host can ensure future ephemeral port selections will
> not collide
>    produces collision-rates that may be deemed too great to depend on
> probabilistic mechanisms
>    to prevent collisions.
> 
>    the creation of new incarnations of previous connections that were in
> the TIME-WAIT state [RFC793]. Other

That sounds fine.

> #4: I will also include a pointer to (Faber, Touch, Yue, Infocom 1999)
> and RFC 1337 somewhere as a pointer toa  discussion of the TIME-WAIT
> issues.

Sure; I'd also include RFC 1948 in the intro rather than just the
acknowledgments.

Joe