Re: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02

[Vern Paxson <[e-mail]>]

Here are some comments on the points you raise:

> how hard is it to spoof an acknowledgement?

It requires essentially the same level of information as is needed to
inject data into an established TCP connection.  For modern TCPs, this is
viewed as quite difficult, due to the widespread randomization of initial
sequence numbers.

> What information would the attacker need to know about the packets in
> the connection?

The sequence numbers in both directions, as well as the port numbers.
There's some slop possible for the sequence numbers (they need to be within
the advertised window, per page 26 of RFC 793), but the search space here
for blind spoofing is large.

> If the sender backed off once a packet was genuinely lost, how hard would
> it be for the attacker could bring the RTO down again?

Quite difficult if they are off-path.  This requires that they anticipate
exactly when the sender will send *new* data (can't be a retransmission,
since those aren't used to recompute RTO) and then send a bogus ACK very
shortly after.

If the attacker is on-path *and* near the sender, then they can manipulate
the sender readily.  However, it's very difficult for an attacker to be
near a *lot* of attackers.

If the attacker is on-path but not near, then they can likely at best
manipulate the RTO towards the RTT between the attacker and the sender.
They can do better if they can guess future transmissions with exceptional
accuracy.

> What if the attacker were applying this attack to multiple senders.  Are
> there cases in which an attacker could spoof an acknowledgement without
> having actually have seen a packet?

Per the above, this is presumed very difficult to achieve today.  If it
weren't, then we are in much deeper trouble due to the ability of attackers
to inject data rather than simply manipulate RTO estimates.

		Vern