Re: [tcpm] tcp-auth-opt issue: replay protection

"Adam Langley" <> Wed, 30 July 2008 23:10 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id ADF003A6978; Wed, 30 Jul 2008 16:10:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3E4F3A67AC for <>; Wed, 30 Jul 2008 16:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EikMemtEswns for <>; Wed, 30 Jul 2008 16:10:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA4293A6978 for <>; Wed, 30 Jul 2008 16:10:03 -0700 (PDT)
Received: by with SMTP id b25so227349rvf.49 for <>; Wed, 30 Jul 2008 16:10:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=5dadFRnnEXo4a91ku1I38dFtq7onaIYdMj6JRWpJtUw=; b=TZokf/NKSiu6DnM5+e2eymE4U07uzsEsspJ6ey1bTBb1Kf+/iCREJ4+2ITjM0UeLnm V+36Hv/Va6l+eULcLbhgAErRxIDBtXvvrdk3iv/AwLYOcfUgCH8nJocRmxvmVpTcpUxt OcEz9Ycbh2emRky3BQsYz27Sl8z0ROjSHtZD4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=EZ1ecA1DuLfO+jIJG1i5LBNvy6LP/P77I+JL6dK9AXa0Em5qOvx28hrLvyfZaO2JpR ou4RVJo7pNy/z+mrlLcZuC219F1nsR0jXVsGVSZgZ0YXa6KcfgvX5CjVuIPPmeT/ptRq OvQZ/N0lGZNos2oHiTkTgxAS4lxrknA997E38=
Received: by with SMTP id u15mr4911639rvn.51.1217459419601; Wed, 30 Jul 2008 16:10:19 -0700 (PDT)
Received: by with HTTP; Wed, 30 Jul 2008 16:10:19 -0700 (PDT)
Message-ID: <>
Date: Wed, 30 Jul 2008 16:10:19 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <> <> <> <> <>
X-Google-Sender-Auth: e83daff6be10c75d
Subject: Re: [tcpm] tcp-auth-opt issue: replay protection
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Wed, Jul 30, 2008 at 3:22 PM, Joe Touch <> wrote:
> 1. assume the key management system (KMS) will rollover the keys every
> 2^31 bytes
>        Eric noted this is weak, since we cannot rely on the KMS
>        to act on this without other info. Let's presume this
>        is unacceptable to the WG and move on...

I don't really like this solution, but I don't think it's too bad.
Here's what my test impl's currently do:

Each direction has a TX key and two valid RX keys configured. From the
point of view of a sending application, which keeps track of the
number of bytes sent:
  If I'm just about to cross a 2**31 bytes boundary, install the next TX key.

This means that retransmissions of some bytes with seq numbers less
than the boundary get the new key, but that's not a huge problem.

On the receiving side (for a given half-connection):
  From the current number of bytes received (n), ensure that keys for
n - 2**30 and n + 2**30 are installed as valid RX keys.

This ends up meaning that RX keys are rotated ever 2**31 bytes with a
2**30 byte phase.

This is fine so long as the window is < 2**31 bytes (which is defined
by the window scaling spec at the moment)

> Given that algorithm, every ESN increment would trash data in transit
> from A-B. Is there an algorithm that does not do this?

This seems an odd ESN to me:

The ESN is just a 64-bit sequence number. The SEQ field in the TCP
header is just the lower 32-bits of this counter. Thus, for the
half-connection from A to B, A knows the ESN exactly for every packet.
For a packet recved by B, it guesses the ESN based on the closest
value to it's last understanding. An example for B:

At the beginning of the connection, B knows the ESN for the A->B half
connection exactly: top 32-bits are 0, bottom 32-bits from the
For each packet recved it gets the low 32-bits of the ESN, now assume
that that the ESN is the closest of the 2**32 possible ESN's to the
previous value of the ECN.
Update the previous value with this new guess.

This is very easy code.

Any packets which are reordered > 2**32 sequence bytes will be
misclassified and dropped, but 2**32 sequence bytes is a long way.


Adam Langley
tcpm mailing list