Bugtraq mailing list archives
Re: TCP Port randomization paper
From: "Fernando Gont" <fernando.gont () gmail com>
Date: Tue, 11 Dec 2007 20:15:48 -0300
Hello, Amit,
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...).
Not really. While the motivation of the draft was motivated by the blind attacks that received some attention in the last few years, it's not necessarily limited to addressing blind attacks. The draft does mention (and provides references to) blind attacks because they have received some attention during the last few years, and because the IETF has ongoing work on those issues. But I think the issues you raise are well within the scope of our draft.
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).
Good point. I will try to add some text about this issue in the next revision of the draft.
However, note that algorithm #3 in your proposal is also susceptible to the same technique.
Good point, too.
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.
Well, I guess this is the point at which an engineering decision is made. I mean, if one is concerned with traffic analysis, then make TABLE_LENGTH as large as possible. e.g., with only 2KB of memory, you could compartmentalize the port sapce into 1024 sections.
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.
Agreed. I will try to address the issues you raised in the next revision of the draft. Thanks! Kind regards, Fernando Gont
Current thread:
- TCP Port randomization paper Fernando Gont (Dec 07)
- Message not available
- Re: TCP Port randomization paper Fernando Gont (Dec 12)
- Message not available
- <Possible follow-ups>
- RE: TCP Port randomization paper Amit Klein (Dec 11)
- Re: RE: TCP Port randomization paper Amit Klein (Dec 18)