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

[[e-mail]]

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
forward.

-- 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.

tmp/draft-ietf-btns-connection-latching-04.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
 
------------------------------------------------------------------------
----

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


  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
the
     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
     draft-ietf-btns-abstract-api)

  == Outdated reference: A later version (-06) exists of
     draft-ietf-btns-core-05

  == Outdated reference: A later version (-06) exists of
     draft-ietf-btns-prob-and-applic-05

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

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

  == Outdated reference: A later version (-07) exists of
     draft-bellovin-useipsec-06

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

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

_______________________________________________