Re: [IPsec] Traffic visibility - consensus call

Venkatesh said: > I agree that WESP should not be clipped to only support ESP-NULL; it > should be able to carry encrypted packets as well. Without this the > middle boxes would never know whether the ESP packet thats passing is > encrypted or not. Earlier, Manav said: > Now, assume that we limit

Re: [IPsec] Traffic visibility - consensus call

At 11:14 AM -0700 1/5/10, Grewal, Ken wrote: Yes to both, based on arguments already discussed numerous times in the WG via presentations, 12 iterations of the draft and multiple WG last calls + AD reviews! The main motivation for extending the ICV was to counter some of the issues originally

Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

Gabriel, ... One may argue whether that consistency check is best served by extending the ICV to include the WESP header fields (per the current WG consensus as expressed in the existing draft), or whether that is best done by the end nodes checking the fields explicitly. My reply to Ken a

Re: [IPsec] Traffic visibility - consensus call

At 10:10 PM + 1/5/10, Brian Swander wrote: I'll resend my message from earlier today that gives a concrete scenario for why the WESP encryption bit is in charter. To satisfy the existing charter item, we need a deployable solution, which entails working with legacy systems that don't supp

Re: [IPsec] Traffic visibility - consensus call

I would like to reframe the migration discussion. Manav, Scott and everyone else, please correct me if I got it wrong. Suppose we have a middlebox that can do useful things if it knows that the flow is unencrypted, and only basic things if it is encrypted. A load balancer is a good example. We

Re: [IPsec] Traffic visibility - consensus call

Yes and Yes. I supported WESP from the beginning, because it allows intermediate systems to perform DPI on ESP-NULL packets. I was not in favor of heuristics - not because it is a bad solution (on the contrary) - but because many products we have/make today could not be upgraded to support it. M

Re: [IPsec] Traffic visibility - consensus call

Jack: The name sets incorrect expectations, but that is not on my list of concerns. Russ On 1/5/2010 7:01 PM, Jack Kohn wrote: Russ, It is a replacement (as opposed to a wrapper) if the portions of the packet that are covered by the ICV are different. Would it help if WESP is renamed t

Re: [IPsec] Traffic visibility - consensus call

At 9:45 AM +0530 1/6/10, Venkatesh Sriram wrote: > Would it help if WESP is renamed to something else? Since we're discussing the fundamental principles of the protocol, i see no reason why we cant change the name, if that helps. I think its the "Wrapped" in the WESP thats causing most heart

Re: [IPsec] Traffic visibility - consensus call

At 5:19 PM +0200 1/6/10, Yaron Sheffer wrote: I would like to reframe the migration discussion. Manav, Scott and everyone else, please correct me if I got it wrong. Suppose we have a middlebox that can do useful things if it knows that the flow is unencrypted, and only basic things if it is e

Re: [IPsec] Traffic visibility - consensus call

Take a look at the policy sketch I sent our yesterday for how to roll this out in a mixed mode environment. That should clarify all your questions. bs From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott C Moonen Sent: Wednesday, January 06, 2010 5:38 AM To: Venka

Re: [IPsec] Traffic visibility - consensus call

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 vis

Re: [IPsec] Traffic visibility - consensus call

Not wearing any hat: At 10:10 PM + 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete scenario for >why the WESP encryption bit is in charter. > >To satisfy the existing charter item, we need a deployable solution, which >entails working with lega

Re: [IPsec] Traffic visibility - consensus call

But that doesn't give us any path to actually do encryption (in environments with legacy systems) - hence the proposal is untenable. I'd argue it therefore doesn't satisfy the charter item. The charter item is a deployable mechanism that lets intermediaries inspect ESP-NULL when present. Th

Re: [IPsec] Traffic visibility - consensus call

On Wed, Jan 6, 2010 at 8:49 PM, Yaron Sheffer wrote: > I would like to reframe the migration discussion. Manav, Scott and everyone > else, please correct me if I got it wrong. > > Suppose we have a middlebox that can do useful things if it knows that the > flow is unencrypted, and only basic thi

Re: [IPsec] Traffic visibility - consensus call

On Wed, Jan 6, 2010 at 2:52 AM, Dragan Grebovich wrote: > Yes and Yes. > > I supported WESP from the beginning, because it allows intermediate > systems to perform DPI on ESP-NULL packets.  I was not in favor of > heuristics - not because it is a bad solution (on the contrary) - but > because many

Re: [IPsec] Traffic visibility - consensus call

No hat. At 5:56 PM + 1/6/10, Brian Swander wrote: >But that doesn't give us any path to actually do encryption (in environments >with legacy systems) - hence the proposal is untenable. That doesn't make sense: it is *exactly* the same path as we have today. WESP-as-envisioned gives us one e

Re: [IPsec] Traffic visibility - consensus call

At 5:42 PM + 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 sat

[IPsec] What problem are we REALLY trying to solve? (was Traffic visibility)

> Transport policies for within an organization that want to enable > intermediary inspection of ESP-NULL non-heurisitically. Organization has a > mix of version of systems. At this point I need more details. Specifically, why does an organization need to inspect ESP-NULL packets? I can think

Re: [IPsec] Traffic visibility - consensus call

Hi, No and no. I'm a little alarmed at the assumption by some that ESP would be deprecated (albeit "not for a long time"). AH does not really solve the problem supposedly solved by WESP because it doesn't work through a NAT. So if we're going to have a new protocol that needs to be impleme

Re: [IPsec] Traffic visibility - consensus call

Hi Steve, Please reread my text. I was (in that paragraph) taking Manav's side, i.e. assuming there's value in deterministic distinction between encrypted and unencrypted ESP, and hence, gradually moving the endpoints to WESP so that middleboxes have an easier time. As we know, this opinion is

Re: [IPsec] Traffic visibility - consensus call

Brian, the middle box could never "assume that ESP always means ESP-NULL" because the down-level nodes (as well as any up-level node talking to them) will use ESP for encrypted traffic as well. Moreover, this is a soft sort of begging the question because it is assuming that WESP will be widely

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 v

Re: [IPsec] Traffic visibility - consensus call

See my response to Stephen Kent, and let me know if that doesn't clarify adequately. bs From: Scott C Moonen [mailto:smoo...@us.ibm.com] Sent: Wednesday, January 06, 2010 11:00 AM To: Brian Swander Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org; ipsec-boun...@ietf.org; Stephen Kent Subje

Re: [IPsec] Traffic visibility - consensus call

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

Re: [IPsec] Traffic visibility - consensus call

At 8:56 PM +0200 1/6/10, Yaron Sheffer wrote: Hi Steve, Please reread my text. I was (in that paragraph) taking Manav's side, i.e. assuming there's value in deterministic distinction between encrypted and unencrypted ESP, and hence, gradually moving the endpoints to WESP so that middleboxes h

Re: [IPsec] Traffic visibility - consensus call

I'd like to understand your policies for deploying your proposal below that meets the charter item. Here are the customer scenario requirements: Legacy systems that don't support WESP (lots of them) Requirements to do encryption between some machines. Willing to upgrade pockets of machines to a

Re: [IPsec] Traffic visibility - consensus call

I never meant to imply WESP would reduce encryption requirements. If the customer traffic has to be encrypted, then it will be or the scenario isn't satisfied.In the below, to meet that customer requirement, the customer would need to upgrade the machines that require encryption to the lat

Re: [IPsec] Traffic visibility - consensus call

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 heuristic

Re: [IPsec] Traffic visibility - consensus call

At 7:06 PM + 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

Re: [IPsec] Traffic visibility - consensus call

Steve, The either-or on using an ICV or explicitly checking the WESP header on the recipient was based on the assumption that the threat does not come from the sender and only from some other malicious entity after the packet has been sent. This was the reason for simplifying the header check

Re: [IPsec] Traffic visibility - consensus call

Hi Brian, [No hat] If your intermediary is something like a load balancer, and you don't care that some portion of your traffic is not balanced well, then fine - you don't need heuristics. But if the intermediary is a security device, then I would only buy one that implemented heuristics, eve

Re: [IPsec] Traffic visibility - consensus call

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; gabr

Re: [IPsec] Traffic visibility - consensus call

That's a cost/benefit business decision for the intermediary.Some intermediaries may welcome the option to not support heuristics at all. They'll need to do the market research, etc on the various scenarios. But it is my goal to understand exactly what scenarios require heuristics, and ena

Re: [IPsec] Traffic visibility - consensus call

At 9:34 PM +0200 1/6/10, Yaron Sheffer wrote: 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 w

Re: [IPsec] Traffic visibility - consensus call

At 12:48 PM -0700 1/6/10, Grewal, Ken wrote: Steve, The either-or on using an ICV or explicitly checking the WESP header on the recipient was based on the assumption that the threat does not come from the sender and only from some other malicious entity after the packet has been sent. This was

[IPsec] this discussion

Folks, The flurry of messages that have been exchanged today and yesterday have often struck me as incorporating rather vague arguments. I find myself having to do a lot of work to fill in the blanks for not well-articulated comments, construct detailed analyses, and postulate rationales for

Re: [IPsec] Traffic visibility - consensus call

At 7:55 PM + 1/6/10, Brian Swander wrote: I trust my clarification (to Yaron) addressed these questions. Let me know if there are any outstanding. I understood the first two lines about lots of legacy systems, only a few of which need to perform encryption." The next two lines were too

Re: [IPsec] Traffic visibility - consensus call

I've been watching a long stream of messages about WESP flying by and I must admit to being rather confused. What follows is based on my best understanding of what's going on, so please apply grains of salt as needed. It's likely that I'm in the same corner as Tero. It sounds to me like WESP w

Re: [IPsec] Traffic visibility - consensus call

On Tue, 2010-01-05 at 00:27 +0200, Yaron Sheffer wrote: > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. > This has been done to counter certain attacks, but it means that WESP > is

Re: [IPsec] Traffic visibility - consensus call

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 requ

Re: [IPsec] Traffic visibility - consensus call

Paul, My 2 cents... Some people have jumped to conclusions that because we want to differentiate between encrypted and non-encrypted traffic by explicitly signaling in the packet, that WESP is now a replacement for ESP. THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! One item that may h

[IPsec] Traffic visibility - consensus call

Responding to Yaron's request for group input on two questions pertaining to WESP draft On question #1 (ICV calculation): I don't agree with design decision to include WESP header in ESP trailer's ICV. I see it as unnecessary contamination of ESP protocol. On question #2 (Allowing WESP as a

Re: [IPsec] Traffic visibility - consensus call

Hi Ken, No one responded to my suggestion so I'll suggest it again below. On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: [snip] > The bottom line is that in order for a network appliance (Trusted > Intermediary) to offer critical network services (IDS/IPS/DPI/Access > Control) in IPsec

Re: [IPsec] Traffic visibility - consensus call

On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote: > Paul, > > this topic! :-)> > > My 2 cents... > > Some people have jumped to conclusions that because we want to differentiate > between encrypted and non-encrypted traffic by explicitly signaling in the > packet, that WESP is now a repl

Re: [IPsec] Traffic visibility - consensus call

>> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption >> within a given domain / environment. How does an intermediate device know >> that this policy is being enforced? What if ESP is still being used

Re: [IPsec] Traffic visibility - consensus call

Hi Dan, I think the main motivation for using ESP and providing a wrapper was so we do not have to reinvent the wheel / redo all the work that has been done already. Starting off from scratch on a new protocol would have meant a larger workload and this item was meant to be a simple wrapper to p

Re: [IPsec] Traffic visibility - consensus call

Joy, Yes, your understanding is correct - WESP with the encryption flag allows intermediaries to determine if the payload is encrypted or NULL-encrypted and act accordingly. Thanks, - Ken >-Original Message- >From: Joy Latten [mailto:lat...@austin.ibm.com] >Sent: Wednesday, January

[IPsec] New IKEv2 parameter listing at IANA

Greetings again. All IKEv2 developers: please review , which has a few of the registries updated and reformatted. If you see anything wrong, please contact Yaron and Tero and I. Thanks! --Paul Hoffman, Director --VPN Consortium _

Re: [IPsec] Traffic visibility - consensus call

Hi Jack, My suggestion in not just a semantic one. The protocol would be different because it would not wrap an existing, ESP-encapsulated packet. There would be no "additional attributes", no "next header" duplication, no processing overhead to check whether data is the same in two places, a

Re: [IPsec] Traffic visibility - consensus call

Oh sigh!! What is it about IPsec that makes people go down this same path every time: 1) Someone proposes an utterly simple and useful piece of functionality (in this case, some way to indicate where the encapsulated data begins in the case where ESP is carrying unencrypted data. 2) The proposa

Re: [IPsec] Traffic visibility - consensus call

On Jan 7, 2010, at 9:14 AM, Charlie Kaufman wrote: > Oh sigh!! What is it about IPsec that makes people go down this same path > every time: IPsec? So I guess you haven't been following the TLS mailing list these past couple of months. I don't think anyone's described a practical attack on

Re: [IPsec] Clarifying what happens with INITIAL_CONTACT

There was a lot of debate in the original IPsec working group about INITIAL_CONTACT. We should be careful not to add any MUSTs that would make noticing it mandatory, since that would complicate minimal implementations. It would be reasonable to say that if an IKE SA is deleted in response to an