I'm going by what my real customers are asking for. Our real customers are asking for exactly what I'm describing below. I didn't ask them why their stance to intermediaries has changed, if it even has. That is academic. The key question here is what do real customers want to deploy, and how can we enable them to do it.
bs -----Original Message----- From: Stephen Kent [mailto:k...@bbn.com] Sent: Thursday, January 07, 2010 11:09 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley Subject: RE: [IPsec] Traffic visibility - consensus call 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
