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

[Nicolas Williams]

On Tue, Jan 08, 2008 at 05:31:39PM -0500, Black_David at emc.com wrote:
> > > The introduction considerably undersells the architectural
> > > impact of this draft.  [...]
> > 
> > I agree, ...
> > 
> > ... 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.
> 
> 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.

OK, I will do so.

> > > -- NATs
> > > 
> > > p.5 says:
> > 
> > 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).
> 
> 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).

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?

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

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.

> > > -- Key Manager/Key Management
> 
> [... snip ...]
> 
> > >              This is the infamous "dangling SAs" issue
> > > applied to connection latch state.
> > 
> > What is this infamous issue?
> 
> Does a CHILD_SA survive termination of the IKE_SA used to create
> the CHILD_SA?

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