[anonsec] Comments on connection latching draft

Sam Hartman <hartmans-ietf@mit.edu> Thu, 06 December 2007 23:46 UTC

Return-path: <anonsec-bounces@postel.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QQ5-0002be-RP for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 18:46:17 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QQ5-0005nG-GH for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 18:46:17 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB6Ncwiw028776; Thu, 6 Dec 2007 15:38:58 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (dhcp-178f.ietf70.org [130.129.23.143]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB6Ncbgd028695 for <anonsec@postel.org>; Thu, 6 Dec 2007 15:38:38 -0800 (PST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5E014815; Thu, 6 Dec 2007 18:38:36 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: anonsec@postel.org
Date: Thu, 06 Dec 2007 18:38:36 -0500
Message-ID: <tsld4tjjsw3.fsf@mit.edu>
MIME-Version: 1.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: hartmans@mit.edu
Subject: [anonsec] Comments on connection latching draft
X-BeenThere: anonsec@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: anonsec-bounces@postel.org
Errors-To: anonsec-bounces@postel.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


What is the purpose of the connection states?  I see them enumerated but never used.

Why must implementations make available nat state?  I'm unconvinced
that is well enough defined to actually be useful.

   o  Any IPsec channel created with a given peer while another
      distinct, established IPsec channel exists with the same source
      and destination addresses SHOULD be bound to the same peer.


How does this interact with nats?
 Is it really desirable?
It seems like the BITS model plus proprietary extensions might work for channel binding.


Section 2.1: What does it mean for connection latches to be broken?

Section 2.1: define what a conflicting latch is; you use the term
several times but don't  define it.  There is what I think is a definition but it is not associated with the term.

_______________________________________________