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

Eric Rescorla <ekr@networkresonance.com> Mon, 22 June 2009 18:05 UTC

Return-Path: <ekr@networkresonance.com>
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 BAC5B28C256 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 11:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=1.021, 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 80LekTB1bVt8 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 11:05:29 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D7EEC3A6B0F for <tcpm@ietf.org>; Mon, 22 Jun 2009 11:05:29 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E2F7C50822; Mon, 22 Jun 2009 11:09:09 -0700 (PDT)
Date: Mon, 22 Jun 2009 11:09:09 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu> <20090619161614.EFC4850822@romeo.rtfm.com> <4A3BBC2E.9040100@isi.edu> <20090619164724.2353850822@romeo.rtfm.com> <4A3BC59C.9090200@isi.edu> <20090620153548.C20C01C0154@kilo.networkresonance.com> <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20090622180909.E2F7C50822@romeo.rtfm.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>, Joe Touch <touch@ISI.EDU>
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: Mon, 22 Jun 2009 18:05:30 -0000

At Mon, 22 Jun 2009 12:16:16 -0500,
Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> 
> Since this thread has turned into ping-pong between Joe and
> Eric, I'll break that pattern by putting in my assessment as
> a WG participant ...
> 
> I think Eric's explanation that if multiple MKTs can be
> matched to the outgoing SYN, then we can pick from them in
> an implementation-dependent way, as long as we pick one key,
> makes sense.  Yes, we can add complexity to disambiguate
> how that selection is made as part of our spec (TSAD/TAPD),
> but after reading the thread, I don't see clear value in that.

I note that if we don't like this, then the problem isn't 
particular to overlap. Even if we only allowed exact matches
and prohibited overlap, we still have the question of how
to deal with two keys that have been inserted for the same
connection. For instance, say we have some connection
which is operating on key A.

Then Alice injects B and C in that order. Bob injects C and B
in that order. I thought we'd agreed that that was OK and that
we were happy to end up with a setting in which we had C in
one direction and B in the other. If not, we need some 
more sophisticated ordering rule.

-Ekr