Subject: [Tsvwg] Fwd: draft-larsen-tsvwg-port-randomization-00

From: Fernando Gont <[email-masked]>
Date: Sat, 10 Feb 2007 17:52:18 -0300

Folks,

We received this feedback for our draft 
draft-larsen-tsvwg-port-randomization-00.

We will be addressing these comments in the next 
revision of the draft, together with other 
feedback provided by Carlos Pignataro.

Any further comments on the draft will be greatly appreciated.

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
>Subject: draft-larsen-tsvwg-port-randomization-00
>To: [email-masked], [email-masked]
>Date: Wed, 10 Jan 2007 17:48:35 +0100 (MEZ)
>
>Hello,
>I've studied your I-D, draft-larsen-tsvwg-port-randomization-00,
>and found a few issues worth noting.
>
>
>(1)  algorithm flaws
>
>The stated algorithms do not exactly deliver what the text pretends.
>
>Section 2.2, Figure 1:
>
>       port = min_ephemeral + random() % (max_ephemeral - min_ephemeral)
>
>Taking 'min_ephemeral' and 'max_ephemeral' literally,
>the number of ephemeral ports isn't
>           max_ephemeral - min_ephemeral   ,
>it is:    max_ephemeral - min_ephemeral + 1     !!!
>
>For use below, take  num_ephemeral = max_ephemeral - min_ephemeral + 1
>
>Hence, *that* should be used as the modulus.
>
>Similar issues exist in 'Algorithm 1'  (Figure 2) and
>'Algorithm 2'  (Figure 3).
>
>Algorithm 1 adds "_port" to all "ephemeral" variables and constants;
>drop that in favor of the notation in Figure 1 & 3 !
>I'll omit "_port" generally below, for brevity.
>
>
>(2)  other sources of pseudorandomness
>
>At the end of Section 2.2, the draft states:
>
>    Note that on multiuser systems, the function F() could include user
>    specific information, thereby providing protection not only on a host
>    to host basis, but on a user to service basis.
>
>It would be easy to use the 'process ID' or a similar identifier
>of the software context here because it has a greater temporal
>variability, and hence a greater entropy.
>
>Also, a high resolution realtime clock could be used easily
>(or just the least significant part thereof, e.g. the fractions
>of seconds as available in Unix systems etc.); this is equivalent
>to extremely rapid rekeying, and would perhaps allow to avoid the
>use of the 'secret_key' at all.  (Beware, that ought to be kept
>secret -- a rather difficult job in practice!  The goal is ease
>of implementation; therefore this should be considered seriously.)
>
>
>(3)  Outdated Reference
>
>RFC 1750 has long been obsoleted by BCP 106, RFC 4086.
>Please changce all occurrences of [RFC1750] appropriately!
>
>
>(4)  Further ideas for algorithm improvement
>
>Saving 'last_ephemeral' instead of 'next_ephemeral' seems to be
>more natural, and it avoids to store somewhere a number of potential
>value for a Trojan or other Spyware.
>Additionally, IMHO, doing so would easily lead to a way to tackle the
>subtle matter of loop prevention the draft is so tacitly about 'til now.
>
>First sketch of modified Algorithm 1 (1bis) :
>
>     last_ephemeral = min_ephemeral ;   // state variable
>
>     port_t get_ephemeral ( ... ) {
>
>       port_t port = last_ephemeral ;
>
>       do {
>           if ( port == max_ephemeral ) {
>               port = min_ephemeral ;
>           } else {
>               port++ ;
>           }
>       } until ( port == last_ephemeral || (four-tuple is unique))
>
>       if ( port == last_ephemeral ) {
>           return ERROR ;
>       } else {
>           last_ephemeral = port ;
>           return port ;
>       }
>
>First sketch of a variant (2bis) of Algorithm 2 , using internally
>port numbers offset by  -min_ephemeral, and assuming  F() != 0 :
>
>     last_ephemeral = 0 ;   // state variable -- truly: a port offset
>
>     port_t get_ephemeral ( ... ) {
>
>       port_t port ;
>       port_t portdif = last_ephemeral ;
>       port_t offset  = F ( ... ) ;
>
>       do while () {
>           portdif = ( portdif + offset ) % num_ephemeral ;
>           if ( portdif == last_ephemeral ) {
>               return ERROR ;
>           } else {
>               port = min_ephemeral + portdif ;
>               if ( four-tuple with port is unique) break ;
>           }
>       }
>       last_ephemeral = portdif ;
>       return port ;
>     }
>
>Algorithm 1bis is exhaustive.  Contrary to that,
>Algorithm 2bis might miss an available four-tuple if
>              gcd ( offset, num_ephemeral ) != 1
>
>Another variant (2ter) of Algorithm 2 , using internally
>port numbers offset by  -min_ephemeral :
>
>     last_ephemeral = 0 ;   // state variable -- truly: a port offset
>
>     port_t get_ephemeral ( ... ) {
>
>       port_t port ;
>       port_t portdif = ( last_ephemeral + F(...) ) % num_ephemeral ;
>       port_t test_ephemeral = portdif ;
>
>       do while () {
>           if ( portdif == num_ephemeral ) {
>               portdif = 0 ;
>           } else {
>               portdif++ ;
>           }
>           if ( portdif == test_ephemeral ) {
>               return ERROR ;
>           } else {
>               port = min_ephemeral + portdif ;
>               if ( four-tuple with port is unique) break ;
>           }
>       }
>       last_ephemeral = portdif ;
>       return port ;
>
>That's exhaustive again, but less elegant, and it doesn't spread
>so well the port numbers returned.
>
>
>Best regards,
>   Alfred HÎnes.
>
>--
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
>| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
>| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
>+------------------------+--------------------------------------------+

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