Hi Raj The ordinary thing for a responder to do with unrecognized Notifies/VIDs is to ignore them. So the only responder that will behave as you suggest is one that supports this extension, but is configured not to.
At least for the remote access client, it makes sense for a client that faces both supporting and non-supporting gateways to have a "dummy" proposal for a useless child SA, for example ICMP from the client to the gateway. It doesn't really matter if the proposal is accepted or rejected, because the client does not need the traffic. In any case, an initiator that insists on a childless IKE SA contacting a gateway that does not support the extension is a misconfiguration. I don't believe we should go to great lengths (especially the new critical payload that Yaron is proposing) to save work in such a misconfiguration case. If we do think it's important, the "right" way is for the Initiator to send the VID, for the responder to only send the VID if it (a) supports the extension *and* (b) has seen the VID from the initiator. We could even require that the initiator be prepared to continue with a non-supporting gateway, but I'm not sure that's a good idea. ________________________________________ From: Raj Singh [rsjen...@gmail.com] Sent: Friday, July 03, 2009 16:51 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt Hi Yoav, Mostly the Initiator will decide that it wants to bring UP only IKE SA without child SA. But currently there is no notify/VID from Initiator to Responder to indicate that initiator wants to bring only IKE SA. Even if responder does not supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding CPU intensive D-H calculations, and send IKE_SA_INIT response without "childless VID" payload. By introducing a notify/VID payload from Initiator that it wants to bring UP only IKE SA without child SA wil ease the processing ar Responder side. If responder does not support "childless IKE_AUTH", it can send INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info to be available to bring UP both IKE and child SA, normally as mentioned in RFC 4306. Thanks, Raj On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir <y...@checkpoint.com<mailto:y...@checkpoint.com>> wrote: Hi all. This is the fourth iteration of this draft. New in this iteration - Another co-author - Changed the name, so that this item is considered in the rechartering discussion - Fixed some notation and some discussion based on comments from the list Yoav ________________________________________ From: i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org> [i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org>] On Behalf Of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>] Sent: Wednesday, July 01, 2009 12:15 To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Subject: I-D Action:draft-nir-ipsecme-childless-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Childless Initiation of the IKE SA Author(s) : Y. Nir, et al. Filename : draft-nir-ipsecme-childless-00.txt Pages : 7 Date : 2009-07-01 This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-childless-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
