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

Vern Paxson <> Fri, 22 April 2011 01:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25748E074D; Thu, 21 Apr 2011 18:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qzUvHkxyiSaU; Thu, 21 Apr 2011 18:52:54 -0700 (PDT)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 731AEE06E2; Thu, 21 Apr 2011 18:52:54 -0700 (PDT)
Received: from ( []) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6489536A36C; Thu, 21 Apr 2011 18:52:53 -0700 (PDT)
To: Catherine Meadows <>
In-Reply-To: <> (Thu, 21 Apr 2011 19:02:46 EDT).
Date: Thu, 21 Apr 2011 18:52:53 -0700
From: Vern Paxson <>
Message-Id: <20110422015253.6489536A36C@taffy.ICSI.Berkeley.EDU>
X-Mailman-Approved-At: Sat, 23 Apr 2011 08:08:33 -0700
Subject: Re: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Apr 2011 01:52:55 -0000

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

> 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.