At 5:13 PM +0000 1/7/10, Brian Swander wrote:
In this scenario, the sum of functionality is
greater than the parts - end hosts and
intermediaries working together can achieve
better overall security than either working in
isolation and in complete distrust of the other.
It'll be up to the individual customer on where
to dial the knobs, and we should enable the
options and make them as deployable as possible.
I.e. if customers really want to manage full IP
address policies for who can do encrypted ESP,
than that option should be available. If they
want good intermediary audit trails with a
simpler intermediary config, that option needs
to be available. If they want best effort load
balancing/WAN optimization, that option needs to
be available.
This is no longer an either-or adversarial
situation between end systems and
intermediaries, and the intermediaries in play
are not relegated to security intermediaries -
although clearly security intermediaries are
important here, too.
bs
Brian,
I was really hoping for a simple answer to the
questions I posed in my message. Instead IO got a
message with words like "holistic" and phrases
like "the sum of functionality is greater than
the partsĀ" which is a bit too new age for me :.
I'm guessing that hints to the answer I was
looking for are lurking in your second paragraph:
It'll be up to the individual customer on where
to dial the knobs, and we should enable the
options and make them as deployable as possible.
I.e. if customers really want to manage full IP
address policies for who can do encrypted ESP,
than that option should be available. If they
want good intermediary audit trails with a
simpler intermediary config, that option needs
to be available. If they want best effort load
balancing/WAN optimization, that option needs to
be available.
In interpret this to mean that yes, you realize
that an intermediate system that wants to enforce
the sort of policies you previously described
would, in fact, have to be configured with IP
address info (or its moral equivalent) in order
to enforce such policies. In this case your
argument against my suggested approach to dealing
with incremental deployment of WESP disappears
(which may be why you chose to not make this
statement directly :)).
You seem to offer an alternative, i.e., to give
customers the ability to have intermediaries
inspect or not inspect traffic based solely on
what the traffic labels indicate. This amounts
trusting the hosts to label traffic properly,
which is the alternative answer I postulated and
criticized. Again, you chose not to answer this
directly, but instead alluded (in your last
paragraph) to the need to think of end systems
and intermediaries as no longer operating in an
adversarial environment. Historically, the
principle motivations for security intermediaries
include countering (security relevant)
misconfiguration of hosts, an inability to manage
the (security relevant) configurations of hosts,
dealing with compromise of hosts, etc. These are
all instances where the intermediaries do not
trust the end systems. Please elaborate on why
you believe that these are now outmoded reasons
for how security intermediaries should relate to
hosts.
You describe allowing intermediaries to generate
audit trails (presumably capturing some info
about the encrypted traffic that they were unable
to inspect, but you didn't say specifically) as
an alternative to policy enforcement. There may
be some merit to this in some contexts, but I
think the WG needs to have a clear picture of
what is being proposed and the associated
rationale. I searched the IPSECME archives and
found only one set of messages inn 2009 that
include the word "audit" in the context of this
discussion. These messages were a thread
involving Ken and Tero, and appeared in the
2/4-11 timeframe. The messages focused on the
performance and cost issues associated with
implementing stateful vs. stateless
intermediaries, as part of the larger debate on
heuristics vs. explicit packet labeling. This
thread did not raise the issue you did above,
i.e., that a major motivation for WESP is to
enable users to "audit" encrypted traffic flows
as an alternative to using access control info to
permit/deny such flows.
I don't think the WG should make major design
decisions without a clear picture of the various
use cases that are being cited, but which lack
detailed descriptions and thoroughly-articulated
assumptions. I think the WG needs such
descriptions and associated analysis to guide its
decisions.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
