Keith Welter writes:
> A recognized (old) notify type like NO_PROPOSAL_CHOSEN may be used
> as a hint to do something special like try again later, a notion the
> RFC 4718 authors exploited because they didn't have the luxury of
> introducing new notify types. So, sending a new notify type to a
> p
> > Do you support [the decision to include the WESP header in the ICV
> > calculation]?
> > . . .
> > Do you support [the decision to allow the use of WESP for encrypted
> > ESP flows]?
>
> Yes to both.
>
> Regardless of what the original work item specified, WESP as it is now
> is an alternativ
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
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
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
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 raised by Steve Kent - malicious entities modi
Yes to both questions.
But I'd also like to question the process being followed. We've discussed these
points numerous times
in f2f meetings, on the mailing list, at virtual interims, etc. So I'm
surprised to see the already
established consensus being questioned all over again. Some of the arg
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
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.
I would have expected the response to the IESG to be: yes, this was the
consensus arrived
in the WG at time X, here are further details, etc.
W
Hi Russ,
I'd like to comment on your assumption below that:
> ...the ICV protection
> imposes a requirement that the end system check the WESP information that it
> does not need, and then discard the packet if the attacker altered it to the
> potential detriment of the middlebox"
The underly
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
Yes to both.
To elaborate on what Ken said, here's an explicit scenario that requires the
encrypted bit for WESP, fully within the current charter of enabling ESP-NULL
inspection.
Transport policies for within an organization that want to enable intermediary
inspection of ESP-NULL non-heurisit
Yes and Yes.
We see a lot of value in taking advantage of the extensibility of the protocol
as it stands in the WESP today. Allowing WESP to not be simply a wrapper, and
enabling encryption support are both fundamental for the future
extensibilities. So we express our support of the these desig
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
Gabriel:
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
exposed informa
Hi Russ,
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
arri
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 support this functionality yet.
Here's an explic
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
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 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
> 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
> 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
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
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,
I think we agree here: the end nodes need to validate the WESP header info.
As I noted before, one could do this by modifying the ICV or by explicitly
checking those
WESP fields at the end nodes. I think there has been enough feedback to the
effect that
modifying the ICV is overkill and
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
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
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
> 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
29 matches
Mail list logo
