[anonsec] BYPASS OR PROTECT

[Nicolas Williams]

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

[Stephen Kent]

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

[Nicolas Williams]

Post by Stephen Kent
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.

Post by Stephen Kent
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
--

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent
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.

Post by Stephen Kent
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

[Nicolas Williams]

Post by Stephen Kent
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
--

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent
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.

one could do that, although I worry that this sounds fairly complex,
especially because it sounds like changes in SPD affect where
different rules apply.

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

how would one define the insertion point in a way that doesn't get too complex?

Post by Nicolas Williams
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.

agreed.

Post by Nicolas Williams
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.

I see what you mean, and I appreciate the generality, but I do worry
about creating a sophisticated access control capability that will
induce management errors.

Steve

[Nicolas Williams]

Post by Stephen Kent

Post by Nicolas Williams
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.

one could do that, although I worry that this sounds fairly complex,
especially because it sounds like changes in SPD affect where
different rules apply.

That's the nature of policies consisting of ordered rulesets.

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent

Post by Nicolas Williams
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.

one could do that, although I worry that this sounds fairly complex,
especially because it sounds like changes in SPD affect where
different rules apply.

That's the nature of policies consisting of ordered rulesets.

This is not true for many access control models. We adopted the
ordered rule model because it was commonly employed in other
contexts, e.g., firewall filter rule, and because, with caching, it
works very well at layer 3.

Also, recall that the 4301 processing model uses caches and that
calls for the SPD to be de-correlated, which implies no ordering. So,
although it still makes sense to offer an interface for an ordered
SPD to a human user to administer, if we talk about making changes to
an SPD dynamically, from an app, we are assuming that the correlated
SPD is used as the reference, and then we have to de-correlate it,
see what impact that has on extant SPD cache and SAD entries, etc.

Steve

[Nicolas Williams]

Post by Stephen Kent

Post by Nicolas Williams
That's the nature of policies consisting of ordered rulesets.

This is not true for many access control models. We adopted the
ordered rule model because it was commonly employed in other
contexts, e.g., firewall filter rule, and because, with caching, it
works very well at layer 3.
Also, recall that the 4301 processing model uses caches and that
calls for the SPD to be de-correlated, which implies no ordering. So,

However, the access control semantics of RFC4301 depend on the SPD being
ordered, and SPD de-correlation is intended to preserve the access
control semantics of a pre-de-correlation, ordered SPD. N'est ce pas?

Post by Stephen Kent
although it still makes sense to offer an interface for an ordered
SPD to a human user to administer, if we talk about making changes to
an SPD dynamically, from an app, we are assuming that the correlated
SPD is used as the reference, and then we have to de-correlate it,
see what impact that has on extant SPD cache and SAD entries, etc.

My view was that app-driven rules, in the model we'll describe, are
inserted into a normal SPD and then de-correlation is done again in
order to install the new SPD.

Implementors may choose to do this differently, provided that they
maintain the same semantics.

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent

Post by Nicolas Williams
That's the nature of policies consisting of ordered rulesets.

This is not true for many access control models. We adopted the
ordered rule model because it was commonly employed in other
contexts, e.g., firewall filter rule, and because, with caching, it
works very well at layer 3.
Also, recall that the 4301 processing model uses caches and that
calls for the SPD to be de-correlated, which implies no ordering. So,

However, the access control semantics of RFC4301 depend on the SPD being
ordered, and SPD de-correlation is intended to preserve the access
control semantics of a pre-de-correlation, ordered SPD. N'est ce pas?

right.

Post by Nicolas Williams

Post by Stephen Kent
although it still makes sense to offer an interface for an ordered
SPD to a human user to administer, if we talk about making changes to
an SPD dynamically, from an app, we are assuming that the correlated
SPD is used as the reference, and then we have to de-correlate it,
see what impact that has on extant SPD cache and SAD entries, etc.

My view was that app-driven rules, in the model we'll describe, are
inserted into a normal SPD and then de-correlation is done again in
order to install the new SPD.

OK, then let's say so explicitly in our description of the nominal model.

Post by Nicolas Williams
Implementors may choose to do this differently, provided that they
maintain the same semantics.

right, but we need a precise nominal model, like 4301, to provide a
testable reference.

Steve

[Nicolas Williams]

Post by Stephen Kent

Post by Nicolas Williams
My view was that app-driven rules, in the model we'll describe, are
inserted into a normal SPD and then de-correlation is done again in
order to install the new SPD.

OK, then let's say so explicitly in our description of the nominal model.

Post by Nicolas Williams
Implementors may choose to do this differently, provided that they
maintain the same semantics.

right, but we need a precise nominal model, like 4301, to provide a
testable reference.

The next revision of the connection latching I-D will say so, or perhaps
this should be a separate I-D (Sam seemed to think so).

What's the status of the core I-D?

Nico
--

[Julien Laganier]

On Mon, Apr 09, 2007 at 08:28:35AM -0400, Stephen

Post by Stephen Kent

Post by Nicolas Williams
My view was that app-driven rules, in the model
we'll describe, are inserted into a normal SPD
and then de-correlation is done again in order
to install the new SPD.

OK, then let's say so explicitly in our
description of the nominal model.

Post by Nicolas Williams
Implementors may choose to do this differently,
provided that they maintain the same semantics.

right, but we need a precise nominal model, like
4301, to provide a testable reference.

The next revision of the connection latching I-D
will say so, or perhaps this should be a separate
I-D (Sam seemed to think so).
What's the status of the core I-D?

Nico, the WGLC concluded on 2007-04-09, hence I thought
the WG would request publication of the core I-D to
IESG.

Does the discussion you and Steve have had so far
impact that? In other words, should we delay
submission of the core I-D to IESG?

-- julien / BTNS co-chair

[Nicolas Williams]

Post by Julien Laganier

Post by Nicolas Williams
What's the status of the core I-D?

Nico, the WGLC concluded on 2007-04-09, hence I thought
the WG would request publication of the core I-D to
IESG.

OK.

Post by Julien Laganier
Does the discussion you and Steve have had so far
impact that?

No, it does not.

Post by Julien Laganier
In other words, should we delay
submission of the core I-D to IESG?

Nope. I think it's ready.

Nico
--

[Julien Laganier]

On Wed, Apr 11, 2007 at 11:01:25AM +0200, Julien

Post by Julien Laganier

Post by Nicolas Williams
What's the status of the core I-D?

Nico, the WGLC concluded on 2007-04-09, hence I
thought the WG would request publication of the
core I-D to IESG.

OK.

Post by Julien Laganier
Does the discussion you and Steve have had so far
impact that?

No, it does not.

Post by Julien Laganier
In other words, should we delay
submission of the core I-D to IESG?

Nope. I think it's ready.

Before I forward it to IESG, I need you to resubmit a
new version of the draft that passes all IDnits
checks:

<http://tools.ietf.org/tools/idnits/>

It currently has 4 errors:

- No 'Intended status' indicated

==> Use "std" as category in the XML's <rfc> mark (e.g.
<rfc category="std" ipr="full3978" > )

- Lack an IANA Considerations section

==> If the document hasn't IANA considerations, include
an IANA cons section stating "This document has no
IANA considerations"

- Bad Normative/Informative ref split causing downrefs.

==> I think [I-D.ietf-btns-connection-latching],
[I-D.ietf-btns-prob-and-applic],
[I-D.ietf-kitten-gssapi-channel-bindings], and
[I-D.ietf-nfsv4-channel-bindings] are Informative
rather than Normative...

- Normative reference to obsolete RFCs (RFC 2408 and
RFC2409)

==> Suggest removing them, or move to Informative?

Once those are taken care of, I'll forward the draft to
IESG.

--julien / BTNS co-chair.

[Nicolas Williams]

Post by Julien Laganier
Before I forward it to IESG, I need you to resubmit a
new version of the draft that passes all IDnits
<http://tools.ietf.org/tools/idnits/>
- No 'Intended status' indicated
==> Use "std" as category in the XML's <rfc> mark (e.g.
<rfc category="std" ipr="full3978" > )

OK.

Post by Julien Laganier
- Lack an IANA Considerations section
==> If the document hasn't IANA considerations, include
an IANA cons section stating "This document has no
IANA considerations"

OK.

Post by Julien Laganier
- Bad Normative/Informative ref split causing downrefs.
==> I think [I-D.ietf-btns-connection-latching],
[I-D.ietf-btns-prob-and-applic],
[I-D.ietf-kitten-gssapi-channel-bindings], and
[I-D.ietf-nfsv4-channel-bindings] are Informative
rather than Normative...

And I-D.ietf-nfsv4-channel-bindings has been replaced with
I-D.williams-on-channel-bindings.

OK.

Post by Julien Laganier
- Normative reference to obsolete RFCs (RFC 2408 and
RFC2409)
==> Suggest removing them, or move to Informative?

Those should be informative, since they are only referenced in the
Introduction. Similarly for RFC4306 (IKEv2). The only normative
references left are to RFC2119 and RFC4301.

Post by Julien Laganier
Once those are taken care of, I'll forward the draft to
IESG.

I'll re-submit shortly.

Nico
--

[Nicolas Williams]

Post by Stephen Kent

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

how would one define the insertion point in a way that doesn't get too complex?

You put that "inviolable" rules that you posited ahead of the insertion
point. All others go behind. For a simple system with two levels of
privilege (w.r.t. IPsec policy), privileged and unprivileged, you need
two insertion points: one at the head of the SPD-S for privileged apps
to request BYPASS in contravention to system poilicy, and one at the end
of the SPD-S for unprivileged apps to request PROTECT where system
policy would BYPASS. (Yes, I ignored DISCARD rules there.).

Post by Stephen Kent

Post by Nicolas Williams
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.

agreed.

Post by Nicolas Williams
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.

I see what you mean, and I appreciate the generality, but I do worry
about creating a sophisticated access control capability that will
induce management errors.

Me too. But how can we ignore the "where" in the SPD to insert
API-driven rules? Do you believe that your "inviolable" flag would
allow us to ignore SPD order for such rules?

Nico
--

[Stephen Kent]

Post by Nicolas Williams
...

Post by Stephen Kent
I see what you mean, and I appreciate the generality, but I do worry
about creating a sophisticated access control capability that will
induce management errors.

Me too. But how can we ignore the "where" in the SPD to insert
API-driven rules? Do you believe that your "inviolable" flag would
allow us to ignore SPD order for such rules?
Nico
--

I had a very simple model in mind, which might be too simplistic, but
let me state it anyway.

For what I believe is the common case of user vs. supervisor, we
would need to mark rules as "U" or "S." When a newly proposed "U"
rule is to be inserted, we invoke an algorithmic check to determine
whether it would affect any "S" rule. If so, then the attempt to
insert the "U" rule is rejected. In this model one does not need to
define points where "U" rules could be inserted.

Steve

[Nicolas Williams]

Post by Stephen Kent
I had a very simple model in mind, which might be too simplistic, but
let me state it anyway.
For what I believe is the common case of user vs. supervisor, we
would need to mark rules as "U" or "S." When a newly proposed "U"
rule is to be inserted, we invoke an algorithmic check to determine
whether it would affect any "S" rule. If so, then the attempt to
insert the "U" rule is rejected. In this model one does not need to
define points where "U" rules could be inserted.

Marking an insertion point into the SPD -- bissecting it -- is the
equivalent of what you propose: all the rules ahead of the insertion
point for unprivileged apps are 'S' and all the rules behind it are 'U'.

We need a canonical model only to explain what the correct semantics
are, not to dictate implementation.

I fully expect that some implementations will do something really
simple, like: unprivileged app-driven PROTECT rules go at the back of
the SPD, while privileged app-drive BYPASS rules go at the head of the
SPD. I expect such an implementation to match the semantics of that
we'll describe for PROTECT OR BYPASS (and not because we should describe
what implementations that have this feature do, but because this is
fairly natural).

Nico
--

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent
I had a very simple model in mind, which might be too simplistic, but
let me state it anyway.
For what I believe is the common case of user vs. supervisor, we
would need to mark rules as "U" or "S." When a newly proposed "U"
rule is to be inserted, we invoke an algorithmic check to determine
whether it would affect any "S" rule. If so, then the attempt to
insert the "U" rule is rejected. In this model one does not need to
define points where "U" rules could be inserted.

Marking an insertion point into the SPD -- bissecting it -- is the
equivalent of what you propose: all the rules ahead of the insertion
point for unprivileged apps are 'S' and all the rules behind it are 'U'.

You seem to be assuming that we perform a sort on the (correlated)
SPD to put all S rules above all U rules. If no U rules are allowed
to overlap with any S rules, then that should allow the simple,
two-tier SPD that you are suggesting. I don't recall you explicitly
stating that assumption in prior messages, or maybe I just missed it.
Yes, I thin this would work.

Post by Nicolas Williams
We need a canonical model only to explain what the correct semantics
are, not to dictate implementation.

agreed.

Post by Nicolas Williams
I fully expect that some implementations will do something really
simple, like: unprivileged app-driven PROTECT rules go at the back of
the SPD, while privileged app-drive BYPASS rules go at the head of the
SPD. I expect such an implementation to match the semantics of that
we'll describe for PROTECT OR BYPASS (and not because we should describe
what implementations that have this feature do, but because this is
fairly natural).

Do we agree that the spec needs to have one model that has enough
detail to be unambiguous and testable, like 4301, but also need to
tell implementers that they are free to implement the model in nay
way that exactly matches the model's external behavior?

Steve

[Nicolas Williams]

Post by Stephen Kent

Post by Nicolas Williams

Post by Stephen Kent
I had a very simple model in mind, which might be too simplistic, but
let me state it anyway.
For what I believe is the common case of user vs. supervisor, we
would need to mark rules as "U" or "S." When a newly proposed "U"
rule is to be inserted, we invoke an algorithmic check to determine
whether it would affect any "S" rule. If so, then the attempt to
insert the "U" rule is rejected. In this model one does not need to
define points where "U" rules could be inserted.

Marking an insertion point into the SPD -- bissecting it -- is the
equivalent of what you propose: all the rules ahead of the insertion
point for unprivileged apps are 'S' and all the rules behind it are 'U'.

You seem to be assuming that we perform a sort on the (correlated)
SPD to put all S rules above all U rules. If no U rules are allowed
to overlap with any S rules, then that should allow the simple,
two-tier SPD that you are suggesting. I don't recall you explicitly
stating that assumption in prior messages, or maybe I just missed it.

Indeed, that's my assumption, and I state it explicitly in this thread,
but not in the I-D.

Post by Stephen Kent
Yes, I thin this would work.

Me too :)

Post by Stephen Kent
Do we agree that the spec needs to have one model that has enough
detail to be unambiguous and testable, like 4301, but also need to
tell implementers that they are free to implement the model in nay
way that exactly matches the model's external behavior?

Yes, you and I do, and I suspect that the rest of the WG will agree as
well.

Now I have to go re-read what RFC4301 has to say about the SPD... In
this thread we've not taken into account RFC4301's logical split of the
SPD into three pieces (SPD-S, -I and -O). I'm sure that won't be a
problem.

Nico
--

[Stephen Kent]

Post by Stephen Kent

Post by Nicolas Williams
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

[Michael Richardson]

Post by Stephen Kent
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"

Post by Stephen Kent
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 Kent]

Post by Michael Richardson

Post by Stephen Kent
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

"PROTECT IF REQUESTED"

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

Post by Michael Richardson

Post by Stephen Kent
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

[Michael Richardson]

Post by Michael Richardson

Post by Stephen Kent
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)

Post by Michael Richardson

Post by Stephen Kent
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[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

Post by Michael Richardson
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.

I too wondered about the "but those were entries that all had the same
precedence" bit -- these are ordered lists, so no two rules can have the
"sam precedence."

[Stephen Kent]

Post by Nicolas Williams

Post by Michael Richardson
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.

I too wondered about the "but those were entries that all had the same
precedence" bit -- these are ordered lists, so no two rules can have the
"sam precedence."
_______________________________________________

The issue is not precedence once the list (PAD or SPD) is ordered.
The issue is that given an extant, presumably OK list, if someone
tries to add a new entry at a given location in the ordered database,
are they allowed to do so. If PAD/SPD entries have a label that
indicates the precedence/priority of the each entry, analogous to
user/supervisor state, then maybe one can decide whether the new
entry can be added (at the requested point) based o the comparison
with the extant entries and their labels.

Steve

[Nicolas Williams]

Post by Stephen Kent

Post by Nicolas Williams

Post by Michael Richardson
Your word "precedence" is funny to me, since the entries don't have
the same precedence if they are ordered.

I too wondered about the "but those were entries that all had the same
precedence" bit -- these are ordered lists, so no two rules can have the
"sam precedence."
_______________________________________________

The issue is not precedence once the list (PAD or SPD) is ordered.
The issue is that given an extant, presumably OK list, if someone
tries to add a new entry at a given location in the ordered database,
are they allowed to do so. If PAD/SPD entries have a label that
indicates the precedence/priority of the each entry, analogous to
user/supervisor state, then maybe one can decide whether the new
entry can be added (at the requested point) based o the comparison
with the extant entries and their labels.

This sounds very much like what I meant by insertion points -- you have
to know, or else you have to have some way to figure out where in the
SPD to insert API-driven rules.

(Of course, native implementions might not implement API-driven rules as
rules that are inserted into the SPD as there are other morally
equivalent ways to describe this, but we're trying to stay close to the
RFC4301 model.)

Nico
--

[Stephen Kent]

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

Post by Michael Richardson

Post by Stephen Kent
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.

I was focusing on the requester being the peer, not the application
triggering SA creation.

I am still a bit confused. Are you saying that if an app requests
IPsec protection for a connection then this entry will try to create
an SA, but it will not try to create an SA if the app does not
request it? I guess I tend to think in PAD/SPD -centric terms, not
app-centric terms, which would say create the SA IF possible,
irrespective of whether an app requests it or not.

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
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?

Steve

[Stephen Kent]

<SNIP!>

Post by Stephen Kent
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
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.
Dan

I don't see how this is consistent with the 4301 model of caching SPD entries.

Steve

[Nicolas Williams]

Post by Stephen Kent

<SNIP!>

Post by Stephen Kent
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).

Post by Stephen Kent

Post by Stephen Kent
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.

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

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent

<SNIP!>

Post by Stephen Kent
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.

Post by Nicolas Williams

Post by Stephen Kent

Post by Stephen Kent
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.

Post by Nicolas Williams
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
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

[Michael Richardson]

Post by Stephen Kent

Post by Michael Richardson
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.

I was focusing on the requester being the peer, not the application
triggering SA creation.
I am still a bit confused. Are you saying that if an app requests
IPsec protection for a connection then this entry will try to create
an SA, but it will not try to create an SA if the app does not
request it? I guess I tend to think in PAD/SPD -centric terms, not

Yes. This is not the same as inserting a PAD/SPD entry that creates an SA
upon the first packet (with or without the "populate from packet" option).

Post by Stephen Kent
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

I agree that we need to decide whether or not to "migrate" the traffic or
not. This is an interoperability issue.
The applications which did *NOT* request the SA, are presumably happy
(i.e. "secure") even if they don't get IPsec protection. Probably they don't
even know anything about it. How is this any different than suddenly turning
on that bump-in-the-wire site-to-site IPsec gateway?

I don't like the term "migrate", because I wouldn't have had a "BYPASS"
entry for the traffic in the clear. The traffic went in the clear because it
fell off the end of the SPD, and the default was clear (vs drop).

Post by Stephen Kent
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?

[Nicolas Williams]

Post by Michael Richardson

Post by Stephen Kent
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

"PROTECT IF REQUESTED"

Actually, these rules might not be used at all by administrators, but be
created dynamically by applications. In any case, they are used on both
sides (client and server).

We could just call them TEMPLATE BYPASS OR PROTECT (yes, I still like
the name I picked originally) -- something that indicates: a) the fact
these aren't rules as such but rules that give rise to flow-specific
rules, and b) that the latter may be either BYPASS or PROTECT rules.

Nico
--

[Stephen Kent]

Post by Nicolas Williams

Post by Michael Richardson

Post by Stephen Kent
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
"PROTECT IF REQUESTED"

Actually, these rules might not be used at all by administrators, but be
created dynamically by applications. In any case, they are used on both
sides (client and server).
We could just call them TEMPLATE BYPASS OR PROTECT (yes, I still like
the name I picked originally) -- something that indicates: a) the fact
these aren't rules as such but rules that give rise to flow-specific
rules, and b) that the latter may be either BYPASS or PROTECT rules.
Nico
--
_______________________________________________

I'n not saying this is a bad idea, but I don't think I've seen a
clear description of how the templates fit into the extant 4301
model. maybe we need more details. Also, if apps create the rules,
there is still a need to be able to determine if they conflict with
other rules already created by an admin, in order to be sure that an
admin-controlled access control policy is not subverted.

Steve

[Michael Richardson]

Post by Nicolas Williams
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.