[anonsec] BYPASS OR PROTECT

[Stephen Kent]

At 5:48 PM -0500 4/5/07, Nicolas Williams wrote:
>On Thu, Apr 05, 2007 at 05:52:32PM -0400, Stephen Kent wrote:
>>  At 8:49 AM -0400 4/5/07, Dan McDonald wrote:
>>  >On Thu, Apr 05, 2007 at 08:10:09AM -0400, Stephen Kent wrote:
>>  >
>>  ><SNIP!>
>>  >
>>  >>  I also see a possible disconnect here. Consider an SPD entry that
>>  >>  supports our new "PROTECT IF X" feature and that entry is a tunnel
>>  >>  for ALL TCP traffic between Host A and Host B. Let's say that one app
>
>PROTECT OR BYPASS is intended to support application use of IPsec and
>very much relates to specific traffic flows -- all SPD entries resulting
>from template PROTECT OR BYPASS entries will be for specific 5-tuples
>(yes, SCTP's multi-homing angle should be addressed).

OK, then we need to make sure that this, and analogous restrictions, 
are stated explicitly.

>
>>  >>  does not request an SA between A and B, and so an unprotected TCP
>>  >>  connection is established. Then a second app requests an SA, if
>>  >>  possible. Do we create a tunnel and migrate the old, unprotected
>>  >>  traffic to the tunnel? If not, we would seem to have a conflict
>>  >>  between two SAD entries, one labelled BYPASS and one ESP, with the
>>  >>  same scope (based on the SPD entry I described above). have we
>>  >>  discussed this scenario before, and if so, what was the conclusion?
>>  >
>>  >Connection latching covers this.  The first TCP connection between A and B
>>  >will latch into BYPASS, and the second one will latch into ESP.  Once a
>>  >connection is latched, policy changes will not affect the connection.
>>
>>  I don't see how this is consistent with the 4301 model of caching 
>>SPD entries.
>
>Which part isn't consistent?  Keep in mind that each latch is for a
>specific packet flow.

If we restrict the sorts of SPD entries top which BTMS applies, then 
the problem I cited does not arise. Otherwise, we have a scenario in 
which there is an extant, BYPASS SA and a new, PROTECTED SA, and 
there is no way to decide which traffic belongs on which SA, based on 
the cached SPD entry model defined in 4301.

>Are you concerned about tunnels and connection latching?
>
>Let's imagine a scenario where client A and server S are trying to
>communicate using PROTECTed traffic but A has to tunnel through an SG,
>G, and has to PROTECT all traffic between A and the SG.  This means we
>have to nest IPsec.  In the following lame ASCII-art the thick line
>represents the tunnel between A and G, and the thin line represents
>end-to-end IPsec between A and B:
>
>          A                        G
>           /----------------------\
>    app <--+----------------------+-----------------> B
>           \----------------------/
>
>Here the connection latch is between the application on A and B and
>though PROTECTed it is further encapsulated into the tunnel between A
>and G.
>
>Nico
>--

How one uses entries in the SPD caches and in the forwarding tables 
to create nesting of SAs is already defined in the 4301 model. That 
was not my concern.

I admit that I do not understand  how connection latching is realized 
relative to the 4301 model.  When I look at your connection latching 
I-D, I see some new terms, e.g., "template" PAD entry and "cloned" 
PAD and SPD entry, and an informal description of how to use them to 
effect connection latching.  I didn't see a description of how the 
4301 model is extended to accommodate these new features. I think 
that needs to be part of the document, i.e., a comparison of how 4301 
describes packet processing vs. what will now be required, and an 
analysis of why the changes do not undermine the security provided by 
4301.

Additionally, if there are any changes that affect the performance 
features of 4301, e.g., the ability to cache de-correlated SPD 
entries, that too needs to be addressed.  For example, an important 
feature of 4301 is the use of caches, to avoid the need to search the 
SPD for each outbound packet, or to search it to verify that a packet 
received on an SA was consistent with the access controls for that 
SA.  The text in the connection latching I-D does not make clear if 
the same processing model applies, given the references to cloned and 
template PAD and SPD entries

Also, whereas the BTNS I-D describes adding ONE new PAD entry, at the 
end, to allow communication with unauthenticated peers, we have been 
discussing much more elaborate capabilities, which require multiple 
new PAD entries, insertion at other than the end of the PAD table, 
restrictions on the types of SPD entries can can be safely used (as 
you explained above), etc. These are not in the BTNS I-D, and they do 
not appear to be in the connection latching I-D.

Steve