Fernando Gont
12/12/07, 17:16
Hello, Amit,
> However, it seems that your proposal only attempts to address one consequ=
ence 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 th=
e 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 traf=
fic analysis. For
> example, the na=EFve (and as explained in your draft, flawed) algorithm i=
n Fig. 1 of your IETF
> draft advances next_ephemeral globally. Therefore, if the attacker can fo=
rce 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 c=
onsecutive source
> port values to obtain the number of outoing TCP connections established g=
lobally 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 t=
he same technique.
Good point, too.
> Algorithm #4 is affected as well, to some degree. The "table" array compa=
rtmentalize the
> space into TABLE_LENGTH sections. An attacker can perform traffic analysi=
s for any
> section into which the attacker has "visibility", namely that the attacke=
r can force the
> server to establish connection whose G(offset) points to this section. Th=
e attacker has
> little control over to which section exactly the host will map the attack=
er's traffic, but
> once there, the attacker can monitor traffic volumes (new outgoing TCP co=
nnections) 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
> However, it seems that your proposal only attempts to address one consequ=
ence 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 th=
e 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 traf=
fic analysis. For
> example, the na=EFve (and as explained in your draft, flawed) algorithm i=
n Fig. 1 of your IETF
> draft advances next_ephemeral globally. Therefore, if the attacker can fo=
rce 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 c=
onsecutive source
> port values to obtain the number of outoing TCP connections established g=
lobally 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 t=
he same technique.
Good point, too.
> Algorithm #4 is affected as well, to some degree. The "table" array compa=
rtmentalize the
> space into TABLE_LENGTH sections. An attacker can perform traffic analysi=
s for any
> section into which the attacker has "visibility", namely that the attacke=
r can force the
> server to establish connection whose G(offset) points to this section. Th=
e attacker has
> little control over to which section exactly the host will map the attack=
er's traffic, but
> once there, the attacker can monitor traffic volumes (new outgoing TCP co=
nnections) 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