Subject: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

From: Dino Farinacci <[email-masked]>
Date: Mon, 14 Sep 2020 11:49:28 -0700

I would like to make this individual submission a working group document. I’d like to hear if there are any objections. And then I would like it to start a WG last call.

The document is a simple encoding of an ASCII string for an EID or RLOC record using AFI=17 (distinguished-name). It has been active since 2016. I believe its time to do something with it.

Thanks in advance,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 27 Sep 2020 00:36:26 -0700

I did not see any objections for this request but I didn’t see any specific support either. Can we get some replies if you support this. Otherwise, it will continue to reside for more than 4 years as an individual submission.

Thanks in advance,
Dino

> On Sep 14, 2020, at 11:49 AM, Dino Farinacci <[email-masked]> wrote:
> 
> 
>

---

From: Sharon <[email-masked]>
Date: Sun, 27 Sep 2020 12:58:19 +0300

Support.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Sep 27, 2020, at 10:36, Dino Farinacci <[email-masked]> wrote:
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Lori Jakab (lojakab)" <[email-masked]>
Date: Mon, 28 Sep 2020 05:17:56 +0000

> I did not see any objections for this request but I didn’t see any specific support either. Can we get some replies if you support this. Otherwise, it will continue to reside for more than 4 years…

I’m supporting the draft to become a WG document.

-Lori

> 
> Thanks in advance,
> Dino
> 
>> On Sep 14, 2020, at 11:49 AM, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Albert López <[email-masked]>
Date: Mon, 28 Sep 2020 07:29:48 +0200

+1

Albert L.

On 27/9/20 9:36, Dino Farinacci wrote:
> I did not see any objections for this request but I didn’t see any 
> specific support either. Can we get some replies if you support this. 
> Otherwise, it will continue to reside for more than 4 years as an 
> individual submission.
>
> Thanks in advance,
> Dino
>
>> I would like to make this individual submission a working group 
>> document. I’d like to hear if there are any objections. And then I 
>> would like it to start a WG last call.
>>
>> The document is a simple encoding of an ASCII string for an EID or 
>> RLOC record using AFI=17 (distinguished-name). It has been active 
>> since 2016. I believe its time to do something with it.
>>
>> Thanks in advance,
>> Dino
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Sep 2020 01:57:27 -0400

As chair, I would really like to see something more than just +1.  For 
example, what do you see this as being useful for?

Yours,
Joel

---

From: Albert López <[email-masked]>
Date: Mon, 28 Sep 2020 11:24:35 +0200

I believe that using a label as an EID/RLOC can be really useful and 
give extra flexibility to LISP. For instance requesting a service by 
name or providing extra information of an EID or RLOC.

Regards

Albert

On 28/9/20 7:57, Joel M. Halpern wrote:
>>> specific support either. Can we get some replies if you support 
>>> this. Otherwise, it will continue to reside for more than 4 years as 
>>> an individual submission.
>>>
>>> Thanks in advance,
>>> Dino
>>>

-- 
Albert López
CCABA System Administrator
Universitat Politècnica de Catalunya
Telf: 93 4017182

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 28 Sep 2020 07:48:30 -0700

> As chair, I would really like to see something more than just +1.  For example, what do you see this as being useful for?

There are several Internet Drafts that show uses for distinguished names. Case in point is the draft-ietf-lisp-ecdsa-auth working group Internet Draft. 

And as Albert said for labeling RLOCs. It makes it easier for operators to run and debug the overlay system. 

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Sep 2020 15:31:23 -0400

Looking again at this draft, and at the example Dino points to, I think 
there is a basic problem with the work and the usage.

the problem is not a problem for the mapping system per se.  It is a 
problem for usage.

The draft does not define any mechanism for structuring, allocating, or 
otherwise managing the space of names.  It does not say "URIs".  It does 
not say "DNS names"  It syas "ASCII string, terminated by 0".

If there is to be standard usage of this, and if there is to be more 
than one such usage, how are collisions avoided?  It is not sufficient 
to say "just don't" as different problems may end up needing overlapping 
name spaces.  The hash usage (below) assumes that the solution is to 
prepend the string "hash:' on the front.  But that is not formally 
defined, and as such is not actually a reliable mechanism.
(Frankly, for the hashes I would prefer to use a different EID LCAF that 
carries the binary hash.)

I suspect that the people supporting this have expectations on how this 
will work.  But it seems sufficiently basic that the semantics, rather 
than the encoding, is where I would expect the WG to start.  Encodings 
are easy.

I will also acknowledge that as chair I have concerns about turning LISP 
into an arbitrary database system.  Our charter is a mapping system in 
support of routing.  I understand why the ECDSA keys need to be in 
there.  But I do not want to fall into the BGP trap of trying to solve 
every problem with the hammer in my hand.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Sep 2020 12:42:06 -0700

> Looking again at this draft, and at the example Dino points to, I think there is a basic problem with the work and the usage.
> 
> the problem is not a problem for the mapping system per se.  It is a problem for usage.
> 
> The draft does not define any mechanism for structuring, allocating, or otherwise managing the space of names.  It does not say "URIs".  It does not say "DNS names"  It syas "ASCII string, terminated by 0".

Because it is designed as a non-structured field where a deployment can decide what the structure is based on the mapping system it uses, or the instance-ID within a mapping system it uses.

The draft’s intent is to define a general encoding for LISP messages. How it will be used is left to other documents.

> If there is to be standard usage of this, and if there is to be more than one such usage, how are collisions avoided?  It is not sufficient to say "just don't" as different problems may end up needing overlapping name spaces.  The hash usage (below) assumes that the solution is to prepend the string "hash:' on the front.  But that is not formally defined, and as such is not actually a reliable mechanism.
> (Frankly, for the hashes I would prefer to use a different EID LCAF that carries the binary hash.)

The ecdsa-auth use-case assumes that the hash length is largest where collisions won’t happen. There are applications that use UUIDs and encodes them in distinguished-name EIDs. UUIDs do not have an allocation authority. And:

> I suspect that the people supporting this have expectations on how this will work.  But it seems sufficiently basic that the semantics, rather than the encoding, is where I would expect the WG to start.  Encodings are easy.

So lets have a look at each Internet Draft that references draft-farinacci-lisp-name-encoding and lets review those semantic encodings.

For draft-farinacci-lisp-simple-nat-00, the RLOCs are encoded with human readable RLOC-names so you can distinguish a multi-homed interface through NATs. That has proved useful for my lispers.net implementation.

> I will also acknowledge that as chair I have concerns about turning LISP into an arbitrary database system.  Our charter is a mapping system in support of routing.  I understand why the ECDSA keys need to be in there.  But I do not want to fall into the BGP trap of trying to solve every problem with the hammer in my hand.

I could encode anything I want in an IPv6 EID and make the LISP mapping system an arbitrary database. I don’t think anyone wants to do this. The mapping system is used for routing, addressing, identity, and location problems (at the network layer).

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Sep 2020 15:47:36 -0400

In line, preserving all for now, but we will need to trim or top-post soon.
Yours,
Joel

On 9/29/2020 3:42 PM, Dino Farinacci wrote:
>> Looking again at this draft, and at the example Dino points to, I 
>> think there is a basic problem with the work and the usage.
>>
>> The draft does not define any mechanism for structuring, allocating, 
>> or otherwise managing the space of names.  It does not say "URIs".  It 
>> does not say "DNS names"  It syas "ASCII string, terminated by 0".
> 
> Because it is designed as a non-structured field where a deployment can 
> decide what the structure is based on the mapping system it uses, or the 
> instance-ID within a mapping system it uses.
> 
> The draft’s intent is to define a general encoding for LISP messages. 
> How it will be used is left to other documents.

I think it really needs more structure.  One does not say "here is a 
shared database; use any key you like and hope not to collide with other 
users."

>> to say "just don't" as different problems may end up needing 
>> overlapping name spaces.  The hash usage (below) assumes that the 
>> solution is to prepend the string "hash:' on the front.  But that is 
>> not formally defined, and as such is not actually a reliable mechanism.
> The ecdsa-auth use-case assumes that the hash length is largest where 
> collisions won’t happen. There are applications that use UUIDs and 
> encodes them in distinguished-name EIDs. UUIDs do not have an allocation 
> authority. And:

the ECDSA draft assumes that no other uses will begin with hash:.  This 
has nothing to do with length.  My concern is not collision amon hashes. 
  It is collision between hashes and other uses of the "distinguished 
name" LCAF.

Note that most uses in the industry for the last 40 yeaars of 
"distinguished name" have gone to some length to be clear how names are 
distinguished.  This does not.  That is what causes me concern.

> 
> 
>> I suspect that the people supporting this have expectations on how 
>> this will work.  But it seems sufficiently basic that the semantics, 
>> rather than the encoding, is where I would expect the WG to start. 
>>  Encodings are easy.
> 
> So lets have a look at each Internet Draft that 
> references draft-farinacci-lisp-name-encoding and lets review those 
> semantic encodings.

Looking at the couple of places you have chosen to use this, and have 
therefore been careful not to collide with yourself really does not tell 
us much.

If you want a sub-type under LCAF, then let's do that.  trying to 
pretend arbitrary strings have distinguishable semantics is asking for 
trouble.

> 
> For draft-farinacci-lisp-simple-nat-00, the RLOCs are encoded with human 
> readable RLOC-names so you can distinguish a multi-homed interface 
> through NATs. That has proved useful for my lispers.net 
> <http://lispers.net> implementation.
> 
>> I will also acknowledge that as chair I have concerns about turning 
>> LISP into an arbitrary database system.  Our charter is a mapping 
>> system in support of routing.  I understand why the ECDSA keys need to 
>> be in there.  But I do not want to fall into the BGP trap of trying to 
>> solve every problem with the hammer in my hand.
> 
> I could encode anything I want in an IPv6 EID and make the LISP mapping 
> system an arbitrary database. I don’t think anyone wants to do this. The 
> mapping system is used for routing, addressing, identity, and location 
> problems (at the network layer).
> 
> Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Sep 2020 12:58:24 -0700

> I think it really needs more structure.  One does not say "here is a shared database; use any key you like and hope not to collide with other users."

I can add that to the draft.

> the ECDSA draft assumes that no other uses will begin with hash:.  This has nothing to do with length.  My concern is not collision amon hashes.  It is collision between hashes and other uses of the "distinguished name" LCAF.

If the hash avoids collisions, then anything you put before it, in totality makes the name unique.

> Looking at the couple of places you have chosen to use this, and have therefore been careful not to collide with yourself really does not tell us much.

If you connect two IPv4 islands behind NATs and register their addresses to the same instance-ID to the same mapping system, those addresses will collide. The same goes for these names. That is what VPNs are used for and hence instance-IDs allows the registering entities to agree to not collide names. 

This is a general principle for the LISP mapping system for all EIDs being used. And note for RLOC-names, they do not have to be unique. They are free-form documentation based names.

> If you want a sub-type under LCAF, then let's do that.  trying to pretend arbitrary strings have distinguishable semantics is asking for trouble.

The AFI encoding is tigher and save less space in the packet and hence why it was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm sure many coders appreceiate this.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Sep 2020 16:23:39 -0400

Another way of looking at my issue here is the many problems the DNS 
folks have had with tXT records.  They are free-form text.  Making them 
useful has proven to be a major challenge.  hence, even as RLOCs rather 
than EIDs (where the collision problem is not an issue), I am concerned 
that adding this is opening a can of worms.

Yours,
Joel

PS: Dino, youa re correct that the hash probably won't collide with 
anything else.  But for anything that is not cryptographically random, 
collision seems a major risk.

PPS: Even for you hash case, you concluded that you needed a type 
discriminator (hash:).  Presumably so taht you would know which one you 
needed for the ECDSA operation.  Sensible.  But if we need that, 
probably eveyrone needs that.  At which point it should be part of the 
definition.  At which point we get into defining the structure of these 
naems with sufficient uniqueness.  Or sub-typing,  Or something.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Sep 2020 13:56:45 -0700

Well I have seen these sorts of issues come up before and it usually is not as bad as designers think they are. In practice, people make up there own rules and out checks and balances in to verify collisions. 

Dino

> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Another way of looking at my issue here is the many problems the DNS folks have had with tXT records.  They are free-form text.  Making them useful has proven to be a major challenge.  hence, even as RLOCs rather than EIDs (where the collision problem is not an issue), I am concerned that adding this is opening a can of worms.
> 
> Yours,
> Joel
> 
> PS: Dino, youa re correct that the hash probably won't collide with anything else.  But for anything that is not cryptographically random, collision seems a major risk.
> 
> PPS: Even for you hash case, you concluded that you needed a type discriminator (hash:).  Presumably so taht you would know which one you needed for the ECDSA operation.  Sensible.  But if we need that, probably eveyrone needs that.  At which point it should be part of the definition.  At which point we get into defining the structure of these naems with sufficient uniqueness.  Or sub-typing,  Or something.
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Sep 2020 13:58:30 -0700

So since there seems to be support and little or no objections, can we make this draft a working group document and continue the discussion. I can add more text to reflect Joel’s comments. 

Thanks for the comments and discussion Joel. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Sep 2020 20:04:58 -0700

Well chairs - can you make a decision?

Dino

> On Sep 29, 2020, at 1:58 PM, Dino Farinacci <[email-masked]> wrote:
>