Slight rewording of the first sentence for more clarity: In this scenario, the sum of functionality is greater than the parts - end hosts and intermediaries working together can better satisfy the customer's holistic deployment requirements (security, load balancing, auditing, etc) than either working in isolation and in complete distrust of the other.
-----Original Message----- From: Brian Swander Sent: Thursday, January 07, 2010 9:14 AM To: 'Stephen Kent' Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: RE: [IPsec] Traffic visibility - consensus call 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 -----Original Message----- From: Stephen Kent [mailto:k...@bbn.com] Sent: Thursday, January 07, 2010 8:10 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 10:17 PM +0000 1/6/10, Brian Swander wrote: >I trust that this is a question on the sample set of requirements >for the scenario I sent to Paul. > >I use infrastructure and intermediaries terms interchangeably. > >The scenario I had in mind is: > >No heuristic support from any network infrastructure. > >Only limited number of legacy clients that require encryption, hence >they are capable of upgrading. >Vast majority of legacy are ok with ESP-NULL. > >Potentially many uplevel clients that require encryption. As on >the previous thread, we want to enable as many capabilities in the >cross product matrix as possible. Hence it is extremely desirable >for uplevel to do encryption or integrity without forcing extra >infrastructure config. > > I.e. I'd assume that managing ip addresses on all uplevel machines >that want to do encryption is prohibitive. Color me confused. It appears that the high level policy is: - pairs of "uplevel" (WESP-capable) machines are allowed to send data via encrypted SAs, and thus bypass the packet inspection that the intermediate systems would otherwise perform - if either machine in a communicating pair is not "uplevel" then any SAs between them must be subject to inspection by the intermediate systems, and hence they are restricted to using ESP-NULL (or no IPsec at all). What confuses me is how the intermediate systems will know which policy applies to any given traffic flow? If the intermediate systems have a list of IP addresses of the hosts that fall into the category of "allowed to encrypt traffic" that would work, but that approach relies on doing what you said would be prohibitive to manage. Even if one needs only to configure one of the addresses or authorized pairs, that is the same as what would be needed in my proposal, and thus is also viewed as too hard to manage. But what other means of informing the intermediate systems how to decide to treat these two different classes of traffic do you envision? I hope that you're not suggesting that the answer is to rely on each node to behave properly and to use only the type of SA for which it is authorized. If we had sufficient confidence in these nodes to do that, we probably wouldn't need intermediate systems to perform packet inspection, right? Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
