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

From: [email-masked]
Date: Tue, 8 Jan 2008 11:22:54 -0500

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Jan 2008 15:18:47 -0600

> directorate review of the connection latching draft.

Thank you.

> impact of this draft.  [...]

I agree, ...

> be explained in the Introduction of this draft.

... but connection latching is one of a multi-prong approach to closing
that gap.  The other main prong is IPsec APIs.  A third, optional prong,
is channel binding.

I fear that to correct this undersell while the IPsec APIs documents are
not complete might be to oversell the architectural impact of this
document.

Comments?

> be the preferred approach whenever feasible.

Well, does it hurt to have this?  I suppose this could be a MAY, if
implementors object (or it could be downgraded to MAY or removed
altogether when in the progression to Standard).

I don't feel too strongly about it, but I also don't feel too strongly
about discouraging the use of NATs (face it: NATs are here to stay, at
least in the IPv4 world).

> SPD and PAD placed and/or how is that responsibility divided?

RFC4301 does not speak of a key manager, but does speak of key
management -- see section 4.5.  I'll clarify in the I-D, and here: the
key manager is the part of the implementation that manages the SAD.  The
KE protocols (IKEv2, KINK, ...) are associated with the key manager, but
what really matters here is the component of the system through which
all SAD updates are done.

> latched SA?

It doesn't.

>              This is the infamous "dangling SAs" issue
> applied to connection latch state.

What is this infamous issue?

>                                     I think that connection

It is absolutely desirable that connection latch state survive IKE_SA
and even child SA expiration.

The document does describe latch termination, but -05 will do so in much
more detail.

Basically a latch terminates when the ULP requests it (which may be when
the application requests it, or when an RST is received protected by a
suitable SA) and, in the normative model, whenever the key manager adds
an SA to the SAD which conflicts with the latch.

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

Thanks.  I'll fix this.

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

It matches the year in which it was submitted.  -05 will be submitted in
2008, so its IETF Trust Copyright notice will say "2008."

>      explicit reference was found in the text

If I correct the "undersell" then there will definitely be a mention of
bellovin-useipsec!

>      reference was found in the text

Suggestions?

>      draft-ietf-btns-abstract-api)

That should probably be informative, yes.

>   == Outdated reference: draft-williams-on-channel-binding has been

Will fix.

Thanks!

Nico
--

---

From: [email-masked]
Date: Tue, 8 Jan 2008 17:31:39 -0500

Nico,

> that gap.  The other main prong is IPsec APIs.  A third, optional
prong,

Describing this overall multi-prong structure and connection
latching's role in it would be a "good thing" to do in the
introduction and should position the connection latching draft
correctly.

> least in the IPv4 world).

This isn't about discouraging use of NATs; I completely agree
that NATs are a fact of life for IPv4.  This is about avoiding
encouragement of NAT-specific code in protocols and applications
that don't need it (i.e., work just fine with IPsec NAT traversal).

Think of the goal as "damage containment" - it does hurt to
encourage unnecessary attempts to deal with NATs.  It may be ok
to have the interface if the interface adds value to what apps
already have to do to cope with NATs, but there should be a
rationale for the added value.

> > -- Key Manager/Key Management

[... snip ...]

> What is this infamous issue?

Does a CHILD_SA survive termination of the IKE_SA used to create
the CHILD_SA?

[... snip ...]

> The document does describe latch termination, but -05 will do 
> so in much more detail.
> 

I think that's ok, just write it up in -05, and explain why the
disconnection from the IKE_SA lifetime/fate is important.  I
was making intelligent guesses in the absence of detail, and I
guessed wrong :-).

Thanks,
--David

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2008 4:19 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [anonsec] Connection Latching draft review 
> (draft-ietf-btns-connection-latching-04.txt)
>

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Jan 2008 16:52:08 -0600

> introduction and should position the connection latching draft

OK, I will do so.

> that don't need it (i.e., work just fine with IPsec NAT traversal).

I think this text doesn't do that at all.  Why would application
developers bother to ask about NAT-related information when they already
know that their app works with IPsec NAT traversal?

> rationale for the added value.

But also, and more to the point, as long as we accept the existence of
NATs we might as well accept the existence of protocols which need help
to traverse them, and then we should accept some of the responsibility for
helping them.

I'd reverse your question and ask how making this information available
to the application developer encourages the development of new
applications that need help in order to traverse NATs.

> Does a CHILD_SA survive termination of the IKE_SA used to create

Right, that problem is irrelevant to connection latching as specified.
That said, that problem is relevant to the construction of IPsec channel
bindings.  But that's a topic for a different I-D.

Thanks,

Nico

---

From: [email-masked]
Date: Wed, 9 Jan 2008 11:22:31 -0500

Nico,

> developers bother to ask about NAT-related information when 
> they already know that their app works with IPsec NAT traversal?

Because there's a "SHOULD" in the standard written by people who
may have more of a clue about NATs.

> applications that need help in order to traverse NATs.

I hereby renew my membership in the "if in doubt, leave it out"
design camp ;-).  In any case, I'm ok with making the requirement
a MAY, at least for now.  

Thanks,
--David

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jan 2008 16:32:47 -0600

I've uploaded a new version, -05, that addresses most of your comments,
as well as most of Dan McDonald's comments (made off-list; I'll forward
those exchanges to the list, with Dan's permission, shortly).  I still
have some TODOs, but I wanted to submit a new version sooner, rather
than later.

I've made few changes to the design of connection latching, but several
significant and substantive changes to the document.

Design changes:

 - removed LARVAL state (it was imaginary)
 - added requirement for API option for conflict resolution: wait for
   the conflict to go away or break the latch
 - added SUSPENDED state corresponding to "wait for the conflict to go
   away" (see above)

Text changes:

 - moved connection latch state into its own sub-section and greatly
   expanded it, including state transition details
    - I've not yet written a state diagram
 - added more text about the normative/informative model split
 - added text to the introduction about the significance of this work
 - added text on simultaneous latching (corresponding to TCP
   simultaneous opens)
 - added more text on connection latching in BITS and SG

Thank you, David, and thank you, Dan, for your helpful comments!

In particular, given that Dan and connection latching go back a long
time (at least ten years) and that Dan had much to do with the Solaris
implementation of connection latching, I now feel quite certain that
this document is on track as far as the technical details are concerned.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Jan 2008 17:16:10 -0600

On Thu, Jan 10, 2008 at 04:32:47PM -0600, Nicolas Williams wrote:
> those exchanges to the list, with Dan's permission, shortly).

Attached are Dan's comments and my replies.

Nico

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 16:18:03 -0500

Nico & Dan,

the SPD has always been a persistent database. the newly added PAD 
also is persistent. It's the SAD that is transient, i.e., need not 
have any entries unless SAs have been created, and those entries 
vanish when the SAs they represent vanish. The notion of dynamic 
modification of the SPD is a relatively new concept, not part of the 
original design, but not ruled out by it. Also note that the 
de-correlated SPD model introduced in 4301 works very well for a 
persistent database, but could be costly to maintain if the SPD is 
frequently updated.

Steve has indicated that he is tired of reviewing BTNS documents that 
often are hard to read and that too often are revised with only 
slight improvement. The BTNS problem statement is the most recent 
example, where comments from two years ago were not acted upon.

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jan 2008 15:42:46 -0600

> also is persistent. It's the SAD that is transient, i.e., need not 

Had I gotten this wrong?  No.  Dan may not be totally up to speed with
RFC4301 terminology, but I wouldn't dismiss what he has to say on
account of that.

> persistent database, but could be costly to maintain if the SPD is 

Are you asking that the connection latching I-D address how to perform
dynamic updates of a de-correlated SPD?
_______________________________________________

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 16:57:29 -0500

>RFC4301 terminology, but I wouldn't dismiss what he has to say on

since, as I said, the SPD has ALWAYS been defined as persistent, this 
misunderstanding is not attributable to a lack of familiarity with 
4301.

>dynamic updates of a de-correlated SPD?

no. I was just noting the most recent (2 years old) text supporting 
the fact that the SPD was not nominally viewed as dynamic.

Steve