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

"Adam Langley" <> Wed, 09 July 2008 16:48 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 57A053A6A88; Wed, 9 Jul 2008 09:48:08 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E46C3A6A88 for <>; Wed, 9 Jul 2008 09:48:07 -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 meB+JhsfspJ6 for <>; Wed, 9 Jul 2008 09:48:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1DCA13A68E8 for <>; Wed, 9 Jul 2008 09:48:06 -0700 (PDT)
Received: by with SMTP id b25so2759807rvf.49 for <>; Wed, 09 Jul 2008 09:48:16 -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=WfKtzgBP/mEGMjB/LMu+TN8vl8IyRBkkxRHUfIdO1kQ=; b=CGEgr7KEakItV4NYi2uZkR1Pp4sok9gIgsXKBMKHtWLPaxa7JOCEsegQLgfUG2MByo jYFCJ4QGfEW9xsPnveHoa6S9XiS9sN2QDNr7Cm9eJnqKFkttEQQvuqd/tkKPCXUoKoKE ssaYt/AXx2F2tdi/P//AofzHlNIuXLq71+Uc0=
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=TXyqe7BVybW+4bcco6G5FCftNO+JypT1i/SaZo5Cr0mVX3i8bx/cqjCYXydZZnBIrN cjoBzzy86ivL2NESOcG5B6cg1cxFbapwFb0pPPdxBhMLL5/2fdV5jr0nEDs6Q3K3fjhM mUAbM0QKQY45ZX+YYCVtZuOIZEdkntoaS2C8g=
Received: by with SMTP id z6mr4116962rvo.91.1215622096177; Wed, 09 Jul 2008 09:48:16 -0700 (PDT)
Received: by with HTTP; Wed, 9 Jul 2008 09:48:16 -0700 (PDT)
Message-ID: <>
Date: Wed, 09 Jul 2008 09:48:16 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <>
X-Google-Sender-Auth: 11f778e34cda372e
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Tue, Jul 8, 2008 at 9:49 PM, Joe Touch <> wrote:
> The above is optimized assuming that the hash is computed during a copy
> operation that may or may not occur (e.g., it would not in a zero-copy
> stack), and further assumes that the copy is performed one MSS at a time
> (vs. copying the entire write() call argument, i.e., copy-on-write). It's
> not clear that optimizing the algorithm for this corner case is desirable,
> especially given the impact on more traditional implementations (i.e., the
> extra header copies/moves).

I don't believe that it would involve moving any extra data, you just
update the hash context with chunks in a different order. Although I
feel it's very low cost when not used and useful where it can be used,
it is fundamentally just a trick and not that important.

> I'd like to hear what others think of this. My view is that NATs do other
> things to TCP packets (e.g., rewrite sequence numbers, modify TCP options)
> that TCP-AO should probably detect as attacks. An earlier version of this
> work did consider replacing these values (addr/port pairs), not zeroing them
> out - i.e., replacing them with values determined during key exchange. I
> would prefer that to zeroing them out, though.

Although some NATs do change seq numbers, I've only heard it used for
FTP PORT commands. By not including the sequence numbers in a hash,
you are really reducing the power of the signatures, but it would
still have some use (against blind sweeps of the sequence space, for
example), so it shouldn't be dismissed out of hand.

Since the option exclusion list is so general, it would seem
inconsistent if the spec was to be inflexible here. NATs which change
ports and IPs are now, sadly, almost ubiquitous and cannot be ignored.

The most general solution would be for applications to specify a 20
byte mask and a single bit to determine if the pseudoheader is to be
included. Then the TCP header for the hash is: (header & mask) |
(filler & !mask) where "header" is the header on the wire and "filler"
is key-dependent material. (Basically, a zero bit in the mask means
"replace this bit with a bit from the filler"). The bits corresponding
to the TCP checksum should probably be forced to zero by the kernel.

Since only applications can decide what should be considered an
attack, that covers all the cases, it's fast and easy to do in

The filler needs to be 20 bytes, so I'd suggest iterating H(key),
H("\x00" + key), H("\x00\x00" + key) etc until 20 bytes have been
generated. For SHA1, only one iteration is needed. For MD5, only two.
("+" is a concatenation operator here)

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

The security properties of these functions usually depend strongly on
the condition that no two messages be transmitted with the same nonce.
If the seq number were to be taken as the bottom 32-bits of a nonce
counter, we could still hit the situation where two different packets
were transmitted with the same nonce. For example, a host acking data,
but not transmitting any itself. If we included both seq and ack in
the nonce, then I believe the retransmitted ACKs with and without SACK
options could still break 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 <-
  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.

So, I believe the non-uniqueness problem is much greater.



Adam Langley
tcpm mailing list