[tcpm] question about TCP-AO and rekeying

Joe Touch <touch@ISI.EDU> Sat, 06 June 2009 18:46 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 284A328C0D7 for <tcpm@core3.amsl.com>; Sat, 6 Jun 2009 11:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level:
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, 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 h00npPMMRyLq for <tcpm@core3.amsl.com>; Sat, 6 Jun 2009 11:46:21 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 540A53A68BA for <tcpm@ietf.org>; Sat, 6 Jun 2009 11:46:21 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-86-44.lsanca.dsl-w.verizon.net [71.106.86.44]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n56IkAEf026658; Sat, 6 Jun 2009 11:46:12 -0700 (PDT)
Message-ID: <4A2AB973.3030203@isi.edu>
Date: Sat, 06 Jun 2009 11:46:11 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: tcpm Extensions WG <tcpm@ietf.org>
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
Subject: [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: Sat, 06 Jun 2009 18:46:22 -0000

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

Hi, all,

One open issue remaining is how to express what was formerly a database
with a particular structure (TAPD, previously TSAD) in ways that impact
rekeying and possibly future master key management protocols. We decided
at the last meeting in SFO to do as follows:

	- require that each segment match only one key
		- segments for established connections must match
		only one connection key
		- segments for new connections (SYNs) must match
		only one master key

Connection keys never overlap; there would never be two connection keys
with the same keyID and socket pair. The open issue focuses on master
keys, which would more likely be specified with wildcards, masks, or
ranges, esp. for remote port numbers, but also potentially for addresses
or local port numbers. This issue is particularly relevant for rekeying
- - adding new master keys that would result in new connection keys being
derived for existing connections - and how an endpoint would be able to
ensure uniqueness as above.

Do we need additional constraints to ensure that master key descriptions
never overlap?

As review, the previous description of keys as a database also implied,
by its structure, constraints on wildcards/masks/ranges. Each TAPD entry
was:

    a socket pair descriptor
        which may include wildcards or masks

    one or more MKTs, each of which includes:
        sendID
        recvID
        crypto info:
            master key
            MAC info
            KDF info

The TAPD was defined so that a segment matched at most one socket pair
descriptor, and that MKTs within that descriptor had distinct sendIDs
and recvIDs.

If we remove that data structure, it would most obviously be replaced
with MKTs with their own socket descriptors, i.e.:

    MKT
        socket pair descriptor (may include wildcards/masks)
        sendID
        recvID
        crypto info

The question that remains is whether MKTs that match a segment all have
identical socket pair descriptors, even down to their
wildcards/ranges/masks (which was previously required). If
not, then how do we ensure that MKTs don't interfere?

If we throw our hands up and say this is "implementation detail", then
IMO we could be hobbling any KMP, since there would be no common data
for the KMP to coordinate.

So how do we proceed? If we ensure that MKTs that all apply to a given
segment all share the same socket pair descriptor, why can't we call
that a data structure and describe it? (is the issue just that we call
it a database?) If not, how do we describe the MKTs so that we can
enable KMPs?

Please post thoughts to this list.

Thanks,

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

iEYEARECAAYFAkoquXMACgkQE5f5cImnZrvPdwCfZOKNvKpraJ5rp2cuIe89g7MU
9lwAn3qfA+dyY7+vtbA6+C6N3FJbBQis
=Yp3/
-----END PGP SIGNATURE-----