Received changes through RFC Editor sync (changed abstract to 'This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]')

[Ballot discuss]
I am unsure that the SCTP section defines behavior which is consistent with application expectations.  The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks.  This has an impact on the semantics of the application socket API.  While connection latching is transparent when everything is working, there are new failures that ripple to the application.  That is, the application will observe different behavior on a connection with and without latching.

My conclusion is that the API ought to provide information for the application about the connection latching, and it just does not seem to be there.  If you can point me to a discussion of this topic on the WG mail list, then I'll clear.  I'm not trying to alter consensus, but I do want to make sure that this topic was considered.

[Ballot discuss]
Remaining issues:

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

I believe you are requiring that applications do this if the underlying
transport layer cannot do it. Please state this requirement explicitly,
if it is indeed the case.

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

I would like to see an explicit statement that this mode can only support
limited set of protocols (e.g., TCP but not UDP)

[Ballot discuss]
Remaining issues:

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

I would like to see an explicit statement that this mode can only support
limited set of protocols (e.g., TCP but not UDP)

[Ballot comment]
> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

It would be helpful to explicitly call out that you allow both normal IDs
and the public key ID introduced in the BTNS core spec.

> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

Please clarify whether you bind to the *name* or the key behind it in
the non-BTNS cases,

> Implemenations MAY provide a way to disable automatic creation of
> connection latches

1. Typo
2. Personally, I'd like to see a SHOULD/MUST here. Ability to turn off
  complex (i.e., can have bugs, and possibly consume extra time in some
  applications) functionality is needed.

[Ballot discuss]
Remaining issues:

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

I would like to see an explicit statement that this mode can only support
limited set of protocols (e.g., TCP but not UDP)

[Ballot comment]
> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

It would be helpful to explicitly call out that you allow both normal IDs
and the public key ID introduced in the BTNS core spec.

> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

Please clarify whether you bind to the *name* or the key behind it in
the non-BTNS cases,

[Ballot discuss]
Remaining issues:


> o  CLOSED (by the ULP, the application or administratively)
> and always have an associated owner, or holder, such as a ULP
> transmission control block (TCB).

Comment: As you mention below this state doesn't really exist
any measurable time if the ULP closed it. And it couldn't either,
because there would be no TCB to associate with. I wonder if
the name of this state would be better as "CLOSING".

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

I would like to see an explicit statement that this mode can only support
limited set of protocols (e.g., TCP but not UDP)

[Ballot comment]
> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

It would be helpful to explicitly call out that you allow both normal IDs
and the public key ID introduced in the BTNS core spec.

[Ballot discuss]
Remaining issues:


> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound
to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1
and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4
but with *different* peer cert CE2 and possibly a different CA CA2? I.e.,
do you bind to the *name* or the key behind it in those non-BTNS cases?

> o  CLOSED (by the ULP, the application or administratively)
> and always have an associated owner, or holder, such as a ULP
> transmission control block (TCB).

Comment: As you mention below this state doesn't really exist
any measurable time if the ULP closed it. And it couldn't either,
because there would be no TCB to associate with. I wonder if
the name of this state would be better as "CLOSING".

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

I would like to see an explicit statement that this mode can only support
limited set of protocols (e.g., TCP but not UDP)

[Ballot discuss]
Remaining issues:

> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

Do you allow both normal IDs and the public key ID introduced in the
BTNS core spec (which is an RFC by now, by the way)? See also below?

> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound
to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1
and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4
but with *different* peer cert CE2 and possibly a different CA CA2? I.e.,
do you bind to the *name* or the key behind it in those non-BTNS cases?

> o  CLOSED (by the ULP, the application or administratively)
> and always have an associated owner, or holder, such as a ULP
> transmission control block (TCB).

Comment: As you mention below this state doesn't really exist
any measurable time if the ULP closed it. And it couldn't either,
because there would be no TCB to associate with. I wonder if
the name of this state would be better as "CLOSING".

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> SA that protected it could expired before

expire? could be expired?

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

Is there a corresponding message that could be used with UDP? If not,
please state early on that the BITS implementations can only support
TCP.

[Ballot comment]
I have cleared my Discuss leaving two small points that are worthy of consideration for additional text.

---
>> The first two comments can be summarized what is the
>> protection/restoration strategy? - Once one can latch
>> flows to an IPsec tunnel then one may want to latch
>> flows to a backup tunnel so that in the event of a
>> failure there is orderly migration of traffic
>
> Connection latching is intended for end-to-end use; in
> the event of failure the "connection" fails and is
> closed, with the application informed of this.

If this is a conscious decision rather than an oversight, then I suppose I am OK.

Dave (and I) wanted to understand the service interface.

One could imagine a flow being associated with multiple connections (IPsec tunnels). The flow is latched to one (the primary) until it fails at which point it is latched to another (the backup) so that there is no or only minor disruption of service to the application.

If you were to add a note that "provision of protected services by automatically latching to a backup connection in the event of the failure of a primary connection is out of scope of this document" then that would be really nice.

---

Might be nice to include a short paragraph or section on VPNs...

  Connection latching was not developed for use in VPNs, but could
  be used successfully in IPsec VPNs as follows...

[Ballot discuss]
I'm going to carry on with Dave Ward's Discuss at least until I have heard a response from the authors. I think the Discuss could be easily resolved with a few short paragrpahs.

[Ballot discuss]
A few unrelated comments:

The first two comments can be summarized what is the protection/restoration strategy?
- Once one can latch flows to an IPsec tunnel then one may want to latch flows to a backup tunnel so that in the event of a failure there is orderly migration of traffic

- A reader/implementor has to derive the action to take if a tunnel goes down and there are other possible routing paths to the destination and what is supposed to happen. I suggest that there is a brief section on failure cases


---new point---

- How can this technology be used for IPsec VPNs? Can a router latch flows between two VPNs or AFBRs? How?

[Ballot discuss]
I have reviewed draft-ietf-btns-connection-latching-08, and have a
couple of concerns that I'd like to discuss before recommending
approval of the document:

My first concern is that some of the optional features allow an
application/ULP to effectively modify the IPsec Security Policy
Database (overriding the policy configured by the administrator), or
phrased other way, send/receive packets that violate the SPD
configured by the administrator.

The relevant text is Section 2.2 "An OPTIONAL behaviour is to
logically update the SPD..." (which allows not respecting changes to
SPD during a connection), Section 3.1, and Section 6.2.

This sounds a bit problematic -- although Section 6.2 does have some
text about the security considerations, I'd like to discuss this a
bit more.


My second concern is about doing connection latching automatically,
without a request from the application (or in Section 2.4, even
without request from the ULP). This means that e.g. TCP connections
will break if the peer identity or quality of protection changes. If
the change was due to an attack, breaking the connection might be the
right decision. But what about changes due to other reasons?

If the application specifically asked for a latch, then it's basically
saying that it prefers a broken connection to changed peer ID/quality
of protection. That probably would be a reasonable decision for
applications that use channel bindings. But would having this as
default setting for *all* applications a good idea? (And would doing
this in a security gateway -- which is not even an endpoint of the ULP
-- be a good idea?)

It's certainly possible to imagine peer ID/quality of protection
changes that are not due to attacks, and where breaking all ULP
connections would not be the preferred behavior.

The first examples that come to mind are a redirect from one security
gateway to another (in a cluster of "equivalent" gateways), switching
to ESP-NULL (integrity only) when moving to a trusted network, and
non-deterministic policies (e.g. both peers accept both AES and
Camellia, and don't have a preference either way -- which gets picked
would depend on implementation details, and might change over time
depending on e.g. which end initiates rekeying for an SA).

Was this question discussed in the WG?


The third concern is about applicability of latches at all in presence
of non-deterministic policies. While e.g. gateway redirects and
switching encryption on/off are probably quite rare events, it seems
non-deterministic policies would be in general incompatible with
connection latching... perhaps the document should explicitly
describe this?

[Ballot discuss]
Imagine the case where a an ULP has sent 30 k of data and stuffed it into a TCP connection but the kernel is still buffering that data and it has not been sent yet. At this point the flow transitions to the BROKEN state. Does the 30k of data sill get sent or not? I could not seem to find the answer to this.

I would not be surprised if the answer is there and I just missed it so hopefully this can discuss can be resolved with no change to the document.

[Ballot comment]
I like the concept but wIthout the API's is nothing to standardize here - there no change on the wire, there's no change to anything else. How would a vendor even says they are or are not complaint with this? How would one move it to Draft etc. I think this should normatively depend on the API draft - it means nothing without it.

[Ballot comment]
I like the concept but wIthout the API's is nothing to standardize here - there no change on the wire, there's no change to anything else. How would a vendor even says they are or are not complaint with this? How would one move it to Draft etc. I think this soudl normatively depend on the API draft - it means nothing without it.

[Ballot comment]
I support advancement of this technology, but believe it needs some
revision to address comments from Elwyn Davies and IESG discuss
positions.

While I wouldn't necessarily hold up this work waiting for
draft-ietf-btns-abstract-api, I will observe that the longer the
gap between publication of this draft and the abstract API (or at least
a subset of the abstract API necessary for an application to query
channel binding and encryption strength), the less likely we'll get
deployment of this technology by applications.  Application developers
have already invested time integrating with TLS stacks to get channel
security.  They will not spend time integrating with IPsec
unless the extensions to the sockets API are the same across
platforms that offer socket (Linux, Solaris, MacOS, WINSOCK).  Even
then, this will be a tough sell.

Without the application API, this technology provides no useful
services to _applications_ as the application can not know whether
the channel is protected and thus can not indicate such to the
end-user.  Only a tiny group of power-users would be capable of
configuring their IPsec stack to require IPsec to particular
hosts/subnets and understand the security implications of doing so
for applications.  That's simply not a useful application service.

It may be wise to design enough of the abstract API (and
perhaps non-normatively suggest a sockets/WINSOCK style API
extension) to make this useful to applications before publishing this.
After all, the draft includes a "SHOULD" that can't be done in an
interoperable fashion without such work.

[Ballot discuss]
The Gen-ART Review by Elwyn Davies on 24-Feb-2009 includes some very
  significant comments.  Please respond to this review.  The review can
  be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-btns-connection-latching-08-davies.txt

[Ballot discuss]
This is good stuff, but I had a number of issues relating to imprecise
language to describe what exactly is required. Note that as I'm doing
this review it is 2AM so it could be just that I'm too tired to
understand.

> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

Do you allow both normal IDs and the public key ID introduced in the
BTNS core spec (which is an RFC by now, by the way)? See also below?

> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

RFC 4301 talks about partial and exact matches -- presumably you mean
the latter above.

Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound
to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1
and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4
but with *different* peer cert CE2 and possibly a different CA CA2? I.e.,
do you bind to the *name* or the key behind it in those non-BTNS cases?

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

I'm curious why this end's NAT data would also not be relevant for
this. Or maybe it is not, but after thinking about this for a couple
of minutes I can't decide which way it should be. Has the WG considered
providing information about the implementation's own perceived status
behind a NAT and possibly its

What is "inner and outer tunnel address"? Since you are mentioning
this in the context of NATs, do you really mean IPsec tunnel mode
inner and outer addresses, or the peer's address inside and outside
the NAT? Surely "peer's inner address" in a tunnel packet would be
a part of the 5-tuple anyway?

Finally, even if NATs are not involved, wouldn't tunnel mode
outer addresses be interesting anyway?

> o  Implementations SHOULD create IPsec channels automatically by
>    default when the application does not explicitly request an IPsec
>    channel.

Really? Without no policy whatsoever... I think there should be
a knob to enable BTNS, as there would likely be uses of a
BTNS capable device where the small additional IKE negotiation
delay for a large number of connections would be unacceptable.

> o  CLOSED (by the ULP, the application or administratively)
> and always have an associated owner, or holder, such as a ULP
> transmission control block (TCB).

Comment: As you mention below this state doesn't really exist
any measurable time if the ULP closed it. And it couldn't either,
because there would be no TCB to associate with. I wonder if
the name of this state would be better as "CLOSING".

> informed except where the ownser caused the transition, in which case

Typo

> o  CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection
>    parameters]) -> latch handle
>      If there is no conflicting connection latch object in the
>      LISTENER state for the given 3-tuple (local address, protocol
>      and local port number), and local policy permits it, then

It is interesting that here you have "local policy permits" clause,
but for CREATE_CONNECTION_LATCH you do not have one. Is this
deliberate, or a mistake?

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

> CREATE_CONNECTION_LATCH

This description does not tell me what happens in the different
error cases, e.g., when the if clauses are not fulfilled. For instance,
what if there is an existing latch for this 5-tuple and it would
even match the required properties?

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> SA that protected it could expired before

expire? could be expired?

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

Is there a corresponding message that could be used with UDP? If not,
please state early on that the BITS implementations can only support
TCP.

[Ballot discuss]
This is good stuff, but I had a number of issues relating to imprecise
language to describe what exactly is required. Note that as I'm doing
this review it is 2AM so it could be just that I'm too tired to
understand.

> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

Do you allow both normal IDs and the public key ID introduced in the
BTNS core spec (which is an RFC by now, by the way)? See also below?

> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

RFC 4301 talks about partial and exact matches -- presumably you mean
the latter above.

Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound
to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1
and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4
but with *different* peer cert CE2 and possibly a different CA CA2? I.e.,
do you bind to the *name* or the key behind it in those non-BTNS cases?

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

I'm curious why this end's NAT data would also not be relevant for
this. Or maybe it is not, but after thinking about this for a couple
of minutes I can't decide which way it should be. Has the WG considered
providing information about the implementation's own perceived status
behind a NAT and possibly its

What is "inner and outer tunnel address"? Since you are mentioning
this in the context of NATs, do you really mean IPsec tunnel mode
inner and outer addresses, or the peer's address inside and outside
the NAT? Surely "peer's inner address" in a tunnel packet would be
a part of the 5-tuple anyway?

> o  Implementations SHOULD create IPsec channels automatically by
>    default when the application does not explicitly request an IPsec
>    channel.

Really? Without no policy whatsoever... I think there should be
a knob to enable BTNS, as there would likely be uses of a
BTNS capable device where the small additional IKE negotiation
delay for a large number of connections would be unacceptable.

> o  CLOSED (by the ULP, the application or administratively)
> and always have an associated owner, or holder, such as a ULP
> transmission control block (TCB).

Comment: As you mention below this state doesn't really exist
any measurable time if the ULP closed it. And it couldn't either,
because there would be no TCB to associate with. I wonder if
the name of this state would be better as "CLOSING".

> informed except where the ownser caused the transition, in which case

Typo

> o  CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection
>    parameters]) -> latch handle
>      If there is no conflicting connection latch object in the
>      LISTENER state for the given 3-tuple (local address, protocol
>      and local port number), and local policy permits it, then

It is interesting that here you have "local policy permits" clause,
but for CREATE_CONNECTION_LATCH you do not have one. Is this
deliberate, or a mistake?

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

> CREATE_CONNECTION_LATCH

This description does not tell me what happens in the different
error cases, e.g., when the if clauses are not fulfilled. For instance,
what if there is an existing latch for this 5-tuple and it would
even match the required properties?

>o  When the key manager informs a ULP that a connection latch has
>  been administratively transitioned to the CLOSED state then
>  connection-oriented ULPs MUST act as though the connection has
>  been reset by the peer.  Implementations of ULPs which are not
>  connection-oriented, and which have no API by which to simulate a
>  reset, MUST drop all inbound packets for that connection and MUST
>  NOT send any further packets -- the application is expected to
>  detect timeouts and act accordingly.

How does a "non-connection oriented ULP" "drop all inbound packets for
that connection"? I know you have specified the behaviour for certain
type of UDP sockets later in the document, but the general statement
still appears impossible to fulfill. Perhaps there's a limitation
here that you need to highlight.

> SA that protected it could expired before

expire? could be expired?

> When a connection latch is broken a BITS/BITW/SG implementation may
> have to fake a connection reset by sending appropriate packets (e.g.,
> TCP RST packets), for the affected connections.

Is there a corresponding message that could be used with UDP? If not,
please state early on that the BITS implementations can only support
TCP.

[Ballot discuss]
This is good stuff, but I had a number of issues relating to imprecise
language to describe what exactly is required. Note that as I'm doing
this review it is 2AM so it could be just that I'm too tired to
understand.

> The
> REQUIRED set of parameters bound in IPsec channels is:
> o  Type of protection: confidentiality and/or integrity protection;
> o  Transport mode vs. tunnel mode;
> o  Quality of protection: cryptographic algorithm suites, key
>    lengths, and replay protection;
> o  Local identity: the local ID asserted to the peer, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core];
> o  Peer identity: the peer's asserted and authorized IDs, as per the
>    IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].

Do you allow both normal IDs and the public key ID introduced in the
BTNS core spec (which is an RFC by now, by the way)? See also below?

> The SAs that protect a given IPsec channel's packets may change over
> time in that they may expire and be replaced with equivalent SAs, or
> may be re-keyed.  The set SAs that protect an IPsec channel's packets
> need not be related by anything other than the fact that they must be
> congruent to the channel (i.e, the SAs' parameters must match those
> that are latched into the channel).

RFC 4301 talks about partial and exact matches -- presumably you mean
the latter above.

Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound
to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1
and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4
but with *different* peer cert CE2 and possibly a different CA CA2? I.e.,
do you bind to the *name* or the key behind it in those non-BTNS cases?

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

I'm curious why this end's NAT data would also not be relevant for
this. Or maybe it is not, but after thinking about this for a couple
of minutes I can't decide which way it should be. Has the WG considered
providing information about the implementation's own perceived status
behind a NAT and possibly its

What is "inner and outer tunnel address"? Since you are mentioning
this in the context of NATs, do you really mean IPsec tunnel mode
inner and outer addresses, or the peer's address inside and outside
the NAT? Surely "peer's inner address" in a tunnel packet would be
a part of the 5-tuple anyway?

> o  Implementations SHOULD create IPsec channels automatically by
>    default when the application does not explicitly request an IPsec
>    channel.

Really? Without no policy whatsoever... I think there should be
a knob to enable BTNS, as there would likely be uses of a
BTNS capable device where the small additional IKE negotiation
delay for a large number of connections would be unacceptable.

> o  CLOSED (by the ULP, the application or administratively)
> and always have an associated owner, or holder, such as a ULP
> transmission control block (TCB).

Comment: As you mention below this state doesn't really exist
any measurable time if the ULP closed it. And it couldn't either,
because there would be no TCB to associate with. I wonder if
the name of this state would be better as "CLOSING".

> informed except where the ownser caused the transition, in which case

Typo

> o  CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection
>    parameters]) -> latch handle
>      If there is no conflicting connection latch object in the
>      LISTENER state for the given 3-tuple (local address, protocol
>      and local port number), and local policy permits it, then

It is interesting that here you have "local policy permits" clause,
but for CREATE_CONNECTION_LATCH you do not have one. Is this
deliberate, or a mistake?

> If no connection latch exists in the ESTABLISHED states with
> the same 5-tuple, and if there exist no child SAs that match
> the given 5-tuple, then the system MUST initiate an IKE
> exchange to setup child SAs for this 5-tuple.
>    .. a bit later ...
> If there exist no child SAs matching the given 5-tuple then the
> key manager SHOULD try to create a pair of child SAs for that
> 5-tuple.

Why the duplication? Or is there some subtle difference that I
am not seeing?

> CREATE_CONNECTION_LATCH

This description does not tell me what happens in the different
error cases, e.g., when the if clauses are not fulfilled. For instance,
what if there is an existing latch for this 5-tuple and it would
even match the required properties?

[Ballot discuss]
A few unrelated comments:

- Once one can latch flows to an IPsec tunnel then one may want to latch flows to a backup tunnel so that in the event of a failure there is orderly migration of traffic

- A reader/implementor has to derive the action to take if a tunnel goes down and there are other possible routing paths to the destination and what is supposed to happen. I suggest that there is a brief section on failure cases

- How can this technology be used for IPsec VPNs? Can a router latch flows between two VPNs or AFBRs? How?

[Ballot discuss]
[I-D.ietf-btns-prob-and-applic] has been published as Informational (RFC5387) and this is hence a DOWNREF. I believe it can simply move to the Informative References section, if the first reference to it in the introduction is changed to refer to [I-D.ietf-btns-core] instead (which has since been published as PS as RFC5386).

[Ballot discuss]
[I-D.ietf-btns-prob-and-applic] has been published as Informational (RFC5387) and this is hence a DOWNREF. I believer it can simply become an Informative reference, if the first reference to it in the introduction is changed to refer to [I-D.ietf-btns-core] instead (which has since been published as PS as RFC5386).

[Ballot comment]
I'd be better if Figure 4 and its explanatory text in Section 2.2.2 used the IP ranges set aside for documentation and dynamic port numbers (> 49152).

[Ballot discuss]
[I-D.ietf-btns-prob-and-applic] has been published as Informational (RFC5387) and his hence a DOWNREF. I believer it can simply become an Informative reference, if the first reference to it in the introduction is changed to refer to [I-D.ietf-btns-core] instead (which has since been published as PS as RFC5386).

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Julien Laganier, BTNS co-chair, who
reviewed this version of the document and believes this version is ready for
forwarding to the IESG.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, the document had review from both inside and outside the WG.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This WG has very few active participants who more or less are all co-authoring
documents. It is thus difficult to distinguish between the strong concurrence of
a few individuals and the whole WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are split betwen normative and informative. There is one
downward references to the BTNS problem and applicability statement (informational),
which should probably be made informative in next revision of the draft.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

Yes (The document has no IANA considerations).

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes (The document does not contain formal language).

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  This document specifies, abstractly, how to interface applications
  and transport protocols with IPsec so as to create "channels" by
  latching "connections" (packet flows) to certain IPsec Security
  Association (SA) parameters for the lifetime of the connections.
  Connection latching is layered on top of IPsec and does not modify
  the underlying IPsec architecture.

  Connection latching can be used to protect applications against
  accidentally exposing live packet flows to unintended peers, whether
  as the result of a reconfiguration of IPsec or as the result of using
  weak peer identity to peer address associations.  Weak association of
  peer ID and peer addresses is at the core of Better Than Nothing
  Security (BTNS), thus connection latching can add a significant
  measure of protection to BTNS IPsec nodes.

  Finally, the availability of IPsec channels will make it possible to
  use channel binding to IPsec channels.

          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

This document is a product of the Better Than Nothing Security (BTNS) working
group.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media Type
            review, on what date was the request posted?

A version of Connection Latching is implemented in OpenSolaris. The document
has been reviewed by Daniel McDonald who worked on the Connection Latching
implementation in OpenSolaris.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?

The Document Shepherd for this document is Julien Laganier (BTNS WG co-chair).
The Responsible Area Director is Tim Polk (Security Area Director).