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

[Nicolas Williams <[e-mail]>]

On Tue, Jan 08, 2008 at 11:22:54AM -0500, [e-mail] wrote:
> 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.

Thank you.

> -- Service Orientation
> 
> The introduction considerably undersells the architectural
> impact of this draft.  [...]

I agree, ...

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

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

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

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

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

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.

> While not exactly key management, how does connection latch
> state lifetime relate to the lifetime of the IKE_SA for the
> 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
> 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.

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.

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

Thanks.  I'll fix this.

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

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

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

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

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

Suggestions?

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

That should probably be informative, yes.

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

Will fix.

Thanks!

Nico
-- 
_______________________________________________