[anonsec] Comments on connection latching draft

[Sam Hartman]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman
    Nicolas> wrote:
    >> What is the purpose of the connection states?  I see them
    >> enumerated but never used.

    Nicolas> To help describe the process by which latches are created
    Nicolas> and torn down.

Then actually use the states in section 2 etc.

    >> Why must implementations make available nat state?  I'm
    >> unconvinced that is well enough defined to actually be useful.

    Nicolas> I think this is Michael's requirement.

    >> o Any IPsec channel created with a given peer while another
    >> distinct, established IPsec channel exists with the same source
    >> and destination addresses SHOULD be bound to the same peer.
    >> 
    >> 
    >> How does this interact with nats?

    Nicolas> Hmmm, badly :)

    >> Is it really desirable?

    Nicolas> It's a mitigation for BTNS clients using non-channel
    Nicolas> binding applications with multiple TCP connections.  It's
    Nicolas> not important to me, and I'll be glad to remove it.

    >> It seems like the BITS model plus proprietary extensions might
    >> work for channel binding.

    Nicolas> That's native IPsec built with BITS components.

    >> Section 2.1: What does it mean for connection latches to be
    >> broken?

    Nicolas> That ULPs (and applications) are informed.  ULPs are
    Nicolas> informed synchronously, so they can close/reset the
    Nicolas> connection before any subsequent packets can be accepted.

    >> Section 2.1: define what a conflicting latch is; you use the
    >> term several times but don't define it.  There is what I think
    >> is a definition but it is not associated with the term.

    Nicolas> Here:

    Nicolas>     o Create a connection latch object for a ULP 5-tuple
    Nicolas> (local and remote address, protocol and local and remote
    Nicolas> port numbers).  This operation succeeds when no
    Nicolas> conflicting connection latch objects exist and when there
    Nicolas> exist no child SAs encompassing the given 5-tuple or when
    Nicolas> all such SAs are with the same peer and equal quality of
    Nicolas> protection.  The key manager SHOULD attempt to create a
    Nicolas> suitable SA pair if one does not already exist; if it
    Nicolas> does then it MUST use the 5-tuple as the initial traffic
    Nicolas> selectors of the proposed child SAs.

    Nicolas> s/no conflicting connection latch objects exist/no
    Nicolas> connection latch exists already with the same 5-tuple/

    Nicolas> I.e., "conflicting connection latch" there means that a
    Nicolas> latch with the same 5-tuple as the proposed new latch
    Nicolas> already exists.  The latch manager can know this while
    Nicolas> the ULP cannot, which is why the latch manager checks
    Nicolas> this.

    Nicolas> So far I'm putting latch management in the same place as
    Nicolas> key management, but this is very abstract -- it need not
    Nicolas> translate into latch management being done by an IKE
    Nicolas> daemon.