Subject: [IPsec] Some comments about redirect

From: Yoav Nir <[email-masked]>
Date: Wed, 27 May 2009 10:36:29 +0300

Hi.

I've read through the draft again, and here are a few comments:

Section 3 has the following line:

                                                      If the
   IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload,
   the responder MUST NOT send the REDIRECT payload to the VPN client.

This IMO should apply to all variations, not just to redirect during the Initial exchange.

I'm wondering if the REDIRECT notification type should not be allocated from the error range. It makes more sense, since it always fails the exchange (or at least part of it - the child SA in the IKE_AUTH exchange)

Section 10 sets up an IANA registry for identity types. Couldn't we just reuse the "IKEv2 Identification Payload ID Types"?  There's already IPv4, IPv6 and FQDN, and additionally KEY_ID for locally meaningful names and a range of private use IP addresses. Why set up a new registry for the same thing?

Yoav 

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 May 2009 13:02:48 +0300

Yoav Nir writes:
> Section 10 sets up an IANA registry for identity types. Couldn't we
> just reuse the "IKEv2 Identification Payload ID Types"?  There's
> already IPv4, IPv6 and FQDN, and additionally KEY_ID for locally
> meaningful names and a range of private use IP addresses. Why set up
> a new registry for the same thing? 

I do not think we want reuse IKEv2 Identification Payload ID types for
this, as then we again create lots of values which are not defined
(i.e. what does it mean to send ID_DER_ASN1_GN during redirect). I
prefer to have separate registry for it. I would actually like to have
separate registries for the two different use cases there is, as not
all values are usable in both cases.

Creating new IANA registries has small initial overhead, and if there
will not be any more allocations there is no more overhead for having
its own registry compared to sharing IKEv2 one.

On the other hand if there will be new allocations then even better if
we have separate registry for them so we do not mess up other
registries.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 May 2009 13:11:45 +0300

OK. In that case I would add to the initial registry

  4 - locally meaningful name

In our product, the gateways have "names" that appear both in the GUI and the configuration files (and logs). It's easier for them to fetch another gateway's "object" by name than by IP address. Such a name could be ASCII or UTF-8.
________________________________________
From: Tero Kivinen [[email-masked]]
Sent: Wednesday, May 27, 2009 13:02
To: Yoav Nir
Cc: [email-masked]
Subject: [IPsec] Some comments about redirect

Scanned by Check Point Total Security Gateway.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 May 2009 15:02:09 -0700

Hello,

> This IMO should apply to all variations, not just to redirect during the

We could add one sentence at the end of the paragraph. The new one would be

  The VPN client indicates support for the IKEv2 redirect mechanism
  and the willingness to be redirected by including a
  REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT
  request.  If the IKE_SA_INIT request did not include the
  REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT
  payload to the VPN client. This is applicable to all REDIRECT
  scenarios described in this document.

Is this is sufficient?

> I'm wondering if the REDIRECT notification type should not be allocated from
> the error range. It makes more sense, since it always fails the exchange (or
> at least part of it - the child SA in the IKE_AUTH exchange)

I don't think the REDIRECT is an error message. In some cases, you have to
delete the IKEv2 SA. Then there is the gateway-initiated redirect in the
middle of a session.
 
> Section 10 sets up an IANA registry for identity types. Couldn't we just reuse
> the "IKEv2 Identification Payload ID Types"?  There's already IPv4, IPv6 and
> FQDN, and additionally KEY_ID for locally meaningful names and a range of
> private use IP addresses. Why set up a new registry for the same thing?

In addition to what Tero said, I think the current registry "IKEv2
Identification Payload ID Types" explicitly refers to the ID payload. It
doesn't say "ID Types". If it had said "ID types", it could have been used
for the REDIRECT payload.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 May 2009 15:04:55 -0700

Hi Yoav,

>   4 - locally meaningful name

The client should be able to resolve this "locally meaningful name" to an IP
address to which it can initiate a new IKE_SA_INIT exchange. These "locally
meaningful names" might make sense to the pool of IKEv2 gateways, but would
it make sense to the client? How does the client figure out what the new VPN
gateway is?

Am I missing something?

Vijay

> 
> In our product, the gateways have "names" that appear both in the GUI and the
> configuration files (and logs). It's easier for them to fetch another
> gateway's "object" by name than by IP address. Such a name could be ASCII or
> UTF-8.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 May 2009 01:14:16 +0300

The client has to have a PAD that includes the gateways. 

Our implementation has the client downloading the configuration (by a proprietary protocol) that includes the gateway names (and how to find them - IP address or DNS name).  These gateway names can optionally be shown to the user in the GUI.  In any case, the client is as aware of the names as the gateways.
________________________________________
From: Vijay Devarapalli [[email-masked]]
Sent: Thursday, May 28, 2009 01:04
To: Yoav Nir; Tero Kivinen
Cc: [email-masked]
Subject: Re: [IPsec] Some comments about redirect

Hi Yoav,

Am I missing something?

Vijay

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 May 2009 01:17:23 +0300

The change is sufficient

OK about the status (rather than error) type

OK about using a new registry (though I still think you need to allocate the "locally meaningful name" and some space for private use)

Thanks

Yoav
________________________________________
From: Vijay Devarapalli [[email-masked]]
Sent: Thursday, May 28, 2009 01:02
To: Yoav Nir; [email-masked]
Subject: Re: [IPsec] Some comments about redirect

Hello,

Is this is sufficient?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 29 May 2009 14:50:50 -0700

Ok.

Anyone else have any comments on including "4 - Locally Meaningful Name"?

Vijay

On 5/27/09 3:14 PM, "Yoav Nir" wrote:

> Our implementation has the client downloading the configuration (by a
> proprietary protocol) that includes the gateway names (and how to find them -
> IP address or DNS name).  These gateway names can optionally be shown to the
> user in the GUI.  In any case, the client is as aware of the names as the
> gateways.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 31 May 2009 11:19:04 +0300

I think we should *not* add this type. I don't see how a client and a
gateway can agree on such a "locally meaningful name", without
non-interoperable protocols (or configuration databases). And I don't think
we should add this new concept, of all places, to the Redirect draft.

But of course we should reserve a portion of the new ID Type registry for
private use.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vijay Devarapalli
> Sent: Saturday, May 30, 2009 0:51
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>