Subject: [Tsvwg] Fwd: RE: TCP Port randomization paper

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Dec 2007 10:10:24 -0300

Folks,

FYI, this is some feedback I got on 
draft-ietf-tsvwg-port-randomization-00 on the bugtraq mailing list.

Kind regards,
Fernando

>Subject: RE: TCP Port randomization paper
>Date: Tue, 11 Dec 2007 07:26:04 -0500
>From: "Amit Klein" <[email-masked]>
>To: "Fernando Gont" <[email-masked]>,
>         <[email-masked]>
>
>Hi Fernando+list
>
>I'm glad to see that someone takes aim at this issue.
>
>However, it seems that your proposal only 
>attempts to address one consequence of 
>predictable TCP source ports, namely blind TCP 
>attacks (in all fairness, it appears that the 
>object of your proposal is to solve the blind 
>TCP attacks, rather than the issue of 
>predictable TCP source ports; I look at it the 
>other way around...). Naturally this is a major 
>outcome, but there are still other consequences, 
>perhaps less severe, such as traffic analysis. 
>For example, the naïve (and as explained in your 
>draft, flawed) algorithm in Fig. 1 of your IETF 
>draft advances next_ephemeral globally. 
>Therefore, if the attacker can force the target 
>host to periodically establish a new TCP 
>connection to an attacker controlled machine (or 
>through an attacker observable routing path), 
>the attacker can subtract consecutive source 
>port values to obtain the number of outoing TCP 
>connections established globally by the target 
>host within that time period (up to wrap-around 
>issues and 5-tuple collisions, of course).
>
>However, note that algorithm #3 in your proposal 
>is also susceptible to the same technique.
>
>Algorithm #4 is affected as well, to some 
>degree. The "table" array compartmentalize the 
>space into TABLE_LENGTH sections. An attacker 
>can perform traffic analysis for any section 
>into which the attacker has "visibility", namely 
>that the attacker can force the server to 
>establish connection whose G(offset) points to 
>this section. The attacker has little control 
>over to which section exactly the host will map 
>the attacker's traffic, but once there, the 
>attacker can monitor traffic volumes (new 
>outgoing TCP connections) for this arbitrary section.
>
>Again, I don't know if this is in scope for your 
>draft, but I do believe that looking at the 
>generic problem here, this should be a factor.
>
>Thanks, and good luck,
>-Amit

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