Remember, the goal isn't necessarily to provide the full cross product of all possible permutations, which is what you've done. The goal is to satisfy the customer scenarios. Only if the customer really needs all the cross product permutations, do they come into play.
My argument is that a very good deployment strategy that will meet many customer scenarios is precisely to prune your matrix to make things deterministic to the intermediaries. In terms of your chart, that means that the only allowed combinations (of this scenario) are: Case Nodes Flow S 1 S 2 1 N-N I EN EN 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-NULL, and the encypt flag is critical, as it is the mechanism to enable encryption between uplevel machines. The main point of WESP is to remove heuristics from intermediary processing. Hence we need to focus on the scenarios that actually allow us to do that, and enable as many of them as possible. bs From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, January 06, 2010 10:37 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 5:42 PM +0000 1/6/10, Brian Swander wrote: The uplevel machines can't use ESP to send the encrypted traffic in this scenario. Remember, that we need to look at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP. And we need to satisfy the goal of deterministic intermediary visibility. Hence, the best method I see is what I describe below. The non-WESP machines MUST do ESP-NULL to allow visibility. That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries would see both ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL. bs Sorry, Brian, I still don't understand the scenario. Let's see if a detailed analysis can help. In a mixed environment, there are two classes of machines: WESP-capable and not. That yields 3 types of connections, and 6 types of flows. Let's label end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP), W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL). The following table shows the flows and protocols that could result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WESP. Case Nodes Flow S 1 S 2 1 N-N I EN EN 2 N-N E EE EE 3 W-W I W W 4 W-W E EE W* 5 W-N I EN EN 6 W-N E EE EE The only place W* can be used is in case 4 (in Scenario 2), where both nodes are WESP-capable and the traffic is encrypted. But, in both scenarios, an intermediate device will encounter ESP traffic that may or may not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nodes. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous info for deciding whether a packet can be inspected. This analysis suggests that there is no need for the flag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes. Steve
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
