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
