Jack,
Thanks for describing the additional selection criteria that must be
employed to avoid the problem I cited.
Given this more complete description of the selection criteria, I am
not convinced that that is a significant benefit for using WESP in
this context.
- Whether using WESP or
Jack Kohn writes:
Assume we dont have WESP.
I would like to, but unfortunately I lost :-)
The end router having scores of OSPF adjacencies will have following
rules in its database for *each* adjacency:
Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
HELLO, put it
At 12:11 PM +0100 11/25/09, Daniel Migault wrote:
Hi Manav,
I agree that for an already negotiated SA, the SPD lookup detects IP
source address spoofing. So in that case ESP detects the address
spoofing during the SPD check whereas AH would detect it while
checking the signature check.
Now, assume that we were using WESP.
You would need just two rules in your filter database saying the
following:
Incoming Pkt is WESP integrity Protected, then look at the nth bit and
if its a OSPF HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt is WESP integrity Protected, then look
At 11:09 PM +0530 11/21/09, Jack Kohn wrote:
Steve,
4301 contains We have explicit directions on how to use multiple SAs when
the peers know that they want to send traffic with different QoS parameters.
This appears to be an instance where the middle boxes are to examining
traffic, and
You got it all wrong. The sender is sending packets with the same QoS
parameters; its the receiver thats trying to prioritize some packets
over the others. One would typically do this for the Hellos/KeepAlives
that are associated with a protocol, so that the adjacency/peering
session are
Jack Kohn writes:
From operational perspective if we are supporting both v4 and v6 (and we
will) then having different protocols ESP and AH is and will be a
nightmare. Common denominator is ESP-Null. However, there were issues with
ESP-Null as it couldnt be deep inspected which has now been
It will take several years before implementations start to implement
WESP, and even more years before hardware chips support WESP. Most of
the IPsec users are still using IKEv1, even when we published IKEv2
2005, i.e. 4 years ago. And IKEv2 draft was finished and publication
was requested
On Nov 13, 2009, at 12:16 AM, Stephen Kent wrote:
My message pointed out that there was no mention of options, Your reply
picked a couple of option examples and argued that they were either not used
or did not pose a security problem.
The right way to generate a god answer is to
On Nov 11, 2009, at 3:56 PM, Stephen Kent wrote:
Jack,
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than ESP-NULL.
However, other WGs have cited AH as the IPsec protocol of choice for
At 6:48 AM +0530 11/13/09, Bhatia, Manav (Manav) wrote:
Daniel,
AH is a security feature we need to keep for header authentication
Am really not sure about the value that AH adds even in case of
header authentication.
So what fields does AH protect:
Version, Payload length, Next Header,
So what fields does AH protect:
Version, Payload length, Next Header, Source IP and dest IP
you forgot IPv4 and IPv6 options that have predictable values at the
destination
Lets start with the IPv6 Type 0 Route Header (aka Source Routing in v4
parlance), which is a mutable but a
lookup fail?
Cheers, Manav
-Original Message-
From: Richard Graveman [mailto:rfgrave...@gmail.com]
Sent: Friday, November 13, 2009 7.07 AM
To: Bhatia, Manav (Manav)
Cc: Daniel Migault; ipsec@ietf.org; Stephen Kent; Kaeo;
mer...@core3.amsl.com
Subject: Re: [IPsec] WESP - Roadmap
Scott,
From: ipsec-boun...@ietf.org On Behalf Of Scott C Moonen
Sent: Thursday, November 12, 2009 2.37 AM
To: Jack Kohn
Cc: ipsec@ietf.org; ipsec-boun...@ietf.org
Subject: Re: [IPsec] WESP - Roadmap Ahead
Jack, I'm not sure it's clear yet whether WESP will be widely adopted
Steve,
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
choice for integrity/authentication in their environments, so there
will be a
At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote:
Steve,
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
choice for
All of the standards I've seen that explicitly define how
IPsec is to
be used for authentication (including RFC 4552 - Authentication/
Confidentiality for OSPFv3) say that for authentication
ESP-Null MUST
be used and AH MAY.
Yes, this is correct.
The latest PIM-SM authentication
Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
they never refer to it that way) as a MUST, and AH as a MAY.
Ok, so can we work on deprecating AH? This way new standards defined
in other WGs dont have to provide support for AH.
Jack
I probably was confused because
All of the standards I've seen that explicitly define how IPsec is to
be used for authentication (including RFC 4552 - Authentication/
Confidentiality for OSPFv3) say that for authentication ESP-Null MUST
be used and AH MAY.
Which RFCs specify AH specifically as a MUST for authentication/
On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn kohn.j...@gmail.com wrote:
Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
they never refer to it that way) as a MUST, and AH as a MAY.
Ok, so can we work on deprecating AH? This way new standards defined
in other WGs
20 matches
Mail list logo
