Subject: Re: [IPsec] Some comments about redirect

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jun 2009 16:19:00 -0700

Hello,

On 5/31/09 1:19 AM, "Yaron Sheffer" wrote:

> 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.

I don't see a consensus on this yet. Tero and Yoav would like to see this
new gateway id type.
 
> But of course we should reserve a portion of the new ID Type registry for
> private use.

Since new values can be assigned by "Expert Review" do we really need to set
aside space for private use? You can always request new assignments without
having to revise the RFC.

Vijay

> 
> Thanks,
> Yaron
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Vijay Devarapalli
>> Sent: Saturday, May 30, 2009 0:51
>> To: Yoav Nir; Tero Kivinen
>> Cc: [email-masked]
>> Subject: Re: [IPsec] Some comments about redirect
>> 
>> Ok.
>> 
>> Anyone else have any comments on including "4 - Locally Meaningful Name"?
>> 
>> Vijay
>> 
>> 
>> On 5/27/09 3:14 PM, "Yoav Nir" wrote:
>> 
>>> 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,
>>> 
>>> On 5/27/09 3:11 AM, "Yoav Nir" wrote:
>>> 
>>>> OK. In that case I would add to the initial registry
>>>> 
>>>>   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: Tero Kivinen [[email-masked]]
>>> 
>>> 
>>> Scanned by Check Point Total Security Gateway.
>>> 
>>> Email secured by Check Point
>> 
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> Scanned by Check Point Total Security Gateway.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Jun 2009 09:18:08 +0300

Hi Vijay,

I agree there is no consensus on the "locally meaningful name". But I'd like
to hear more opinions before we add new stuff to the draft at this late
stage.

Regarding private values: We want to encourage experimentation with the
protocol, and private values are an important part of that. People may not
have stable documentation when they start to deploy a system, or such
documentation may be confidential. Private use ranges provide an easy way
for vendors to deal with such cases. In this particular case, I don't see
any reason NOT to include a private range.

Thanks,
	Yaron

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, June 11, 2009 2:19
> To: Yaron Sheffer; Yoav Nir; Tero Kivinen
> Cc: [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jun 2009 12:00:52 +0300

> any reason NOT to include a private range.

The reason I was supporting "locally meaningful name" is that in most
cases the redirection support is used inside one adminstrative domain
and that adminstrative domain often use some kind of centralized
policy distribution system and that means that all clients & gateways
will have some kind of "locally meaningful name" in their centrally
distributed policy and redirecting from one name to another makes more
sense than redirecting from one IP to another.

As those implementations used there are quite often also from same
vendor I assume private use range could also be used here without any
problems.

So I think we need at least the private use range so vendors can use
that one number from there as their "locally meaningful name".
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jun 2009 14:13:24 -0700

Hello Yaron, Tero,

Ok, I am fine with setting aside some space for private GW identity. Lets
set aside 240-255.

Since we have the private space, I guess we don't need the "locally
meaningful name" as a GW identity.

Vijay

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jun 2009 15:49:22 -0400

Yaron,

Add me to the list of folks who does not understand how a locally 
meaningful name works.  I'd like to see a more thorough discussion of 
this notion before we proceed.

Steve