Re: [tcpm] question about TCP-AO and rekeying

Joe Touch <touch@ISI.EDU> Wed, 17 June 2009 06:25 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F073A6DCF for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 23:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-mEKjwIvGhM for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 23:25:17 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 32CBB3A6DDA for <tcpm@ietf.org>; Tue, 16 Jun 2009 23:25:17 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5H6Ot7D021061; Tue, 16 Jun 2009 23:24:57 -0700 (PDT)
Message-ID: <4A388C37.3030703@isi.edu>
Date: Tue, 16 Jun 2009 23:24:55 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com>
In-Reply-To: <20090617054551.A4E0C1BCA23@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 06:25:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
>> However, the invariant is twofold:
>>
>> 	a) for a given packet, only one MKT applies
>>
>> 	b) for two endpoints with multiple MKTs,
>> 	the *same* MKT applies.
> 
> I don't see that this is true. As I understand the current design
> there's no reason that both sides can't use different MKTs
> indefinitely.

Each side can use a different MKT to transmit. However, if side A uses
MKT X to transmit, then side B needs to know to use MKT X to receive. If
side A matches MKT X on transmit and side B matches MKT Y on receive,
then there's a problem for that connection.

So let's rephrase, recognizing that there are two MKTs at any given time
(one for transmit on each side, and the same pair for receive on the
opposite side).

b) for two endpoints, if a given packet matches MKT on one side during
transmit, it must match the corresponding MKT on the other side during
receive.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko4jDYACgkQE5f5cImnZrtN/ACg+auD2x3yiHy6owI5aeUCePf7
M0IAoKAniNQHEBTxl6LIoSrixtwS4G9m
=8v0e
-----END PGP SIGNATURE-----