[anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)

Black_David@emc.com Tue, 08 January 2008 17:19 UTC

Return-path: <anonsec-bounces@postel.org>
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI6i-0001P6-Tu for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 12:19:20 -0500
Received: from boreas.isi.edu ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI6h-0004JH-H8 for btns-archive-waDah9Oh@lists.ietf.org; Tue, 08 Jan 2008 12:19:20 -0500
Received: from boreas.isi.edu (localhost []) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08HFQAM016162; Tue, 8 Jan 2008 09:15:27 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08GnQBM007199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <anonsec@postel.org>; Tue, 8 Jan 2008 08:49:27 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08GnOfQ002866; Tue, 8 Jan 2008 11:49:24 -0500 (EST)
Received: from mailhub.lss.emc.com (nagas.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 8 Jan 2008 11:49:24 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m08GnC5U008691; Tue, 8 Jan 2008 11:49:22 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 11:22:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 8 Jan 2008 11:22:54 -0500
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085EA3@CORPUSMX20A.corp.emc.com>
Thread-Topic: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)
thread-index: AchSErkdc2O0+mHIRCeV3hdoNbnnfw==
To: <anonsec@postel.org>, <tsv-dir@ietf.org>
X-OriginalArrivalTime: 08 Jan 2008 16:22:55.0133 (UTC) FILETIME=[B94624D0:01C85212]
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2007.8.30.53115
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Tablus-Inspected: yes
X-Tablus-Classifications: public
X-Tablus-Action: allow
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: black_david@emc.com
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m08GnQBM007199
Cc: Black_David@emc.com
Subject: [anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)
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: 33cc095b503da4365ce57c727e553cf1

This message is an attempt to kill two review "birds" with
one email "stone" - I meant to review the connection latching
draft some time ago, and in addition, this is a transport
directorate review of the connection latching draft.

For the latter purpose, the following paragraph applies:

- I've reviewed this document as part of the transport area
  directorate's ongoing effort to review key IETF documents.
  These comments were written primarily for the transport
  area directors, but are copied to the document's authors
  for their information and to allow them to address any
  issues raised.

The result is a mix of transport and security comments in
this email - the transport ADs should pay particular
attention to the service-orientation and NAT comments.  In
general, this is a good draft, and I think it should go

-- Service Orientation

The introduction considerably undersells the architectural
impact of this draft.  IPsec architecture has been based on
inclusion of a logical firewall.  This results in the
configuration of security services being somewhat
disconnected from the higher level protocols and
applications that benefit from those services by the use of
the SPD to configure the logical firewall (see Sections 3
and 3.1 of RFC 4301).

This disconnection has been an important feature of IPsec,
as it has enabled consistent application of security
policy to all traffic crossing an IPsec boundary (e.g.,
to/from a specific network node, to/from an otherwise
unprotected [untrusted] network at a network node), but
it has made use of IPsec by higher layer applications and
protocols more difficult because application usage
requests for IPsec have to be expressed in terms of a
firewall-like configuration through an API of some form,
and conflicts are possible.

The connection latching draft is aimed at precisely this
gap between effective application usage and the logical
firewall architecture of IPsec; in essence, the draft is
defining the functional service interface through which
higher layer applications and protocols should be
obtaining IPsec services for themselves instead of setting
up SPD (and possibly PAD) entries directly.  This change
from logical firewall orientation to service orientation is
(IMHO) an important step towards making IPsec effectively
usable for protocols such as iSCSI and NFSv4, and should
be explained in the Introduction of this draft.

-- NATs

p.5 says:

   o  Implementations that provide such programming interfaces
	SHOULD make available to applications any available
	NAT-related information about the peer: whether it is
	behind a NAT and, if it is, the inner and outer tunnel
	addresses of the peer.

Is that serious?  I don't think inflicting NAT awareness on
additional protocols and applications is a good idea unless
it's absolutely necessary (i.e., protocol/app won't work through
a NAT that it doesn't know about).  In general, IPsec NAT
traversal ought to work transparently with respect to
connection latching, and (IMHO), this transparency should
be the preferred approach whenever feasible.

-- Key Manager/Key Management

The draft talks about a key manager.  It should state what
functions the key manager is performing with respect to the
IPsec architecture (RFC 4301).  While IKEv2 would clearly
be inside the key manager, where is responsibility for the
SPD and PAD placed and/or how is that responsibility divided?

While not exactly key management, how does connection latch
state lifetime relate to the lifetime of the IKE_SA for the
latched SA?  This is the infamous "dangling SAs" issue
applied to connection latch state.  I think that connection
latch state does not survive termination without replacement
of the IKE_SA (e.g., key management entity containing
IKE/IKEv2 implementation crashes), but ought to survive
replacement of the IKE_SA.  In any case, this topic needs to
be covered.

-- Nits

idnits 2.05.03 found a bunch of nits, mostly in the references.


  Checking boilerplate required by RFC 3978 and 3979, updated by RFC

     No issues found here.

  Checking nits according to

  == No 'Intended status' indicated for this document; assuming Proposed

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

     No issues found here.

  Miscellaneous warnings:

  == The copyright year in the IETF Trust Copyright Line does not match
     current year

  Checking references for intended status: Proposed Standard

     (See RFC 3967 for information about using normative references to
     lower-maturity documents in RFCs)

  == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632,
but no
     explicit reference was found in the text

  == Unused Reference: 'RFC4322' is defined on line 642, but no explicit
     reference was found in the text

  -- Possible downref: Normative reference to a draft: ref.
     'I-D.ietf-btns-abstract-api'  (No intended status found in state
file of

  == Outdated reference: A later version (-06) exists of

  == Outdated reference: A later version (-06) exists of

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-btns-prob-and-applic (ref.

  ** Downref: Normative reference to an Informational RFC: RFC 2367

  == Outdated reference: A later version (-07) exists of

  == Outdated reference: draft-williams-on-channel-binding has been
     as RFC 5056

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754