Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00

Joe Touch <touch@ISI.EDU> Wed, 09 July 2008 18:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 614583A695C; Wed, 9 Jul 2008 11:49:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95D7628C1F6 for <>; Wed, 9 Jul 2008 11:49:05 -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 T+Tceejuk7Qd for <>; Wed, 9 Jul 2008 11:49:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 999463A695C for <>; Wed, 9 Jul 2008 11:49:04 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m69ImolL013971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jul 2008 11:48:52 -0700 (PDT)
Message-ID: <>
Date: Wed, 09 Jul 2008 11:48:45 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00
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: multipart/mixed; boundary="===============0833839435=="

Adam Langley wrote:
>> TCP already includes a 16-bit counter - the sequence number. The use of
>> longer counters that retain the high-order bits of that number were
>> discussed in Philadelphia.

(I had the IP ID on my brain; it's a 32-bit counter, as noted below).

> The security properties of these functions usually depend strongly on
> the condition that no two messages be transmitted with the same nonce.

Note that the inclusion of the IP ID may help in this regard; not only 
does the 32-bit seqno need to be repeated, but so does the ID; overall, 
the pair of those two should could be sufficient for statistical 
uniqueness (although, if we relax the ID requirement as per my intarea 
draft, that might not be the case)...

We talked in Phila about the use of either counters for the high-order 
bits of the 32-bit space, or about the use of rekeying to handle this.

>> The key problems involve retransmission at the
>> edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP
>> protocol itself. As you note, there didn't seem to be a good solution here.
> I don't see that's a big problem: The host maintains a belief of the
> high 32-bits (H) of the counter and the last low-32 bits that it saw
> (L). For each packet with a new sequence number (S):
>   If the distance from L..S is < S..L (mod 2**32) then assume
> out-of-order reception; if L...S crosses a rollover, decrement H. L <-
> S.
>   Otherwise, if S..L crosses a rollover, increment H. L <- S
> This can be confused by massive reordering. However, that just leads
> to the packet being rejected and it's probably been retransmitted
> anyway. Also, if a huge number of packets were lost the hosts could be
> knocked out of sync. Some additional logic could cope with this
> (assume it might have happened and check the MAC for another sequence
> number), but I believe that the window would have to be about 2GB big
> for this to happen.

IMO, this is much more effectively handled by rekeying. Doing so every 
4GB (or even twice as often) should be more than sufficient.


tcpm mailing list