[IPsec] Proposed work item: EAP-only authentication in IKEv2

This draft proposes an IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for one of the peers to present a certificate. This applies to a small number of key-generating EAP methods that allow mutual authentication.   Proposed starting point:

[IPsec] Proposed work item: Childless IKE SA

This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no Child SA, a situation which is currently disallowed by the protocol. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.   Please reply to the list:   - If this proposal is accepted

[IPsec] Proposed work item: IKEv2 password authentication (SPSK)

This draft proposes a particular method for mutual authentication of IKEv2 peers using a short, low quality shared secret (a.k.a. password). The proposal is to embed this method in the IKE exchange, rather than use EAP. Proposed starting point:

[IPsec] Proposed work item: Failure detection in IKEv2

This work item proposes an IKEv2 extension to allow an IKE peer to quickly and securely detect that its opposite peer has lost state. This is claimed to be quicker than the current method, which is based on time outs. Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txt or

[IPsec] Proposed work item: WESP extensibility

This draft proposes an extensibility framework for WESP, as well as several specific extensions. Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you

[IPsec] Proposed work item: IKE/IPsec high availability and load sharing

This work item will define the problem statement and requirements for a solution that allows interoperable HA/LS device groups. Mixed-vendor clusters are specifically out of scope; but single-vendor clusters should be fully interoperable with other vendors' devices or clusters. The main

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

For someone, who spent quite a lot of time working in this area, it is not difficult fo figure out what is really important and what is not. But, I think, a newcomer could be confused by a long list of all possible numbers. This answer is inconsistent, and that's the crux of the issue I have

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

At 12:19 AM +0300 11/30/09, Valery Smyslov wrote: For someone, who spent quite a lot of time working in this area, it is not difficult fo figure out what is really important and what is not. But, I think, a newcomer could be confused by a long list of all possible numbers. This answer is

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

Re: [IPsec] Proposed work item: WESP extensibility

I am opposed to pursing this work at this time. The ongoing discussion on the list suggests that the arguments put forth for WESP use in the OSPFv3 context, the first concrete proposal outside of the middlebox inspection context that motivated WESP, have not been validated. The presentation