Re: [tcpm] tcp-auth-opt issue: support for NATs

Joe Touch <touch@ISI.EDU> Thu, 07 August 2008 19:11 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 911FE3A6903; Thu, 7 Aug 2008 12:11:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 362F63A6908 for <>; Thu, 7 Aug 2008 12:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XlTp1j0elC9t for <>; Thu, 7 Aug 2008 12:11:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E3F33A6903 for <>; Thu, 7 Aug 2008 12:11:05 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m77JAUv9002869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2008 12:10:32 -0700 (PDT)
Message-ID: <>
Date: Thu, 07 Aug 2008 12:09:49 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Eric Rescorla <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Adam Langley <>,
Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Hi, Eric,

<indiv hat on>

Eric Rescorla wrote:
|> <indiv hat on>
|> If we ignore source IP addresses, we probably end up needing to go
|> through a set of possible keys when a SYN arrives.
| Well, not if you use unique key-ids.

I've noted before that I don't think it's a good idea to assume
cryptographic properties of fields in the header or option except for
the MAC.

Also, the size of the keyID space is fairly small as it is, and others
have suggested it be even smaller (the few bits actually needed to
rotate keys during a connection).

|> This seems like it
|> amplifies the impact of a SYN attack - the more keys we have, the more
|> each falsly-encrypted SYN costs.
| Well, that's certainly true at some level, but if you use any
| randomness at all in key-id assignment, you would expect to have
| about N/256 key-ids where N is the number of keys. Unless N is
| very large, the number of duplicate key-ids is likely to be high
| enough that this doesn't seem like a very impressive attack,
| especially since the attacker can force you to compute a MAC with
| *every* packet he sends, not just SYNs.

N could easily be fairly large, e.g., in peer-to-peer hubs. Note that
this should be an issue only for SYNs; once a connection is made, the
socket pair is already static (by TCP rules), so the appropriate key for
that socket pair (thus determined during the SYN handling) can be
installed - e.g., by a link.

|> Alternately, a good KMS could figure out when these IP addresses
|> changed, and update the TSAD accordingly. I would prefer this latter
|> solution...
| Yeah, but what does that say about manual key management, which is what
| we're going to have for the foreseeable future.

It says that renumbering has consequences. Either you need to increase
the burden on your key manager, or weaken your security (by increasing
DOS impact, e.g.).

If I have to pick one, I'd pick increasing the burden on the key manager
in that case for *this* protocol. (where key manager could be a person).

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list