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
Kind-of wearing my co-chair hat:
At 9:16 AM +0530 1/6/10, Bhatia, Manav (Manav) wrote:
>I currently don't see applications that may need this kind of expedited
>processing, but the WESP design should not preclude development of such
>applications/features.
We have heard a number of statements l
Hi Russ,
> My point is that the end system does not need the information in the
> WESP header to properly handle the packet for the supported
> application. The additional information is being exposed to allow
> middle boxes to make various checks. The end system can
> ensure that the
> ex
, December 29, 2009 6:32:54 AM
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Manav:
I am unconvinced. If a malicious attacker is willing to alter packets to fool
middleboxes, this ICV does not help the middlebox and it harms the end system.
The middlebox cannot validate the IC
d nodes checking the fields explicitly.
Gabriel
- Original Message
> From: Russ Housley
> To: "Bhatia, Manav"
> Cc: ipsec@ietf.org; i...@ietf.org
> Sent: Tue, December 29, 2009 6:32:54 AM
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
>
>
At 6:17 AM +0530 12/29/09, Jack Kohn wrote:
Are you suggesting that ESP ICV should not cover the WESP fields?
I think, and my memory could be failing me, that this was discussed in
the WG before this got added to the draft.
Jack
I am suggesting that WESP should be cleanly layered, in one of t
December 29, 2009 6.17 AM
> To: Stephen Kent
> Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
>
> Are you suggesting that ESP ICV should not cover the WESP fields?
>
> I think, and my memory could
Bhatia, Manav (Manav) writes:
> Yes, this was discussed in the WG
> (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea
> was this:
>
> We could have some malicious entity that could modify the offsets to
> ensure that the intermediaries don't parse a portion of the payload
> (wh
Manav
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> On Behalf Of Jack Kohn
> Sent: Tuesday, December 29, 2009 6.17 AM
> To: Stephen Kent
> Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald
> Subject: Re: [IPsec] DISCUSS:
Are you suggesting that ESP ICV should not cover the WESP fields?
I think, and my memory could be failing me, that this was discussed in
the WG before this got added to the draft.
Jack
On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote:
> Yaron,
>
> I hate to admit it, but I lost track of the
Yaron,
I hate to admit it, but I lost track of the details of WESP as it
progressed through WG discussions and briefings at IETF meetings.
When I read the I-D in detail, I was very surprised to see that it
was no longer a neatly-layered wrapper, as originally proposed. The
fact that it now c
Yaron
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Tero Kivinen
> Sent: Monday, December 21, 2009 13:36
> To: Jack Kohn
> Cc: ipsec@ietf.org; Russ Housley
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-tra
On Behalf Of Yaron Sheffer
> Sent: Monday, December 21, 2009 5:25 AM
> To: Tero Kivinen; Jack Kohn
> Cc: ipsec@ietf.org; Russ Housley
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
>
> Hi Tero,
>
> Allowing the more generic, encrypted WESP (as per the cur
Tero,
> The reason I am in favor of heuristics instead of WESP, is that
> heuristics requires changes only on the middleboxes, we do not need to
> make new extension that will affect all the end nodes supporting
> IPsec.
>
> Also heuristics is not harmful, as it does not harm others, it is
> simp
36
To: Jack Kohn
Cc: ipsec@ietf.org; Russ Housley
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Jack Kohn writes:
> Alternatively, since we seem to be
> having unlimited bandwidth for discussions, we might as well argue
> whether we need heuristics also or not, as t
: draft-ietf-ipsecme-traffic-visibility
Jack Kohn writes:
> Alternatively, since we seem to be
> having unlimited bandwidth for discussions, we might as well argue
> whether we need heuristics also or not, as there are very few people
> in IPSecMe WG who feel the need for it.
My personal
Jack Kohn writes:
> Alternatively, since we seem to be
> having unlimited bandwidth for discussions, we might as well argue
> whether we need heuristics also or not, as there are very few people
> in IPSecMe WG who feel the need for it.
My personal feelings is that this inspecting ESP-NULL packets
Hi Russ,
If we are not willing to ever extend WESP then we might as well debate
the alternative scheme that i had reviewed long time back (which was
shot down citing WESP being more extensible). I see that we are going
through the discussions that we've already had in the WG, things that
had been
Ken:
[Ken] I think this is the whole point. All the work on ESP/IPsec
this far has been considering a two party interaction (outside the
multicast context!). Now there is a third party - the middle box,
which would like to gain some additional information in order to
provide valuable network
Grewal, Ken writes:
> >It does make more complexity for the middle boxes as they need to cope
> >with both encrypted WESP and ESP-NULL WESP, thus they still cannot use
> >just the WESP protocol number to indicate this packet is clear text.
> >Now they also need to check the bit in the header, and i
FWIW, I would personally rather see WESP do exactly what it is supposed
to do, reveal the packet, and not handle other kinds of functionality
(encrypted packets etc)
Jari
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ips
Some comments inline...
>It does make more complexity for the middle boxes as they need to cope
>with both encrypted WESP and ESP-NULL WESP, thus they still cannot use
>just the WESP protocol number to indicate this packet is clear text.
>Now they also need to check the bit in the header, and if
Agreed.
Thanks,
Ken
>-Original Message-
>From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>Of Jack Kohn
>Sent: Wednesday, December 16, 2009 3:33 PM
>To: Russ Housley
>Cc: ipsec@ietf.org; i...@ietf.org
>Subject: Re: [IPsec] DISCUSS: draft
Yaron Sheffer writes:
> I agree with you regarding some of the proposals that have been
> floating around re: exposing bits and pieces of encrypted data.
I am really concerned about some of those late proposals for WESP
extensions, and if someone would have mentioned any of those earlier
when we w
: Thursday, December 17, 2009 4:35
To: Russ Housley
Cc: ipsec@ietf.org; i...@ietf.org
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote:
> The document allows the encapsulation of encrypted IPsec traffic.
> W
On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote:
> The document allows the encapsulation of encrypted IPsec traffic.
> Why? I cannot see the justification for the use if WESP at all if
> the IPsec traffic is encrypted.
Because THE MAN told 'em to do it!
:)
Seriou
riginal Message
> From: Jack Kohn
> To: Russ Housley
> Cc: ipsec@ietf.org; i...@ietf.org
> Sent: Wed, December 16, 2009 3:33:14 PM
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
>
> My two bits on this and I'll let the authors/chairs explain in de
> >
> So, in fact, WESP is not an optional encapsulation of ESP. It is an
> alternative to ESP with some duplicated fields (such as Next Header)
> and pointers into the actual integrity-protected payload.
>
Actually, the name "Wrapped ESP" (WESP) is a misnomer. :)
It may have been envisaged
My two bits on this and I'll let the authors/chairs explain in detail ..
On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley wrote:
> Discuss:
> The primary motivation for this work is to allow a middlebox to peek
> into integrity protected (but not encrypted) IPsec packets. Some
> integrity-check a
29 matches
Mail list logo
