[anonsec] Comments on connection latching draft

[Sam Hartman]

What is the purpose of the connection states? I see them enumerated but never used.

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

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?
Is it really desirable?
It seems like the BITS model plus proprietary extensions might work for channel binding.


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

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

Post by Sam Hartman
What is the purpose of the connection states? I see them enumerated but never used.

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

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

I think this is Michael's requirement.

Post by Sam Hartman
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?

Hmmm, badly :)

Post by Sam Hartman
Is it really desirable?

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

Post by Sam Hartman
It seems like the BITS model plus proprietary extensions might work for channel binding.

That's native IPsec built with BITS components.

Post by Sam Hartman
Section 2.1: What does it mean for connection latches to be broken?

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

Post by Sam Hartman
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.

Here:

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

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

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

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

[Sam Hartman]

Nicolas> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman

Post by Sam Hartman
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.

Post by Sam Hartman
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.

Post by Sam Hartman
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 :)

Post by Sam Hartman
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.

Post by Sam Hartman
It seems like the BITS model plus proprietary extensions might work for channel binding.

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

Post by Sam Hartman
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.

Post by Sam Hartman
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.

[Paul Wouters]

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

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

I think this is Michael's requirement.

I think this might have to do with detecting multiple clients behind
the same NAT router.

Post by Nicolas Williams

Post by Sam Hartman
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?

Hmmm, badly :)

Why not make it souce and destination address plus port?

Post by Nicolas Williams
o Create a connection latch object for a ULP 5-tuple (local and
remote address, protocol and local and remote port numbers).

Like here.

Paul

[Nicolas Williams]

Post by Paul Wouters

Post by Nicolas Williams

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

I think this is Michael's requirement.

I think this might have to do with detecting multiple clients behind
the same NAT router.

The information is available, therefore requiring that it be made
available seems reasonable. Making this a recommendation is also
reasonable.

Post by Paul Wouters

Post by Nicolas Williams

Post by Sam Hartman
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?

Hmmm, badly :)

Why not make it souce and destination address plus port?

Did you mean only one port, and if so, the destination port, or both
ports? (Connection latching already does this for all five elements of
the 5-tuple, so if your answer is "both" then note that that's the whole
point of connection latching :)

[Michael Richardson]

Post by Nicolas Williams

Post by Sam Hartman
What is the purpose of the connection states? I see them enumerated but never used.

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

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

I think this is Michael's requirement.

Post by Sam Hartman
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?

Hmmm, badly :)

If as you say, it's my requirement, let me remember why.
I thought that we had ruled NAT interaction as out-of-scope.

BTW: real world case where channel binding is necessary:


http://www.schneier.com/blog/archives/2007/12/defeating_the_s.html
...
This works because the two security systems are decoupled. And the shoe
screening machine is so crowded and chaotic, and so poorly manned, that no
one notices the switch.