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

[IPsec] IPsecME WG report

IPsecME met this morning. We have one RFC (IKEv2 Redirect) recently published, and a couple more in the RFC Editor queue. The other "small" drafts are coming along as well. The group is making progress on IKEv2-bis, and we had a presentation on one thorny protocol issue that was resolved by a d

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] Clarification on identities involved in IKEv2EAPauthentication

The selection of AAA server will be based on IDi then EAP will happen. The gateway will get EAP authenticated ID from the AAA server. If EAP identity is different from IDi and no policy is found for EAP identity. The gateway should initiate deletion of the SA. Also, if policy is found based on EAP

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

[IPsec] Finishing #22 (was: Re: Closing the IKEv2bis open issues)

Title: Finishing #22 (was: Re: [IPsec] Closing the IKEv2bis open Resent so that the issue number is in subject line only. Please reply to this thread. At 11:42 AM -0800 11/11/09, Keith Welter wrote: > Issue #22, Add section on simultaneous IKE SA rekey >

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 whether WESP will be widely adopted.

[IPsec] comments on esp-null-heuristics-01

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >As end nodes might be able to > bypass those checks by using encrypted ESP instead of ESP-NULL, these > kinds of scenarios also require very specific policies to forbid such > circumvention. The question is, are these end-nodes malicio

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] Clarification on identities involved in IKEv2EAPauthentication

Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is > more for the client, which is typically more integrated. The client > should be prepared to give an identity hint both in IKE and later in > the EAP session. And in that case the identities should really be same

Re: [IPsec] WESP - Roadmap Ahead

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 reluctant to adopt WESP widel

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

Re: [IPsec] RFC4869 bis submitted

On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote: > While the algorithms and DH groups are subject to configuration in the UI > and negotiation in IKE, the algorithm used to sign the certificates is > outside the IKE implementation. You usually have a certificate that you > need to use, and

Re: [IPsec] RFC4869 bis submitted

Hi If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates? While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implement

Re: [IPsec] Closing the IKEv2bis open issues

> Issue #22, Add section on simultaneous IKE SA rekey > > There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of > opinion, and almost no one else has participated. I have reviewed the discussion, and

[IPsec] RFC4869 bis submitted

A bis has been submitted for RFC 4869, "Suite B Cryptographic Suites for IPsec". It is available at http://tools.ietf.org/html/draft-law-rfc4869bis-00 This Internet-Draft makes several minor changes to the suites in RFC 4869 and incorporates comments that have been posted to the ipsec mailing l

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

Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication

The text is a little vague here, because the draft only describes the use of EAP, and does not mandate anything for an AAA server. If the gateway is also the EAP authenticator, then it makes no sense to send the identity request, because the reply has already been received in packet #3. If the

Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication

Hi Yoav, Thanks for the quick response. Please see inline. -Original Message- From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Wednesday, November 11, 2009 7:23 PM To: Srinivasu S R S Dhulipala (srinid) Cc: Amjad Inamdar (amjads); ipsec@ietf.org Subject: Re: [IPsec] Clarification on ide

Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication

On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote: > >> 2) If not same, what purpose should each of the above identities serve > > 1) mainly used as a hint for the gateway as to which AAA server to > choose > 2) It's the AAA server that may request the identity, and it's

Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication

Hi Yoav, Please see inline for [SRINI]. Thanks, Srinivas -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, November 10, 2009 5:29 PM To: Amjad Inamdar (amjads) Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on iden

Re: [IPsec] EAP Identity request in IKEv2

Resending the query again, as I did not see any response to this query. It looks like additional EAP ID request to the client is not needed, so I think we should move the "should" to "SHOULD" again. Any thoughts? Thanks, Srinivas From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf