I never said that there are service providers clamouring for WESP.
You brought up a point about EGP routing protocols, and I just replied to that.
Cheers, Manav
> -Original Message-
> From: Dan Harkins [mailto:dhark...@lounge.org]
> Sent: Friday, January 08, 2010 10.42 AM
> To: Bhatia
[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
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,
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
In the absolutely most generic case, yes. And heuristics absolutely have their
place. However, my proposal clearly allows for eliminating all heuristics with
policy constraints.
As you well know, you can eliminate the heuristics you describe by choosing the
same algorithm so intermediaries d
-Original Message-
Also, anything QoS related should really happen outside ESP anyways.
Nico
--
In an ideal world maybe. Sometimes the netwwork needs to mark traffic at the
edge switch but doesn't 'trust' the endpoint to do it. So typically it would be
done with policy rules.
Thank
I read this sentence in IKEv2bis...
If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were
exchanged during IKE_SA_INIT), all devices MUST be able to receive and
process both UDP encapsulated and non-UDP encapsulated packets at any
time.
... and thought of my own implemen
On Fri, Jan 08, 2010 at 11:14:06AM -0800, Joseph Tardo wrote:
> -Original Message-
>
> Also, anything QoS related should really happen outside ESP anyways.
>
>
> In an ideal world maybe. Sometimes the netwwork needs to mark traffic
> at the edge switch but doesn't 'trust' the endpoint
Dan, I think the intent of that text was to read "non-UDP encapsulated" as
"non-UDP encapsulated [ESP]". I.e., it is not saying you should support
both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you
should support UDP encapsulation for an ESP tunnel even if a NAT was not
> >
> > In an ideal world maybe. Sometimes the netwwork needs to
> mark traffic
> > at the edge switch but doesn't 'trust' the endpoint to do it. So
> > typically it would be done with policy rules.
>
> We're talking about making changes to the end nodes anyways,
> so why not
> make them handle
On Fri, Jan 08, 2010 at 04:53:25PM -0500, Scott C Moonen wrote:
> Dan, I think the intent of that text was to read "non-UDP encapsulated" as
> "non-UDP encapsulated [ESP]". I.e., it is not saying you should support
> both UDP-encapsulation and vanilla UDP on port 4500; it is saying that you
> s
> ESP isn't a tunnelling protocol... ;) You meant an ESP SA, right?
Er, yes. :)
> OTOH, what is an ESP clarification doing in IKEv2?
IIRC, there was a request at one point to allow for ESP and UDP-encap ESP
to be completely interchangeable for any given packet at the discretion of
the sender.
12 matches
Mail list logo
