[anonsec] BYPASS OR PROTECT
kent at bbn.com
Wed Apr 4 08:17:57 PDT 2007
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
>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.
More information about the ANONSEC