BYPASS OR PROTECT

As you may recall, at last week's IETF 68 meeting I
presented the
current state of the connection latching I-D.

One thing I had added to it was a description of
"BYPASS OR PROTECT" --
a way to negotiate the use/non-use of IPsec for packet flows
associated
with applications that are IPsec-aware and can handle the
non-use of
IPsec through such means as using TLS/SASL/GSS-API/... for
session
protection.

Sam commented that he thought that Stephen would object, but
Stephen did
not make any objections at the meeting.  Instead Stephen
explained that
his main concern is that nothing we do here be inconsistent
with the
access controls of IPsec [RFC4301] -- essentially restating
what the WG
charter says on this matter.

You may also recall that in the case of the core BTNS
document the
access control issue had been about ensuring that BTNS peers
not be
allowed to assert traffic selectors that non-BTNS peers are
allowed to
assert.  And recall that we addressed this by providing that
the PAD be
searched twice, once at authentication time and once at
CHILD SA
creation time, the latter to find that the asserted traffic
selectors do
not overlap with ones reserved for non-BTNS peers.

My question to Stephen and others: does BYPASS OR PROTECT as
specified
in the current connection latching I-D fall foul of the
RFC4301 access
control model?

My view is that no, it does not, though it is an extension
of the SPD in
the RFC4301 model, and that it is needed to in order to
support channel
binding applications.  Without BYPASS OR PROTECT we'll
likely see
applications resort to using two port numbers: one for
PROTECTed traffic
and one for BYPASSed traffic -- if connect() on the
protected port fails
or times out try connect() on the bypassed port).  The
two-port
alternative clearly does not fall foul of the RFC4301 access
control
model; it follows that use of BYPASS OR PROTECT _for
IPsec-aware
application port selectors_ does not either.

Stephen, Sam, others, care to comment?

Nico
-- 
_______________________________________________

Nico,

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.

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.

Steve
_______________________________________________

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.)

Nico
-- 
_______________________________________________

Nicolas Williams wrote:
> You may also recall that in the case of the core BTNS
document the
> access control issue had been about ensuring that BTNS
peers not be
> allowed to assert traffic selectors that non-BTNS peers
are allowed to
> assert.  And recall that we addressed this by providing
that the PAD be
> searched twice, once at authentication time and once at
CHILD SA
> creation time, the latter to find that the asserted
traffic selectors do
> not overlap with ones reserved for non-BTNS peers.

   I want to say that Openswan does precisely this when it
implements
Opportunistic Encryption a la RFC4322.


_______________________________________________

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 

   As this is used primarily on the responder, I suggest th
wording be infact:
     "PROTECT IF REQUESTED"

> 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 

   This is a general  problem in the PAD, and
SPD with overlapping items. i.e. this problem already
exists, and has been solved.



_______________________________________________

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
_______________________________________________

At 12:31 PM -0400 4/3/07, Michael Richardson wrote:
>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
>
>    As this is used primarily on the responder, I
suggest th wording be infact:
>      "PROTECT IF REQUESTED"

Does the spec say that it is used ONLY by a responder? If
so, then 
your wording sounds better. If not, ...

>
>>  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
>
>    This is a general  problem in the PAD, and
>SPD with overlapping items. i.e. this problem already
exists, and 
>has been solved.

I'm not quite sure what you mean above. The ordering of the
PAD and 
SPD allows one to have overlapping entries, but those were
entries 
that all had the same precedence, and which offer a binary
choice. 
The notion of PROTECT IF REQUESTED/POSSIBLE is a new concept
with 
different semantics and that's why I believe we have to be
more 
sophisticated in how we add this feature to the PAD and
SPD.

Steve
_______________________________________________

On Wed, Apr 04, 2007 at 11:17:57AM -0400, Stephen Kent
wrote:
> 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.

Another way to look at it is to have system policy determine
insertion
points into the SPD for app-requested rules -- since the SPD
is ordered
then the insertion points determine what rules the apps can
"punch
holes" into.  There could be multiple such insertion
points,
corresponding to multiple local privilege levels.

So the SPD extension, then, would be a rule type that
declares an
insertion point for specific applications or local
privileges.

Since there's more than one way to represent this we need
English-
language text and a canonical representation that
implementors can
ignore, provided that they provide equivalent
functionality.

Personally I prefer the insertion point approach since it
does not
require modifying existing rules.  Your notion of
"inviolable" rules
maps into placing such rules ahead of any insertion points.

Nico
-- 
_______________________________________________

At 11:50 AM -0400 4/4/07, Dan McDonald wrote:
>On Wed, Apr 04, 2007 at 11:17:57AM -0400, Stephen Kent
wrote:
>>  >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.
>
>For example, OpenSolaris has "inviolable" as a
global flag (which is disabled
>by default) for the entire SPD.  The only exception to
sockets overriding the
>SPD is for a socket that wishes to PASS - the process
that wishes to PASS
>MUST be privileged AND the "inviolable" flag
MUST be disabled.
>
>Having per-rule inviolability is a good idea, but we
need to consider apps
>AND their privileges.  For another example, I really
want my IKE daemon to
>speak in the clear REGARDLESS of the contents of the
SPD.
>
>Dan

Dan,

I think the WG has to discuss just what semantics we need
for the 
flag, but it's good to know that some implementations have
analogous 
capabilities now.

I'm pretty sure 4301 says that IKE messages cross the IPsec
boundary 
and that there need to be SPD entries to enable this, so
your last 
comment above is in conflict with that.

Steve

_______________________________________________

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Stephen" == Stephen Kent
<kentbbn.com> writes:
    Stephen> At 12:31 PM -0400 4/3/07, Michael Richardson
wrote:
    >> 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
    >> As this is used primarily on the responder, I
suggest th wording
    >> be infact: "PROTECT IF REQUESTED"

    Stephen> Does the spec say that it is used ONLY by a
responder? If
    Stephen> so, then your wording sounds better. If not,
...

  1) BTNS says nothing about how nodes know to do BTNS. We
explicitely
     left out discovery.
     So, an initiator would have to some some PAD/SPD entry
that told it
     to do something.
     
     If that thing was "PROTECT IF REQUESTED", and
the application
     requested protection, then that wording would fit.

  2) I think that it does make most sense to have such
entries on the
     responder. I expect to see more clear
"PROTECT" entries on the
     "clients" (I use that label vs initiator, on
purpose)

    >>> 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
    >> This is a general problem in the PAD, and SPD
with overlapping
    >> items. i.e. this problem already exists, and
has been solved.

    Stephen> I'm not quite sure what you mean above. The
ordering of the
    Stephen> PAD and SPD allows one to have overlapping
entries, but
    Stephen> those were entries that all had the same
precedence, and
    Stephen> which offer a binary choice. The notion of
PROTECT IF
    Stephen> REQUESTED/POSSIBLE is a new concept with
different
    Stephen> semantics and that's why I believe we have
to be more
    Stephen> sophisticated in how we add this feature to
the PAD and
    Stephen> SPD.

  Can you give me an example of an ordered PAD that would
still be
ambiguous?
  Your word "precedence" is funny to me, since the
entries don't have
the same precedence if they are ordered.

- -- 
]            Bear: "Me, I'm just the shape of a
bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON
   |net architect[
] mcrxelerance.com      http://www.san
delman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel
hacking, security guy"); [




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRhPb3oCLcPvd0N1lAQLnIQgAoREwgSeUNiOmcig3PTCVbc36m0fj
im0O
0mF2hEl3oGYxXdEIxfHu/mbhaP1dTW6M07l/I6zIslD2FKBRZWC/pooWhpZS
/xdf
jHFVj7KhmcZIDW3M4b+S7Gg5KSvg/P9NhpuT2Av8SyPIp6qzLzlPn+pzGnms
iSfG
Ox36yWMtn9RuBL9PKT8SyD3hD2XZlWJTTJubeIvintMMeLuT3TyUbhOlP/V6
tu2G
dqLzoIr6T+724SBCSv5uYgWfeafO+KPAHCsS8riz/Kgv0TG+mSTN04L4Djme
aGUF
ZlBtAMBuYDp1ekw221ZVD5vQZmafexde1JvANnF1Kmm+xILNfNloow==
=gTKk
-----END PGP SIGNATURE-----
_______________________________________________