Re: [Drip] HHIT field order

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 07 October 2020 09:35 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56E63A0121 for <tm-rid@ietfa.amsl.com>; Wed, 7 Oct 2020 02:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.457
X-Spam-Level:
X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 ywjTnXD4ag26 for <tm-rid@ietfa.amsl.com>; Wed, 7 Oct 2020 02:35:26 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C95F3A011D for <tm-rid@ietf.org>; Wed, 7 Oct 2020 02:35:25 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0979ZOq1015652 for <tm-rid@ietf.org>; Wed, 7 Oct 2020 11:35:24 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 710D520422A for <tm-rid@ietf.org>; Wed, 7 Oct 2020 11:35:24 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 66B1C20423F for <tm-rid@ietf.org>; Wed, 7 Oct 2020 11:35:24 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0979ZOac023287 for <tm-rid@ietf.org>; Wed, 7 Oct 2020 11:35:24 +0200
To: tm-rid@ietf.org
References: <52fb8065-628f-0177-a34b-8456ca796197@labs.htt-consult.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <55f70481-b3f3-6566-bb9c-dbe20afdeb51@gmail.com>
Date: Wed, 07 Oct 2020 11:35:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <52fb8065-628f-0177-a34b-8456ca796197@labs.htt-consult.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/N-5kvqwrlUVxD4KcAWXvjQ4ls5g>
Subject: Re: [Drip] HHIT field order
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2020 09:35:28 -0000


Le 05/10/2020 à 14:56, Robert Moskowitz a écrit :
> This note is going to ask for thoughts on the order of the fields in a 
> HHIT.  Either
> 
> Prefix | Suite ID | RAA | HDA | HI Hash
> 
> or
> 
> Prefix | RAA | HDA | Suite ID | HI Hash
> 
> =================
> 
> In drip-uas-rid, I define the HHIT fields, as I did in 
> draft-moskowitz-hip-arch-02 in '01, as follows:
> 
>     A HHIT is built from the following fields:
> 
>     *  28 bit IANA prefix
> 
>     *  4 bit HIT Suite ID
> 
>     *  16 bit Registered Assigning Authority (RAA)
> 
>     *  16 bit Hierarchical HIT Domain Authority (HDA)
> 
>     *  64 bit ORCHID hash

I do not understand why we need to fix in stones these limits.

In particular, the 64bit ORCHID hash could be as well 66 or 63.

A more flexible stone-setting would be:

- 3 bits from IANA
- m bits for prefix
- n bits for interface ID
- 3+m+n must equal 128; m and n at the discretion of deployer.

Alex

Alex

> 
> 
> But I am proposing a different arrangement in the ICAO/GRAIN IPv6 
> scheme.  First a bit about GRAIN.
> 
> The GRAIN network is for Commercial-Civil aviation:
> 
> "1.2    The network enabling the IATF, the Global Resilient Aviation 
> Interoperable Network"
> (GRAIN), is envisioned as an aviation only (dedicated) IPv6 overlay 
> network on a series of underlying
> networks and supporting network services."
> 
> In some doc that I can't find right now this is limited to 
> commercial/civil aviation.  Further we have:
> 
> "[Please note that all recreational drone operation within Line Of Sight 
> (LOS), Class G airspace are not included in this schema. Recreational 
> drones using point-to-point LOS Command and Control (C2) are outside the 
> scope]"
> 
> So there is a potential and almost for sure bifurcating split in UAS 
> networking.  This does not impact Broadcast Remote ID, but it does 
> impact Network Remote ID.  The actual Remote ID SHOULD be the same for 
> each mode.  (Stu does the reqs say this?)
> 
> The regulators are going to have to figure out the demark.  Are 
> Police/Fire and Small Business like photographers and realtors in GRAIN 
> or out of GRAIN.  It will be interesting, as I suspect it will be a 
> higher cost to be in GRAIN, but there are some advantages to participants.
> 
> I should provide an aside here that the GRAIN prefix plus "platform 
> type" could be /20 so the following reflects this.
> 
> I added HHITs into the GRAIN addressing scheme, minimally for 
> commercial/civil UAS usage.  It could be used for more than UAS within 
> GRAIN.  In doing this I came to thinking two reasons for altering the 
> field order.
> 
> I put the Suite ID after the HID:
> 
> "ICAO DELEGATED NETWORKS /16 FOR PLATFORM TYPE 13 – Hierarchical Host 
> Identifier Tags (HHITs)
> /16 IANA Prefix Addressing Scheme
> 
> Bit #        Field Length        Purpose
> 1 – 16        16            ICAO IPv6 prefix
> 17 – 20        4            Platform type = 13
> 21 – 36       16            GRAIN HHIT RAA
> 37 – 52       16            GRAIN HHIT HDA
> 53 – 56        4            HHIT Crypto Suite
> 57 – 128      72            HHIT HI Hash
> 
> A HHIT Registered Assigning Authority (RAA) will apply for GRAIN 
> membership and be allocated a /36 prefix from this type with their RAA 
> GRAIN number being used in the 16 bits after the platform type. The RAAs 
> will then accept HHIT Hierarchical HIT Domain Authorities (HDA) as 
> sub-members and allocate to them /52 prefixes.
> 
> These HDAs will accept registration from UAS of HHIT Crypto Suite/HI 
> Hash per the IETF DRIP UAS-RID documents using a 72 bit hash. GRAIN HHIT 
> addresses may be for the life of the UAS or may be registered for only 
> some operational period."
> 
> Note, I do NOT envision different Crypto Suites by HDA.  And:
> 
> "A .01% hash collision probability occurs after ~1 Billion HHITs 
> registered (based on the 72 bit hash size) with an HDA. This increases 
> to 1% with ~10 Billion HHITs registered. If an HDA’s business model is 
> to provide a per operation HHIT for delivery UA, and supports a 
> clientele of 1 Million UA making 10 deliveries per day, then the HDA 
> will reach the .01% level in 100 days of operation.  Thus an HDA 
> provider in this type of business may request a block of 128 HDAs from 
> its RAA."
> 
> ========================
> 
> The importance here is putting the Crypto Suite and HI Hash together and 
> the Prefix and aggregation information at the front.  This is good for 
> filtering policy.  It also makes sense in grouping the HIT specific 
> parts and the prefix parts.
> 
> But does it cause any coding or other challenges.  Adam seems to think 
> so and so far he is the only coder active...
> 
> I look forward to a lively debate on this!
> 
> Bob
>