Subject: [Tsvwg] Fwd: More feedback on the part randomization draft (draft-ietf-tsvwg-port-randomization-00.txt)

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Dec 2007 12:03:32 -0300

Folks,

FYI, more feedback from the bugtraq folks.

Kind regards,
Fernando

>from    Matthias Bethke <[email-masked]>
>to      Fernando Gont <[email-masked]>,
>date    Dec 8, 2007 11:44 AM
>subject Re: TCP Port randomization paper
>mailed-by       gmx.net
>
>
>Hi Fernando,
>on Thu, Dec 06, 2007 at 07:45:04PM -0500, you wrote:
> > The document is available at:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-00.txt
>
>Just some minor notes on your paper that addresses a problem I've
>wondered for a while why it's still so often being implemented in the
>traditional manner :)
>
>- The pseudocode example for traditional linear ephemeral port selection
>  is mising the "--count;"
>- The indentation in the code could be misleading for someone wjho
>  doesn't know C well:
>|  next_ephemeral = min_ephemeral + random()
>|                                 % (max_ephemeral - min_ephemeral + 1);
>  This suggests bracketing like
>| (min_ephemeral + random()) % (max_ephemeral - min_ephemeral + 1)
>  which isn't what is meant, but you can only tell if you know the
>  operator precedence rules by heart.
>- There is a rather important difference between alg. 1 and 2 beyond the
>  longer search time you mention:
>  #3 may not produce a result even if there are free ports, in fact it's
>  rather unlikely it will find one if many ports are in use as it just
>  makes n random attempts to find one instead of a systematic search.
>  Maybe that was what you meant in 3.4 but as it says "the only
>  difference" in 3.2.2 I though't I'd mention it.
>  There are PRNGs guaranteed to cycle through all n possible values in
>  exactly n calls. I'm not sure how good their randomness is though
>  as I've only encountered them in graphics applications.
>- Such a PRNG would also provide the guaranteed lowest port reuse
>  frequency but I'm not sure this is what one wants. Unlike a completely
>  random port selection, an attacker could rule out already observed
>  port numbers in his guess of a next port.
>
>kind regards,
>        Matthias
>--
>I prefer encrypted and signed messages. KeyID: FAC37665
>Fingerprint: 8C16 3F0A A6FC DF0D 19B0  8DEF 48D9 1700 FAC3 7665

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