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.
On 9/29/2020 3:58 PM, Dino Farinacci wrote:
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.
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:
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.
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 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
