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

"Adam Langley" <> Thu, 31 July 2008 17:10 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id D9EBC3A6CD4; Thu, 31 Jul 2008 10:10:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C15AB3A6915 for <>; Thu, 31 Jul 2008 10:10:13 -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 VwGUpgt1N61W for <>; Thu, 31 Jul 2008 10:10:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7AD5C3A6D00 for <>; Thu, 31 Jul 2008 10:10:05 -0700 (PDT)
Received: by with SMTP id b25so564943rvf.49 for <>; Thu, 31 Jul 2008 10:10:22 -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=wOPoXApTGHuPeiKJFtSjHYuFUa8OzXnaytBcPOa9GE0=; b=UgXq7k5SASo2MMZm2qy+KPr4Q3mck5e/GkCYJRSbcQE69BW5TYUWLQhBkLD62sZcJK VBDBjS8W0rvyst5Tgdhhg/SEeaMrfyy5QboUPd630RFdweUPzQY44It4hfZJ540DJcaO 3FwY70hTqTh/7ikUnAa4k9Mx5d1bnJNdW3i64=
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=MyYyOmyoiOFcbw3rWpIigI29eYFq+NhP1DqKAicqMhN1fMD4oWNZs0SjGKgcJXheaG s+RVKD3lIA0D2gxxfzfWCe1O/sGQPu/8aafW5Ix91rRUiuhp9K6p3ZDZ52OwG9b9lfER rn889hrlxHfV6IkDuEh5kbA7ZawOr8QQO0Qts=
Received: by with SMTP id v5mr5422435rvj.216.1217524222820; Thu, 31 Jul 2008 10:10:22 -0700 (PDT)
Received: by with HTTP; Thu, 31 Jul 2008 10:10:22 -0700 (PDT)
Message-ID: <>
Date: Thu, 31 Jul 2008 10:10:22 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <> <> <> <> <>
X-Google-Sender-Auth: 143e94cd761a3dad
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 Thu, Jul 31, 2008 at 1:20 AM, Joe Touch <> wrote:
> <individual hat on>
> My goal was to allow TCP-AO code to be isolated to handling packets just
> before exit/entrance to IP. That suggests that all TCP-AO state should
> be kept to the TSAD, and not extend the core TCP code unless absolutely
> necessary.

Speaking for the Linux stack, the current MD5 code filters at the
entry to the TCP layer since it needs to be near the options parsing
code etc. At that point, we have found a socket and thus have a locked
tcp_sock structure. So adding the ESN would involve adding a couple of
u32's to the tcp_sock structure (they would store the upper 32-bits of
the RX and TX ESNs).

> A separate question is whether ESN rollover should use the keyID
> mechanism or not. This is related to Eric's points:

Personally, my feeling is that it shouldn't.

> | So, two salient points:
> | 1. When the sequence number is in the region of 0 (more precisely
> |    while there are unacked segments on both sides of the region),
> |    then the sides must maintain two keys and arrange to use
> |    the appropriate one.
> Eric - can you explain "arrange to use the appropriate one"?

I believe Eric is discussing the case where the keys change because of
a rollover. Since packets may be reordered, a host past to remember
both the keys for the previous period and the keys for the current
period in case a reordered packet comes in. It's unclear, to me, which
key retransmitted packets would use.

> | 2. The same key-id is used in the packet regardless of the which
> |    key is being used to protect the traffic. It refers to the
> |    static key from which the traffic keys were diversified.
> Eric - can you explain where the multiple keys per keyID are determined?
> i.e., are they recomputed per-packet or kept somewhere?

It appears that they are computed when a connection becomes
ESTABLISHED and rotated once every rollover from then.

> <individual hat on>
> FWIW, I agree with Eric's example on the wire; the issue is the state
> required at the endpoints required to make it happen.
> <individual hat off>
> Comments?

I would prefer, for simplicities sake, that the MAC simply include an
ESN rather than roll the keys over, but not strongly.


Adam Langley
tcpm mailing list