[anonsec] BYPASS OR PROTECT

[Stephen Kent]

At 1:38 AM -0500 4/3/07, Nicolas Williams wrote:
>On Mon, Apr 02, 2007 at 02:43:45PM -0400, Stephen Kent wrote:
>>  The existing 4301 model describes BYPASS and PROTECT as mutually
>>  exclusive descriptions. So, the new option, which might more properly
>>  be named "PROTECT IF POSSIBLE" is a third option that the user has to
>>  see as a distinct choice.  So long as we represent this as a new
>>  option (which I think may be better reinforced by the name I
>>  suggested above), I don't think it undermines the 4301 model.
>
>Thank you.  I agree, PROTECT IF POSSIBLE is a better name.
>
>>  Of course we still have to make sure that there is no overlap (in
>>  terms of address space or name space)  between entries in the SPD
>>  that are described as PROTECT and ones that are labeled as "PROTECT
>>  IF POSSIBLE." The same is true for the PAD. These constrains are
>>  needed to satisfy the "don't undermine the existing 4301 access
>>  control model" criteria we discussed in Prague.
>
>I agree, but this needs a bit of refinement.  The point is that such
>overlap does not happen accidentally.
>
>First, administrators who want to write simple rules might appreciate a
>way to write few PROTECT or DISCARD rules that cover most traffic and
>PROTECT IF POSSIBLE that "punch holes" into the former for specific
>IPsec-aware applications.
>
>Second, IPsec-aware apps should not be able to create PROTECT IF
>POSSIBLE rules that punch holes in system policy that would PROTECT/
>DISCARD the apps' traffic unless the apps are sufficiently privileged.
>OTOH, IPsec-aware apps should be able to PROTECT or PROTECT IF POSSIBLE
>traffic that would otherwise be BYPASSED.  (This is the rule implemented
>in Solaris, BTW.)

Good points.  I think this says we may need another SPD extension, 
one that marks rules as ones that are inviolable, vs. ones that may 
be overridden by a user/app as you described above.

Steve