Subject: [IPsec] FW: I-D Action:draft-nir-ike-nochild-00.txt

From: Yoav Nir <[email-masked]>
Date: Thu, 21 May 2009 17:00:46 +0300

Hi all

Recently there's been some discussions about creating an IKE SA without child SAs (on purpose).

I'm still not entirely convinced that this is necessary, but I have submitted this draft, and would like to hear comments about it.  Does it fill the need that some people on this mailing list expressed?

Thanks

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 21, 2009 3:45 PM
To: [email-masked]
Subject: I-D Action:draft-nir-ike-nochild-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
	Filename        : draft-nir-ike-nochild-00.txt
	Pages           : 6
	Date            : 2009-05-21

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-ike-nochild-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Email secured by Check Point

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1uaXItaWtlLW5vY2hpbGQtMDAudHh0DQo=

---

From: Raj Singh <[email-masked]>
Date: Fri, 22 May 2009 00:13:37 +0530

Hi Yoav,

1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want to create
child sa?
2. Also, please mention clearly in draft that what should be the behavior of
responder if a faulty initiator sends modified IKE_AUTH request, even if
responder has not send IKE_AUTH_NO_CHILD VID payload.
3. Also, why its a VID payload, Notify suits better. Because a third party
client will want to connect to some other server. Please give justification
for IKE_AUTH_NO_CHILD to be a VID.

Thanks,
Raj

On Thu, May 21, 2009 at 7:30 PM, Yoav Nir <[email-masked]> wrote:

> I'm still not entirely convinced that this is necessary, but I have
> submitted this draft, and would like to hear comments about it.  Does it
> fill the need that some people on this mailing list expressed?
>
> Thanks
>
> Yoav
>
> This document describes an extension to the IKEv2 protocol that allows an
> IKE SA to be created and authenticated without generating a child SA.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 24 May 2009 13:08:12 +0300

Hi Raj
 
On Thursday, May 21, 2009 9:44 PM, Raj Singh wrote:
> Hi Yoav,
> 
> 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want 
> to create child sa?  
 
We don't. That comes from (note careful enough) cut-and-paste.  Good catch. 
 
> 2. Also, please mention clearly in draft that what should be the 
> behavior of responder if a faulty initiator sends modified 
> IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD 
> VID payload. 
 
There can be two reasons why a certain implementation has not sent the VID:
1. The responder does not support this extension. In that case, I can't specify any behavior for it, and it should send an INVALID_SYNTAX.
2. It does support this extension, but the administrator has deliberately turned it off. In that case, I think the responder should respond exactly as if it didn't support the extension at all, and reply with an INVALID_SYNTAX. I'll add a line to the draft saying this explicitly.
 
> 3. Also, why its a VID payload, Notify suits better. Because a third 
> party client will want to connect to some other server. Please give 
> justification for IKE_AUTH_NO_CHILD to be a VID.

Section 3.12 of -bis document says "A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to this protcol..."
Using a VID has one advantage over a Notify, in that you don't need IANA to allocate a value. With a Notify, I would not be able to get a number from IANA until the document was ready for publication which can take over a year. Implementations that want to support this would need to use a temporary private use notify type, and then protect it with a VID payload (which would not be interoperable, because every vendor would choose a different value and VID). After the document is published, a new version of the product can use a IANA-assigned notify type, but because different products are out there, you need to support for a long time the old private-use type with its VID.  
Doing it all with VID is simpler and allows continuity between draft and RFC implementations. In IKEv1 it was common to use VIDs to indicate support for an externsion. See for example, RFC 3947.
Email secured by Check Point

---

From: Raj Singh <[email-masked]>
Date: Mon, 25 May 2009 08:53:48 +0530

Hi Yoav,

On Sun, May 24, 2009 at 3:38 PM, Yoav Nir <[email-masked]> wrote:

> 1. The responder does not support this extension. In that case, I can't
> specify any behavior for it, and it should send an INVALID_SYNTAX.
> 2. It does support this extension, but the administrator has deliberately
> turned it off. In that case, I think the responder should respond exactly as
> if it didn't support the extension at all, and reply with an INVALID_SYNTAX.
> I'll add a line to the draft saying this explicitly.
>
> Section 3.12 of -bis document says "A Vendor ID payload MAY announce that
> the sender is capable of accepting certain extensions to this protcol..."
> Using a VID has one advantage over a Notify, in that you don't need IANA to
> allocate a value. With a Notify, I would not be able to get a number from
> IANA until the document was ready for publication which can take over a
> year. Implementations that want to support this would need to use a
> temporary private use notify type, and then protect it with a VID payload
> (which would not be interoperable, because every vendor would choose a
> different value and VID). After the document is published, a new version of
> the product can use a IANA-assigned notify type, but because different
> products are out there, you need to support for a long time the old
> private-use type with its VID.
> Doing it all with VID is simpler and allows continuity between draft and
> RFC implementations. In IKEv1 it was common to use VIDs to indicate support
> for an externsion. See for example, RFC 3947.
If we think we are going to allow IKE_AUTH without CHILD SA, i feel
notification of  IKE_AUTH_NO_CHILD_SA type will be better because VIDs are
limited to proprietary use and if any implementation want to support this
extension for their products, it can choose a VALUE value for  this
notification and can update to a new value when IANA assigns it.
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is good
example of it.

Thanks,
Raj

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 May 2009 10:28:08 +0300

Hi Raj

Section 3.12 of -bis document says "A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to this protcol..."
Using a VID has one advantage over a Notify, in that you don't need IANA to allocate a value. With a Notify, I would not be able to get a number from IANA until the document was ready for publication which can take over a year. Implementations that want to support this would need to use a temporary private use notify type, and then protect it with a VID payload (which would not be interoperable, because every vendor would choose a different value and VID). After the document is published, a new version of the product can use a IANA-assigned notify type, but because different products are out there, you need to support for a long time the old private-use type with its VID.
Doing it all with VID is simpler and allows continuity between draft and RFC implementations. In IKEv1 it was common to use VIDs to indicate support for an externsion. See for example, RFC 3947.
Email secured by Check Point
If we think we are going to allow IKE_AUTH without CHILD SA, i feel notification of  IKE_AUTH_NO_CHILD_SA type will be better because VIDs are limited to proprietary use and if any implementation want to support this extension for their products, it can choose a VALUE value for  this notification and can update to a new value when IANA assigns it.
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is good example of it.

Thanks,
Raj
I don't see why VIDs are limited to proprietary use, and implementations don't get updated fast enough to allow them to just "switch" to the new IANA-assigned value.

The example of RFC 3947 is illuminating. The drafts had a different VID value then the RFC. Microsoft implemented the draft version (from draft-02 IIRC) and all gateways that support L2TP clients still must support both the draft VID and the RFC VID.  While we might rely on vendors updating their implementations, we can't rely on customers to do so.