Re: [IPsec] WESP - Roadmap Ahead

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 j

Re: [IPsec] WESP - Roadmap Ahead

> >> 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 Protec

Re: [IPsec] WESP - Roadmap Ahead

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. Howe

Re: [IPsec] WESP - Roadmap Ahead

At 9:05 AM +0530 11/25/09, Jack Kohn wrote: > >... Assume we dont have WESP. 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 in Ospfv3HighPrio

Re: [IPsec] WESP - Roadmap Ahead

Daniel Migault writes: > I agree that for an already negotiated SA, the SPD lookup detects IP source > address spoofing. Not quite true, as you point out yourself. > So in that case ESP detects the address spoofing during > the SPD check whereas AH would detect it while checking the signature ch

Re: [IPsec] WESP - Roadmap Ahead

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

Re: [IPsec] WESP - Roadmap Ahead

ofing we erroneously process the IPSec packet. I don't see that > happening, so is this really an issue? > > Cheers, Manav > > >From: Daniel Migault [mailto:mglt.i...@gmail.com] >Sent: Thursday, November 12, 2009 11.14 AM >

Re: [IPsec] WESP - Roadmap Ahead

> >- the principle example offered is OSPFv3 use of IPsec >- OSPFv3 relies on both unicast and multicast SAs >- in either case, a router receiving IPsec-protected OSPFv3 traffic > will have an SAD entry for the traffic, which means that the > router will kn

Re: [IPsec] WESP - Roadmap Ahead

... >- it fails to characterize the range of protocols for which you believe this argument applies, http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html This is one example, we could think of some more. This is only one example, and I think it is not "mainstream", so mo

Re: [IPsec] WESP - Roadmap Ahead

>> >> 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 >> ses

Re: [IPsec] WESP - Roadmap Ahead

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 put

Re: [IPsec] WESP - Roadmap Ahead

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 putting in into different QoS queues. That rai

Re: [IPsec] WESP - Roadmap Ahead

At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote: inline... On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent <k...@bbn.com> wrote: At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: This is an implementation specific optimization that has already been solved in mult

Re: [IPsec] WESP - Roadmap Ahead

Gregory, Do you see how WESP can be used in KARP? Jack On Wed, Nov 18, 2009 at 12:49 AM, Gregory Lebovitz wrote: > inline... > > On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent wrote: > --snip-- > >> >> I am not suggesting that any aspect of your analysis is flawed. I am >> suggesting that befo

Re: [IPsec] WESP - Roadmap Ahead

inline... On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent wrote: --snip-- > I am not suggesting that any aspect of your analysis is flawed. I am > suggesting that before the WG chooses to further deprecate AH, it needs to > document the analysis supporting this decision, not just cite a couple o

Re: [IPsec] WESP - Roadmap Ahead

inline... On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent wrote: > At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: > >> This is an implementation specific optimization that has already been >> solved in multiple implementations. >> >> Cheers, Manav >> > > Is the phrase "implementation spec

Re: [IPsec] WESP - Roadmap Ahead

Tero, On Mon, Nov 16, 2009 at 6:39 PM, Tero Kivinen wrote: > Bhatia, Manav (Manav) writes: >> And the reason why you might want to use WESP is to prioritize >> certain protocol packets over the others, as is normally done for v4 >> control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 >>

Re: [IPsec] WESP - Roadmap Ahead

There multiple "implementation specific" optimizations available. One such optimization that is currently in use in multiple platforms is: Do the seq number check, and then place the packets in different priority queues/paths based on the kind of packet it is. Proprietary ASICs on the routers can

Re: [IPsec] WESP - Roadmap Ahead

On Mon, Nov 16, 2009 at 11:39:30AM -0500, Stephen Kent wrote: > >Or put the labels in the SA, since especially for IPSO you probably > >want cryptographic separation of different security levels. > > There are various options here. I know of devices that have opted to > use ESP in tunnel mode t

Re: [IPsec] WESP - Roadmap Ahead

... Divine guidance is, I suppose, one way to do protocol design, but it could lead to *real* religious wars an appropriate caution given my typo :-). > Also, note that IPSO and CIPSO are examples of options that were discussed at the IPSECME meeting this week, where there is a need

Re: [IPsec] WESP - Roadmap Ahead

At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: This is an implementation specific optimization that has already been solved in multiple implementations. Cheers, Manav Is the phrase "implementation specific" a euphemism for non-standard? Steve

Re: [IPsec] WESP - Roadmap Ahead

f.org > Subject: RE: [IPsec] WESP - Roadmap Ahead > > Bhatia, Manav (Manav) writes: > > And the reason why you might want to use WESP is to prioritize > > certain protocol packets over the others, as is normally done for v4 > > control packets (e.g. OSPFv3 HELLOs and ACK

Re: [IPsec] WESP - Roadmap Ahead

Bhatia, Manav (Manav) writes: > And the reason why you might want to use WESP is to prioritize > certain protocol packets over the others, as is normally done for v4 > control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 > packets) You cannot do that, as if the packets get reordered mor

Re: [IPsec] WESP - Roadmap Ahead

> > 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 requ

[IPsec] WESP - Roadmap Ahead

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 bee

Re: [IPsec] WESP - Roadmap Ahead

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 con

Re: [IPsec] WESP - Roadmap Ahead

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 construct a table of all the options, and provide a rationale f

Re: [IPsec] WESP - Roadmap Ahead

t the SAD 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

Re: [IPsec] WESP - Roadmap Ahead

> > > >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 mutabl

Re: [IPsec] WESP - Roadmap Ahead

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,

Re: [IPsec] WESP - Roadmap Ahead

c packet. I don't see that > happening, so is this really an issue? > > Cheers, Manav > > >        From: Daniel Migault [mailto:mglt.i...@gmail.com] >        Sent: Thursday, November 12, 2009 11.14 AM >        To: Jack Kohn >        Cc

Re: [IPsec] WESP - Roadmap Ahead

M To: Jack Kohn Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn wrote: > > Whoops, I was wrong. I looked at 4552 an

Re: [IPsec] WESP - Roadmap Ahead

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 > integrity/aut

Re: [IPsec] WESP - Roadmap Ahead

On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn 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 dont have to

Re: [IPsec] WESP - Roadmap Ahead

> > 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 bec

Re: [IPsec] WESP - Roadmap Ahead

> > 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. In fact there was some discussion of using IPSec fo

Re: [IPsec] WESP - Roadmap Ahead

At 7:49 PM -0800 11/11/09, Merike Kaeo wrote: 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 s

Re: [IPsec] WESP - Roadmap Ahead

> 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 authenticat

Re: [IPsec] WESP - Roadmap Ahead

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/ i

Re: [IPsec] WESP - Roadmap Ahead

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 integrity/authe

Re: [IPsec] WESP - Roadmap Ahead

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

Re: [IPsec] WESP - Roadmap Ahead

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 whet

Re: [IPsec] WESP - Roadmap Ahead

Scott C Moonen writes: > Jack, I'm not sure it's clear yet whether WESP will be widely adopted. > There's disagreement between end-node and middle-node folks as to whether > WESP or heuristics are the best approach for inspection of ESP-NULL > traffic. I think that end-node vendors will be very

Re: [IPsec] WESP - Roadmap Ahead

WESP to ESP. What status will the WESP RFC have? Experimental, informational, standards track, etc.? Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Jack Kohn To: ipsec@ietf.org Date: 11/11/2009 11:06 AM Subject: [IP

Re: [IPsec] WESP - Roadmap Ahead

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 integrity/authentication in their environments, so there will be a need to

[IPsec] WESP - Roadmap Ahead

Hi, >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 solved with WESP.