[IPsec] Submission of draft-ipsecme-aes-ctr-ikev2-00.txt

Please use the link http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-ipsecme-aes-ctr-ikev2-00.txt Hi , A new draft draft-ipsecme-aes-ctr-ikev2-00.txt is submitted by NSS Murthy, S.S

[IPsec] Submission of draft-ipsecme-aes-ctr-ikev2-00.txt

Hi , A new draft draft-ipsecme-aes-ctr-ikev2-00.txt is submitted by NSS Murthy, S.Shen and Y.Mao. Please send your comments.We wish to release the next version by 20th of this month. Abstr

Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

Hi, RFC 5114 claims it defines new ECP groups 19, 20, and 21 for IKE but so does RFC 4753. Interestingly the curve definitions are different but the orders are the same (maybe it's just interesting because I don't understand why). RFC 5114 also defines some new MODP groups but RFC 4753 does n

Re: [IPsec] Fwd: Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and

> I have reviewed the diffs between draft-solinas-rfc4753bis-00.txt and RFC 4753 and agree that they fully fix the issue that was brought to the > IPsecME WG last week. Agreed; support. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ h

Re: [IPsec] Fwd: Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and

At 3:29 PM -0700 7/9/09, Paul Hoffman wrote: > >IKEv2) to Informational RFC > > >>The IESG has received a request from an individual submitter to consider >>the following document: >> >>- 'ECP Groups for IKE and IKEv2 ' >>as an Informational RFC >> >>The IESG plans to make a decision in the nex

[IPsec] Fwd: Last Call: draft-solinas-rfc4753bis (ECP Groups for IKE and

>IKEv2) to Informational RFC > >The IESG has received a request from an individual submitter to consider >the following document: > >- 'ECP Groups for IKE and IKEv2 ' >as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action

[IPsec] Fwd: FW: New Version Notification for draft-padmakumar-ikev2-redirect-and-auth-offload-00

Hi All, I submitted a new draft draft-padmakumar-ikev2-redirect-and-auth-offload-00 ( http://www.ietf.org/internet-drafts/draft-padmakumar-ikev2-redirect-and-auth-offload-00.txt ). This draft discuss IKEv2 redirect based mechanism to offload Authenication related work to a trusted third party. I

Re: [IPsec] Stockholm meeting - call for agenda items

This is a gentle reminder that we are dedicating part of the Stockholm meeting to proposed work items, as a preparation for the rechartering process soon after Stockholm. Please send me and Paul requests for presentation slots on this discussion by July 17. Thanks, Yaron > -Original M

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Raj, if responder doesn't support this extension, initiator will determine it after IKE_SA_INIT and continue with current approach (dummy IPsec proposals). If initiator cannot do it, they won't communicate anyway. In this case initiator is broken, because it cannot deal with old (unsupported)

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi Valery, On Thu, Jul 9, 2009 at 1:13 PM, Valery Smyslov wrote: > Hi all, > > I think, adding new payload or exchange type is a real overkill for > such a small extension. > IKE has well defined mechanism for advertising/negotiating new > extensions via VID or Notify. > Other extensions (like M

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

Hi all, I think, adding new payload or exchange type is a real overkill for such a small extension. IKE has well defined mechanism for advertising/negotiating new extensions via VID or Notify. Other extensions (like MOBIKE) use it, so why multiply entities unnecessarily? Then, I'd rather leave a