Re: [tcpm] TCP-AO: Text for New_Key Process

Eric Rescorla <ekr@networkresonance.com> Tue, 03 February 2009 16:52 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0CF28C228; Tue, 3 Feb 2009 08:52:50 -0800 (PST)
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 B5DA628C228 for <tcpm@core3.amsl.com>; Tue, 3 Feb 2009 08:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level:
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 xIplyVmc5xvX for <tcpm@core3.amsl.com>; Tue, 3 Feb 2009 08:52:48 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DC19A28C1C9 for <tcpm@ietf.org>; Tue, 3 Feb 2009 08:52:47 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 69A7E50822; Tue, 3 Feb 2009 09:09:10 -0800 (PST)
Date: Tue, 03 Feb 2009 09:09:10 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4988722D.9070104@isi.edu>
References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <B33C7F84-66B7-4F2C-9B04-2BC1716C7994@cisco.com> <498618DA.1070308@isi.edu> <20090202162602.D178450822@romeo.rtfm.com> <1233596612.498730c436efe@webmail.isi.edu> <20090203041052.83BCF50822@romeo.rtfm.com> <4987D110.7020804@isi.edu> <20090203152834.712B350822@romeo.rtfm.com> <4988722D.9070104@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20090203170910.69A7E50822@romeo.rtfm.com>
Cc: tcpm@ietf.org, Allison Mankin <mankin@psg.com>, skonduru@juniper.net
Subject: Re: [tcpm] TCP-AO: Text for New_Key Process
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: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At Tue, 03 Feb 2009 08:34:53 -0800,
> OK, let's call the place where the connection info is stored the STORE.
>
> Then the steps still become:
> 
> - - get the keyID from the packet
> - - go to the STORE to find out how long the MAC is
> - - pass the keyID and (optionstart + len - maclen)
> 
> Still three steps, vs one:
> 
> - - pass the keyID and (optionstart + 2)
> 
> Note that the second way doesn't need to go to a separate table of
> information to figure out how to finish parsing the packet. Regardless
> of what you call it or where you put it, this takes multiple steps and
> consulting the STORE before you can pass the required information to the
> verification algorithm.

Again, I wouldn't construct the system this way.

Rather, you hang the information required to process each connection
off the connection itself. This is how pretty much every SSL/TLS stack
works.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm