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-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Yoav Nir
Sent: Monday, July 06, 2009 1:54 PM
To: 'Raj Singh'
Cc: ipsec@ietf.org
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Inline with <ynir>
________________________________
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Raj Singh
Sent: Sunday, July 05, 2009 5:02 AM
To: Yoav Nir
Cc: ipsec@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 <y...@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 [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
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
