As it is, RFC 4306 mandates that if the problem
is only with the CHILD SA payloads, then all the IKE SA payloads (including the
AUTH and CFG) should be returned, followed by a child SA error (like NO_PROPOSAL_CHOSEN)
which fails only the child SA.
I agree that scenario (c) is not really solvable,
because the policies actually conflict.
From: Gaurav Poothia
[mailto:gpoothia at microsoft.com]
Sent: Thursday, July 09, 2009 7:57
AM
To: Yoav Nir; 'Raghunandan P
(raghup)'; Raj Singh
Cc: ipsec at ietf.org
Subject: RE: [IPsec] FW: I-D
Action:draft-nir-ipsecme-childless-00.txt
Hello Yoav,
Are you suggesting
that in this scenario the initiator will not tear down the IKE SA on getting a
CHILD SA specific error (NO_PROPOSAL_CHOSEN) for the AUTH exchange response ?
Shouldn’t the
IKE SA also be torn down because while the error notify doesn’t
explicitly fail the AUTH there is no explicit indication of success either.
Or did you have a
response in mind that had all the relevant IKE SA related payloads intact and a
single error notify for the CHILD SA?
BTW perhaps the
authors should consider motivating scenario ( c ) where it is the responder
that wants a childless IKE SA instead of the initiator, with usage scenarios or
alternatively consider making it an explicit non-goal.
I was under the
impression it’s the initiator that requests this feature and the
responder might/might not oblige based on whether it implements the extension.
From:
ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On Behalf Of Yoav Nir
Sent: Monday, July 06, 2009 6:15
AM
To: 'Raghunandan P (raghup)'; Raj
Singh
Cc: ipsec at ietf.org
Subject: Re: [IPsec] FW: I-D
Action:draft-nir-ipsecme-childless-00.txt
Hi Raghu
I think in scenario (c) the initiator will
propose a full child SA proposal, and the responder will accept the IKE SA and
reply with a NO_PROPOSAL_CHOSEN for the child SA.
From: Raghunandan P
(raghup) [mailto:raghup at cisco.com]
Sent: Monday, July 06, 2009 1:43
PM
To: Yoav Nir; Raj Singh
Cc: ipsec at ietf.org
Subject: RE: [IPsec] FW: I-D
Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav/Raj,
I think its a good idea for the initiator
to announce its capabilities about supporting just IKE SA without child
SA. The responder will then act accordingly. Hence, this would make 4
scenarios:
[IKE_SA_ONLY] is the mode that will tell
whether the device supports bringing up IKE SA only or not.
Initiator
Responder
Result
---------------------------------------------------------------------------------------------------------
a) IKE_SA_ONLY
IKE_SA_ONLY
Bring up the IKE SA
b)
IKE_SA_ONLY
Does not support
Send a Notify with INVALID_SYNTAX
IKE_SA_ONLY
c) Does not
support
IKE_SA_ONLY IKE and
child SA would be brought UP
IKE_SA_ONLY
d) Does not
support Does not
support IKE and child SA
would be brought UP.
IKE_SA_ONLY
IKE_SA_ONLY
My question is related to the scenario c)
discussed above.
Is the result to bring up IKE and IPSec
SA or would the responder send a Notify with INVALID_SYNTAX to the
initiator since responder wants to bring up IKE SA only and not the child SA.
It might be good to add a Notify
(IKE_SA_ONLY) than the VID.
Regards
Raghu
From:
ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On Behalf Of Yoav Nir
Sent: Monday, July 06, 2009 1:54
PM
To: 'Raj Singh'
Cc: ipsec at ietf.org
Subject: Re: [IPsec] FW: I-D
Action:draft-nir-ipsecme-childless-00.txt
Inline with <ynir>
From:
ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On Behalf Of Raj Singh
Sent: Sunday, July 05, 2009 5:02
AM
To: Yoav Nir
Cc: ipsec at ietf.org
Subject: Re: [IPsec] FW: I-D
Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav,
Please find my input inline <Raj>.
With Regards,
Raj
On Sun, Jul 5, 2009 at 2:33 AM, Yoav Nir <ynir at checkpoint.com> wrote:
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.
<Raj> Yes, if responder understands childless IKE_AUTH from
initiator, it will behave as mentioned in my previous mail, if NOT and it does
not support childless IKE_AUTH [only responder not supporting childless
extention], then initiator will notice missing childless notify/VID and can
stop the transactions for the SA. But it will help responders, supporting this
extentions and applying policies.
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.
<Raj> What's the usecase ?
<ynir> the usecase is that the client
needs an IKE SA, but can’t get it unless it negotiates a child SA –
that’s what you have now before implementing our draft.
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.
<Raj> How it can be a misconfiguration, The gateway can put some
policy to enable/disable childless IKE_AUTH based on "load" on
gateway. Yes, i agree, new crittical payload, we can avoid.
<ynir> Well, we could add our own
“critical” bit to the notify/VID. If that is on, the responder can
either reply with a similar notification/VID, or else some error notify
(NO_PROPOSAL_CHOSEN or a new one of our own)
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.
<Raj> The whole idea is:
initiator to send childless notify/VID when it want to bring up
"ONLY" IKE SA i.e. it is not hit by traffic or "dummy"
payload. This will avoid unnecessary processing of IKE_SA_INIT at responder
when responder does not support childless IKE_AUTH. This is most likely usecase
of chiless IKE_AUTH in VPN scenarios.
The behavior remains similar as mentioned in my previous mail except
"critical" bit as it needs to define new payload type which even i
want to avoid. Its just a simple notify/VID payload with no associated data and
easing the work at initiator and responder. Its can see goodness in idea.
When initiator has dummy proposal ready, the initiator need not to send
childless notify/VID payload.
________________________________________
From: Raj Singh [rsjenwar at gmail.com]
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 <ynir at checkpoint.com<mailto:ynir at 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-bounces at ietf.org<mailto:i-d-announce-bounces at ietf.org>
[i-d-announce-bounces at ietf.org<mailto:i-d-announce-bounces at ietf.org>]
On Behalf Of Internet-Drafts at ietf.org<mailto:Internet-Drafts at ietf.org> [Internet-Drafts at ietf.org<mailto:Internet-Drafts at ietf.org>]
Sent: Wednesday, July 01, 2009 12:15
To: i-d-announce at ietf.org<mailto:i-d-announce at 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 at ietf.org<mailto:IPsec at ietf.org>
Scanned by Check Point
Total Security Gateway.
Email secured by Check Point
Scanned by Check Point Total Security Gateway.
Email secured by Check Point
Email secured by Check Point
Scanned by Check Point Total Security Gateway.
