Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding
Luigi Iannone <ggx@gigix.net> Fri, 02 October 2020 08:56 UTC
Return-Path: <ggx@gigix.net>
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 BA1E93A0F18 for <lisp@ietfa.amsl.com>; Fri, 2 Oct 2020 01:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.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 zFxvYDHXe2vz for <lisp@ietfa.amsl.com>; Fri, 2 Oct 2020 01:56:31 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 600BC3A0F12 for <lisp@ietf.org>; Fri, 2 Oct 2020 01:56:31 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id t17so871082wmi.4 for <lisp@ietf.org>; Fri, 02 Oct 2020 01:56:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mgnQj4bSa4htpSYKXyIWv6yJkVRhe9fVfziPZujPXjc=; b=OKYXZfSRzVi6aY7a/D7gdcsJl2N2TfmrQqhhFYkxGJ3e5mCK7TeVvE7Un3F7PTyAz8 arxi/4A36UNzxTe6n2gDddb0OyZ5QBaVbrJZKLFb8gq7UnOvPRLp6P7dxwXn6OL/VUk8 P2qCvdsVdaH3wooeqxTyqQOuTrShVcsmtIp4sYr8Vh2l61tkCYdsDUgfiKLXc3UJwjbI BaKWoqGw+rlGRZJOWhvCCr/Qa8rZ9EpRBrq3QDGdn7G2EW594zaNMZDlaT6HmE7jLO+Q 47VnN3TGh4nUp81CfgGZSLWOl2s//4G/v73v1wD6iSx4dmN2zn008UfC5E0S4Vn9f/0Z 68wA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mgnQj4bSa4htpSYKXyIWv6yJkVRhe9fVfziPZujPXjc=; b=PFv7H0v6VfpAIEL2Y8vOa7bKgiuBXWrwaXjCoTo2YVeJ3w0bA7uwHpQ/COTadhEV68 QU2zoMKLRphAhJw92oJ0lS+mDqmHCgRJBoMUkeQ+79q2OCRpFgPObhIe0klvIAC383zi NPMTMkQDJgvZ+gJsUyVWknlrA+/az/L+xVI27BW7k4Hnk2IbTo8FzeiSSqIfzL1DMxDr QXqksP98kZQfgb+/4mweLmRwWMx2CuuhZxThSY8xEQCF5/lD33BHsKgh4YQ8+s3QMRc5 ADVUkNuCmHinzlm/EE/ibEWk7FYaN3NtNGOkZS3Ctf1XSExBpjPUX6HbQXScyQVfhASM HQwA==
X-Gm-Message-State: AOAM530WPXgjHScCB6EJo+wyrqhbbPAE1aZar5nTHRaTlYWwW2n/6flC x+90IQn6VfGSZKaiJ9BN5ZjIqA==
X-Google-Smtp-Source: ABdhPJzMYclhB2Z/RhJCngEaKwqcCH9wZBuLDr5LmUJWQqqCkIzV+BPYk9Ujqq6OvkA96Sk4pxm0gQ==
X-Received: by 2002:a7b:c4d1:: with SMTP id g17mr1591343wmk.167.1601628989388; Fri, 02 Oct 2020 01:56:29 -0700 (PDT)
Received: from ?IPv6:2a01:e0a:1ec:470:b825:e063:3650:2011? ([2a01:e0a:1ec:470:b825:e063:3650:2011]) by smtp.gmail.com with ESMTPSA id z191sm983652wme.40.2020.10.02.01.56.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 01:56:28 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <61AF04E6-BC8F-43E3-9719-9DDB8AA4081A@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95EE94C3-36C4-4464-AB02-2BCC43534332"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 02 Oct 2020 10:56:27 +0200
In-Reply-To: <D8703342-8336-49E8-997E-9A5BE08C8602@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "lisp@ietf.org list" <lisp@ietf.org>
To: Dino Farinacci <farinacci@gmail.com>
References: <88FFF16F-1E5F-4B41-B4A1-D3E02750F9BA@gmail.com> <D8703342-8336-49E8-997E-9A5BE08C8602@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/MfLU1WqC6EzoVuJTt3fuu9HObRU>
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: Fri, 02 Oct 2020 08:56:34 -0000
Dino, This document has been sitting around for 4 years indeed, but it has been presented to the WG for discussion only during IETF 96 (Summer 2016). https://www.ietf.org/proceedings/96/lisp.html <https://www.ietf.org/proceedings/96/lisp.html> The presentation was only 2 slides long and had no comments (you can check the minutes). No discussions have being going on ever since, neither in the mailing list nor during face to face meetings. You have all rights to ask for adoption, but not to formally open the call for adoption. IETF procedures want that is up to the chairs to open the adoption call. Even so, your _informal_ call for adoption has raised 2 supports and 1 objection. At this stage there are no sufficient elements that allow the chairs to declare consensus for adoption. What I would suggest is: - to continue the technical discussion on the mailing list - the more the better - present the document during one of the next meetings - Please focus on why this is needed from a technical standpoint. Just stating I use it in another document is not a technical reason. - If at that point there is interest from the WG, we will make the call for adoption. I encourage you all to continue the discussion. Ciao Luigi > On 1 Oct 2020, at 05:04, Dino Farinacci <farinacci@gmail.com> wrote: > > Well chairs - can you make a decision? > > Dino > >> On Sep 29, 2020, at 1:58 PM, Dino Farinacci <farinacci@gmail.com> wrote: >> >> 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 >> >>> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern <jmh@joelhalpern.com> 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. >>> >>> 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 > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp
- [lisp] Request for WG document - draft-farinacci-… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Sharon
- Re: [lisp] Request for WG document - draft-farina… Lori Jakab (lojakab)
- Re: [lisp] Request for WG document - draft-farina… Albert López
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Albert López
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Luigi Iannone
- Re: [lisp] Request for WG document - draft-farina… Luigi Iannone
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel Halpern Direct
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci
- Re: [lisp] Request for WG document - draft-farina… Joel M. Halpern
- Re: [lisp] Request for WG document - draft-farina… Dino Farinacci