Hi Steve,
[No hat.]
Thanks for the analysis, I hope this'll help the discussion to converge.
You are taking an either-or approach in the last paragraph below. But assuming
that WESP is useful (bear with me...), there will be a gradual deployment
within any given network. I agree that heuristics will still be needed, until
the last endpoint is WESP-enabled (i.e., forever). But if we adopt W*, during
the migration less and less heuristic processing will be needed. Much of this
discussion is about performance, so quantitative arguments are also useful.
Thanks,
Yaron
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Stephen Kent
Sent: Wednesday, January 06, 2010 20:37
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
