IPsec Channels: Connection Latching
RFC 5660

Note: This ballot was opened for revision 11 and is now closed.

(David Ward) Discuss

Discuss (2009-03-12 for -)
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?

(Jari Arkko) (was Discuss) Yes

Comment (2009-05-14)
No email
send info
> 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.

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2009-02-23)
No email
send info
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).

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2009-04-17)
No email
send info
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...

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) (was Discuss) No Objection

Comment (2009-02-26)
No email
send info
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.

(Chris Newman) (was Discuss) No Objection

Comment (2009-02-25 for -)
No email
send info
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.

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection