I trust my clarification (to Yaron) addressed these questions. Let me know if there are any outstanding.
bs From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, January 06, 2010 11:45 AM To: Brian Swander Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro Subject: Re: [IPsec] Traffic visibility - consensus call At 7:06 PM +0000 1/6/10, Brian Swander wrote: 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. I don't recall the WG having agreed upon a subset of cases that were deemed to be the only ones of interest. But, I admit to having missed some details of WESP as it evolved too, so maybe I missed this too. Can you refresh my memory on this point? 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. This seems a lot like saying that we can convince customers that they need only a subset of the possible cases because these are the ones that we can address well! 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 I don't understand how one arrives at this subset. Why are legacy nodes prohibited form sending encrypted traffic in this context? Is the idea that this limitation will motivate deployment of WESP-enabled nodes? I don't think the rationale here has been clearly articulated. 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. This seems to relate to my questions above. 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. I don't think it is reasonable to consider only those cases where the encrypted content flag will make things better, unless we have a very good, and agreed-upon, rationale for discarding the other cases. Steve
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
