At 3:02 PM +0530 1/11/10, Bhatia, Manav (Manav) wrote:
Dan,
You trust the end nodes to negotiate WESP and encapsulate their ESP
packets in WESP but you don't trust the content they put into those
packets. Is that the trust model you're operating on?
No.
We trust the end nodes to put th
m]
>Sent: Monday, January 11, 2010 12:29 AM
>To: Grewal, Ken
>Cc: ipsec@ietf.org
>Subject: RE: [IPsec] Traffic visibility - consensus call
>
>Ken Grewal wrote:
>
>> The either-or on using an ICV or explicitly checking the WESP header
>> on the recipient was based o
Manav,
On Mon, January 11, 2010 1:32 am, Bhatia, Manav (Manav) wrote:
> Dan,
>
>>
>> You trust the end nodes to negotiate WESP and encapsulate their ESP
>> packets in WESP but you don't trust the content they put into those
>> packets. Is that the trust model you're operating on?
>
> No.
>
>
xplicitly checking the WESP
> header at the
> > endnodes.
> >
> > Cheers, Manav
> >
> >> -Original Message-
> >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> >> On Behalf Of pasi.ero...@nokia.com
> >> Sent: Monday, Jan
age-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
>> On Behalf Of pasi.ero...@nokia.com
>> Sent: Monday, January 11, 2010 1.59 PM
>> To: ken.gre...@intel.com
>> Cc: ipsec@ietf.org
>> Subject: Re: [IPsec] Traffic visibility - consensus call
>&
nokia.com
> Sent: Monday, January 11, 2010 1.59 PM
> To: ken.gre...@intel.com
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
> Ken Grewal wrote:
>
> > The either-or on using an ICV or explicitly checking the WESP header
> > on the
Ken Grewal wrote:
> 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 simplifyin
visibility - consensus call
Hi,
We have had a few "discusses" during the IESG review of the WESP draft. To
help resolve them, we would like to reopen the following two questions to WG
discussion. Well reasoned answers are certainly appreciated. But plain "yes"
or "no" would
f.org; Russ Housley; Stephen Kent; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call
[I finally managed to catch up all the tons of emails to the
ipsec-list, so now I can finally reply to few of them.]
Brian Swander writes:
> In terms of your chart, that means that
On Thu, Jan 07, 2010 at 06:10:10PM -0600, Nicolas Williams wrote:
> On Tue, Jan 05, 2010 at 12:27:26AM +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 head
Grewal, Ken writes:
> 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!
That is true,
[I finally managed to catch up all the tons of emails to the
ipsec-list, so now I can finally reply to few of them.]
Brian Swander writes:
> In terms of your chart, that means that the only allowed
> combinations (of this scenario) are:
>
> CaseNodes FlowS 1 S 2
> 1 N-N I
is off?
Thanks,
--Joe
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Brian
Swander
Sent: Thursday, January 07, 2010 3:59 PM
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley
Subject: Re: [IPsec] Traffic visibility - consensus call
Take 3 sim
On Tue, Jan 05, 2010 at 12:27:26AM +0200, Yaron Sheffer wrote:
> We have had a few "discusses" during the IESG review of the WESP
> draft. To help resolve them, we would like to reopen the following two
> questions to WG discussion. Well reasoned answers are certainly
> appreciated. But plain "yes"
rt of justification is needed to progress here?
bs
-Original Message-
From: Stephen Kent [mailto:k...@bbn.com]
Sent: Thursday, January 07, 2010 3:41 PM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley
Subject: Re: [IPsec] Traffic visibility - consensus call
At 8:06 PM + 1/7/10,
decisions
>> that depend on this distinction.
>>
>> And this is why a smooth migration is so important. Over time you get a
>> larger and larger portion of the network to play by the rules.
>>
>> Thanks,
>> Yaron
>>
>> -Original Messag
At 8:06 PM + 1/7/10, Brian Swander wrote:
I'm going by what my real customers are asking for.
Our real customers are asking for exactly what I'm describing below.
I didn't ask them why their stance to intermediaries has changed, if
it even has. That is academic. The key question here is
Original Message-----
> From: Dan Harkins [mailto:dhark...@lounge.org]
> Sent: Thursday, January 07, 2010 19:57
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] Traffic visibility - consensus call
>
>
> Hi Yaron,
>
> Yes, one way was chosen but it has
010 19:57
To: Yaron Sheffer
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Traffic visibility - consensus call
Hi Yaron,
Yes, one way was chosen but it has morphed into something much more
than simply indicating ESP-null traffic. What I'm suggesting is that if
the goal is simply a good way to i
to deploy,
and how can we enable them to do it.
bs
-Original Message-
From: Stephen Kent [mailto:k...@bbn.com]
Sent: Thursday, January 07, 2010 11:09 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley
Subject: RE: [IPsec] Traffic visibility - consensus call
At 5:13 PM + 1/7/10
At 5:13 PM + 1/7/10, Brian Swander wrote:
In this scenario, the sum of functionality is
greater than the parts - end hosts and
intermediaries working together can achieve
better overall security than either working in
isolation and in complete distrust of the other.
It'll be up to the in
t; Dan Harkins
> Sent: Thursday, January 07, 2010 2:04
> To: Grewal, Ken
> Cc: ipsec@ietf.org; Paul Koning; Stephen Kent
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
>
> Hi Ken,
>
> No one responded to my suggestion so I'll suggest it again below.
ither working in isolation and in complete distrust of the other.
-Original Message-
From: Brian Swander
Sent: Thursday, January 07, 2010 9:14 AM
To: 'Stephen Kent'
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: RE: [IPsec] Traffic visibility - consensus call
I
aries - although clearly security intermediaries are important here,
too.
bs
-Original Message-
From: Stephen Kent [mailto:k...@bbn.com]
Sent: Thursday, January 07, 2010 8:10 AM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visib
wal, Ken
>Cc: ipsec@ietf.org
>Subject: RE: [IPsec] Traffic visibility - consensus call
>
>Hi Joy,
>
>Sorry but this is not the case. Quoting your text below: "The use of the
>"USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that
>WESP-capable node
At 10:17 PM + 1/6/10, Brian Swander wrote:
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.
Hi,
On Mon, Jan 4, 2010 at 11:27 PM, Yaron Sheffer wrote:
> Hi,
>
> We have had a few "discusses" during the IESG review of the WESP draft. To
> help resolve them, we would like to reopen the following two questions to WG
> discussion. Well reasoned answers are certainly appreciated. But plain "y
.org; Paul Koning; Stephen Kent
Subject: 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
tf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Joy
Latten
Sent: Thursday, January 07, 2010 2:16
To: Grewal, Ken
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call
On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote:
> Paul,
>
> this topic! :-)>
>
&g
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
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
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
Wednesday, January 06, 2010 4:16 PM
>To: Grewal, Ken
>Cc: ipsec@ietf.org
>Subject: Re: [IPsec] Traffic visibility - consensus call
>
>On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote:
>> Paul,
>>
>> messages on this topic! :-)>
>>
>> My 2 cents...
>>
nal Message-
>From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>Of Dan Harkins
>Sent: Wednesday, January 06, 2010 4:04 PM
>To: Grewal, Ken
>Cc: ipsec@ietf.org; Paul Koning; Stephen Kent
>Subject: 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
what it set out to do - an easy
> and reliable way to tell if an IPsec packet has a NULL payload or if it is
> encrypted.
>
> Thanks,
> - Ken
>
>
> >-Original Message-
> >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> >O
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
.sanc...@hp.com
--
Message: 1
Date: Tue, 5 Jan 2010 00:27:26 +0200
From: Yaron Sheffer
Subject: [IPsec] Traffic visibility - consensus call
To: "ipsec@ietf.org"
Message-ID:
<7f9a6d26eb51614fbf9f81c0da4cfec801bdf887a...@il-ex01.ad.checkpoint.com>
Conten
encrypted.
Thanks,
- Ken
>-Original Message-
>From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>Of Paul Koning
>Sent: Wednesday, January 06, 2010 1:43 PM
>To: Stephen Kent
>Cc: ipsec@ietf.org
>Subject: Re: [IPsec] Traffic visibility - consensus ca
esday, January 06, 2010 1:01 PM
To: Brian Swander
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro; Stephen Kent
Subject: 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 kn
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
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
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
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
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
os can leverage them, too).
bs
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Wednesday, January 06, 2010 11:54 AM
To: Brian Swander; Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus
; gabriel montenegro
Subject: 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
ec@ietf.org; Russ Housley; gabriel montenegro
Subject: 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
misnomer!
Thanks,
- Ken
>-Original Message-
>From: Stephen Kent [mailto:k...@bbn.com]
>Sent: Wednesday, January 06, 2010 6:28 AM
>To: Grewal, Ken
>Cc: Yaron Sheffer; ipsec@ietf.org
>Subject: Re: [IPsec] Traffic visibility - consensus call
>
>At 11:14 AM -0700 1
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
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 + 1/6/10, Brian Swander
tegrity-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 -
ontenegro; Russ Housley
Cc: ipsec@ietf.org
Subject: 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
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
raffic.
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&#
Kent
Subject: 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
f
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 + 1/6/10, Brian Swander wrote:
The uplevel machines can't use ESP to send the encrypted
v4. ;)
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Brian Swander
To:
Stephen Kent
Cc:
"ipsec@ietf.org" , Russ Housley ,
gabriel montenegro
Date:
01/06/2010 12:42 PM
Subject:
Re: [IPsec] Traffic visibilit
is opinion is not shared by everyone.
Thanks,
Yaron
-Original Message-
From: Stephen Kent [mailto:k...@bbn.com]
Sent: Wednesday, January 06, 2010 19:10
To: Yaron Sheffer
Cc: Scott C Moonen; Venkatesh Sriram; ipsec@ietf.org; ipsec-boun...@ietf.org
Subject: Re: [IPsec] Traffic
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
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
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
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
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
ss Housley
Cc: ipsec@ietf.org
Subject: 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
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
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 deployabl
: Venkatesh Sriram
Cc: ipsec@ietf.org; ipsec-boun...@ietf.org
Subject: 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 wo
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
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
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
ragan
-Original Message-
Date: Tue, 5 Jan 2010 00:27:26 +0200
From: Yaron Sheffer
Subject: [IPsec] Traffic visibility - consensus call
To: "ipsec@ietf.org"
Hi,
We have had a few "discusses" during the IESG review of the WESP draft.
To help resolve them, we
o:ipsec-boun...@ietf.org] On Behalf Of Scott
C Moonen
Sent: Wednesday, January 06, 2010 15:38
To: Venkatesh Sriram
Cc: ipsec@ietf.org; ipsec-boun...@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call
Venkatesh said:
> I agree that WESP should not be clipped to only support
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
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
.org"
Date:
01/05/2010 11:16 PM
Subject:
Re: [IPsec] Traffic visibility - consensus call
> 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
> 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 burn, lets change that to
> something else .. som
Yes to both.
Zhen
China Mobile
On Tue, Jan 5, 2010 at 6:27 AM, Yaron Sheffer wrote:
> Hi,
>
> We have had a few "discusses" during the IESG review of the WESP draft. To
> help resolve them, we would like to reopen the following two questions to WG
> discussion. Well reasoned answers are certain
concerns.
thanks,
Gabriel
- Original Message
> From: Russ Housley
> To: gabriel montenegro
> Cc: "ipsec@ietf.org"
> Sent: Tue, January 5, 2010 2:52:24 PM
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
> Gabriel:
>
> > Some of us belie
Hi Russ,
> > - A standards-track mechanism that allows an intermediary
> device, such
> > as a firewall or intrusion detection system, to easily and reliably
> > determine whether an ESP packet is encrypted with the NULL
> cipher; and
> > if it is, determine the location of the actual paylo
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 to something else? Since we're
discussing the fundamental principles of the protocol, i see no reason
why we cant change the name, if
> There is a need per the charter for a mechanism to
> "easily and reliably" determine the type of traffic. Within an organization,
> it would be much easier to use
> WESP encryption as an alternative to ESP. If one sees ESP packets, then one
> would have to run heuristics
> with all the pertaini
> Even if WESP is approved for use with encrypted traffic, that does not mean
> that it will supplant ESP. ESP still has a smaller header than WESP, so for
> environments where there is no intent to accommodate middlebox snooping, ESP
> is still preferable.
I agree with Steve here that extending
Gabriel Montenegro wrote:
> Just to be clear: I'm not saying that WESP is a general replacement for ESP.
> As Steve Kent points out, where there are no trusted intermediary inspection
> devices (i.e., outside of medium to large organizations) there is no need
> for end-nodes to collaborate wit
Yaron,
On Tue, Jan 5, 2010 at 3:57 AM, Yaron Sheffer wrote:
> Hi,
>
> We have had a few "discusses" during the IESG review of the WESP draft. To
> help resolve them, we would like to reopen the following two questions to WG
> discussion. Well reasoned answers are certainly appreciated. But plai
Gabriel:
Some of us believe that allowing WESP to carry encrypted packets is within the
charter
(there's some recent messages today to this effect). Unfortunately, there's
been wording along the lines
that the working group realized it was going off-charter, but no such
conclusion has been
ar
riginal Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
gabriel montenegro
Sent: Tuesday, January 05, 2010 1:32 PM
To: Russ Housley
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call
Hi Russ,
Some of us believe that allowing WESP to
--- Original Message
> From: Russ Housley
> To: gabriel montenegro
> Cc: "ipsec@ietf.org"
> Sent: Tue, January 5, 2010 1:11:19 PM
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
> Gabriel:
>
> This is being discussed to resolve the concerns tha
Gabriel:
This is being discussed to resolve the concerns that I raised in IESG
Evaluation.
When this work was chartered, I expected as simple wrapper. The charter
says:
> - A standards-track mechanism that allows an intermediary device, such
> as a firewall or intrusion detection system, t
design decisions.
Mark
-Original Message-
Date: Tue, 5 Jan 2010 00:27:26 +0200
From: Yaron Sheffer
Subject: [IPsec] Traffic visibility - consensus call
To: "ipsec@ietf.org"
Hi,
We have had a few "discusses" during the IESG review of the WESP draft. To help
resolve th
it to satisfy the current WESP charter
item.
bs
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Monday, January 04, 2010 2:27 PM
To: ipsec@ietf.org
Subject: [IPsec] Traffic visibility - consensus call
Hi,
We have had
At 11:25 AM -0800 1/5/10, gabriel montenegro wrote:
>I fully agree that a consensus call is an integral part of the IETF process.
>
>But what we're seeing here is not one but a plurality of consensus calls.
The two questions that Yaron asked are related to the questions from the IESG.
>I would ha
, etc.
What we're seeing is: oh, ok, let's do it all over again.
- Original Message
> From: Paul Hoffman
> To: gabriel montenegro ; "ipsec@ietf.org"
>
> Sent: Tue, January 5, 2010 11:14:36 AM
> Subject: Re: [IPsec] Traffic visibility - consensus cal
At 11:08 AM -0800 1/5/10, gabriel montenegro wrote:
>But I'd also like to question the process being followed.
And I would like to answer. In short: the IESG is responsible for the output of
the IETF. This is one such output. The IESG chartered the WG for a particular
item, and there is a questi
ious to VPN folks.
Gabriel
- Original Message
> From: "Grewal, Ken"
> To: Yaron Sheffer ; "ipsec@ietf.org"
> Sent: Tue, January 5, 2010 10:14:43 AM
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
> Yes to both, based on arguments alrea
c-boun...@ietf.org] On Behalf
>Of Yaron Sheffer
>Sent: Monday, January 04, 2010 2:27 PM
>To: ipsec@ietf.org
>Subject: [IPsec] Traffic visibility - consensus call
>
>Hi,
>
>We have had a few "discusses" during the IESG review of the WESP draft.
>To help resolve them
At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote:
Hi,
We have had a few "discusses" during the IESG review of the WESP
draft. To help resolve them, we would like to reopen the following
two questions to WG discussion. Well reasoned answers are certainly
appreciated. But plain "yes" or "no" would
On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote:
> If we really want to make WESP as specified in the charter, it would
> be much better to make it so it can be added incrementally to the ESP
> processing, i.e. just like UDP encapsulation for NAT-traversal can be
> do. This would mea
Yaron Sheffer writes:
> - 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 no longer a simple wrapper
ternatively, we
could really rewind the clock and try to establish real warrant and
consensus for a complete replacement to ESP.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Yoav Nir
To:
Yaron Sheffer
Cc:
"ipsec
1 - 100 of 102 matches
Mail list logo
