[anonsec] I-D Action:draft-ietf-btns-connection-latching-02.txt
Nicolas.Williams at sun.com
Fri Sep 14 10:41:33 PDT 2007
I'd appreciate some feedback on this version of the connection latching
- 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
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
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.
More information about the ANONSEC