Hi Brian,
[no hat on]
I think your reasoning about the different scenarios actually demonstrates that
"super-WESP" is useful. But I have to strongly disagree with the statement
below. Yes we should support all possible permutations. There's no reason why
WESP should suddenly cause traffic that used to require encryption to not
require it any more.
So I would put it differently: the WESP encrypt flag is what enables
intermediaries to be implemented *efficiently* in a mixed environment, with old
and new endpoints, encrypted and integrity-protected traffic.
Thanks,
Yaron
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Brian
Swander
Sent: Wednesday, January 06, 2010 21:07
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call
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
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
