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

Dino Farinacci <farinacci@gmail.com> Tue, 29 September 2020 19:58 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F155F3A112B for <lisp@ietfa.amsl.com>; Tue, 29 Sep 2020 12:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPVBQ68pz1B7 for <lisp@ietfa.amsl.com>; Tue, 29 Sep 2020 12:58:30 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879F73A1128 for <lisp@ietf.org>; Tue, 29 Sep 2020 12:58:30 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id u3so3281554pjr.3 for <lisp@ietf.org>; Tue, 29 Sep 2020 12:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Y4r4tOFekZoo9c3iIl5OHQKWg37QR+/TZK76fdOMFw=; b=srXHGmN+jl3lISrxwmrxZk4eoG6TV6HtOuAxZCnDmZMfCgfD58Z7KtyHf5ie5QbBLf +O/lMDVUqH0cHIqKntdvQcG16ksrn2kBSDlSI2BRUm+f4YiQ9RMH3oLS44GZycSre7JE nwlBRJGnrz1krhCOHfaVqmeN/FFJWlYRsM0GGX1maGu/53RQJEOLgKwmKDubevUztFcg WPGfBqkV0VxeWqQmGpxqoLKopBeol2lFRxfLvj/ndOyXBMVeeCA5/g/Q/OevWWcqaFVu Hm2M4/vIjC3skTYnW4tpYBW6WXOBHO+AO0L68e+YlEW008m2WqzXiXMlZuSO4SOzU3u6 Ht5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Y4r4tOFekZoo9c3iIl5OHQKWg37QR+/TZK76fdOMFw=; b=VITmls+fB/BFhcEgt1e2H5Znj4iyz+R2VnP7qiQrmGlmcM43Ljj/iM5YCfHnUXEz/5 Q6qTpctEQFj9rFpox1tfZ9QpBA1ONrWRyHQ/+L/gyUolN1CPo14K4dUxtSykqOtGuMSZ btEc1bTDI4Ee322nGZF4S2c6kFvhpiyPzcziaFU4XYbRlcIhUr3aisc91tyNhP0EpX/3 7vhb2U0d3sQyjQzBSg/0sM06HeumOwglbvq6zY+qqPXoADEwp+XuF1jHKFHF2eUVEHCy Zh5AvhyUDw4zAplINRJKtqRAF2Pe+XUcVoyM0+SjBT2+3ff0HqlDeUbPBRBfxFQQcrtZ CPgQ==
X-Gm-Message-State: AOAM530plJ/ktMjtyDt5JOjdQ963V5qQc/AmVE63JoLKHD4H6TjWQmXT z5w8enmKz8Z5fNp37q38iCugj54rYy3BBg==
X-Google-Smtp-Source: ABdhPJxzuOLCEYOqJr60aygfJlTgXkaFrBIz2OtJqnGM/VghLJxJFVrSraQhGeiwbGV9VFGlyLYfBg==
X-Received: by 2002:a17:90a:dd46:: with SMTP id u6mr5649394pjv.67.1601409509898; Tue, 29 Sep 2020 12:58:29 -0700 (PDT)
Received: from ?IPv6:2601:646:9600:af10:60f4:288b:9c9:4794? ([2601:646:9600:af10:60f4:288b:9c9:4794]) by smtp.gmail.com with ESMTPSA id f19sm6773439pfd.45.2020.09.29.12.58.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2020 12:58:25 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <1be68d18-37f4-47a8-2136-b74b45a3e392@joelhalpern.com>
Date: Tue, 29 Sep 2020 12:58:24 -0700
Cc: "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0EBAC8B-3572-41B6-B71D-0B00BBDB2AE7@gmail.com>
References: <8ab7a055-3615-cf04-2749-446ecde2cc38@joelhalpern.com> <8A777782-AF51-48CA-936A-B6BD68C98334@gmail.com> <f6e19069-7df6-8507-67de-194edd9f625a@joelhalpern.com> <5B6F5137-C628-459A-9EB0-767635D5A622@gmail.com> <1be68d18-37f4-47a8-2136-b74b45a3e392@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/i3bomY8VluikUo7okgOdtsEO9qg>
Subject: Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 19:58:32 -0000

> 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