[anonsec] I-D Action:draft-ietf-btns-connection-latching-02.txt

[Nicolas.Williams at sun.com (Nicolas Williams)]

I'd appreciate some feedback on this version of the connection latching
I-D.

 - In particular I'm looking for feedback on section 2.1, whether the
   proposed modification to the child SA authorization process is
   reasonable.  (Note: the child SA authorization process is modified
   only when connection latching is used; see also the note in section
   2.3 about a PAD entry flag to preserve traditional semantics.)


 - Section 2.2 should have been renamed (something like "Informative
   model: local packet tagging").


 - Neither section 2.1 nor 2.2 talks about when to initiate SAs.  But it
   should be obvious that the right time is when a latch is initiated.


 - Section 3 doesn't say much about the SPD.

   In particular, when an application requests that traffic be PROTECTED
   that would otherwise have been BYPASSed (or when a locally privileged
   app requests the opposite) then the SPD should be temporarily
   modified accordingly.  This should be described in detail.


 - Sam proposed that we describe connection latching in BITS
   implementations.

   I'm not entirely sure if Sam meant describing a model where BITS
   devices are integrated into the local IP stack where such devices be
   interfaced to, or if he meant that we should describe how BITS/SG
   middle boxes can apply connection latching principles to traffic
   traversing them.

   If the former, then I believe that may not be possible without
   changes to those devices to bring them in line with the model
   described in section 2.2; aside from that the model in section 2.2
   should suffice for BITS-like devices that can be interfaced to.

   If the latter, that's easy, but like all stateful middle boxes, the
   result is not 100% perfect.  And channel binding is not possible in
   such a scenario.


 - Sam also wanted it to be possible to support connection latching and
   channel binding for road warriors who move from behind a VPN into the
   private network.  I believe this is feasible using nested SAs (the
   outer SA being between the client and an SG, the inned SA being
   between the client and the server).  But of course, whether TCP
   connections can survive such moves is another story -- the inner
   client address has to remain the same.


Nico
--