[Drip] HHIT field order

Robert Moskowitz <rgm@labs.htt-consult.com> Mon, 05 October 2020 12:57 UTC

Return-Path: <rgm@labs.htt-consult.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 3C02C3A0A06 for <tm-rid@ietfa.amsl.com>; Mon, 5 Oct 2020 05:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 NHgySZ78z2ff for <tm-rid@ietfa.amsl.com>; Mon, 5 Oct 2020 05:57:06 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 DB9F33A0A04 for <tm-rid@ietf.org>; Mon, 5 Oct 2020 05:57:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6AF6F6250B for <tm-rid@ietf.org>; Mon, 5 Oct 2020 08:57:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HluLlNRYHoNU for <tm-rid@ietf.org>; Mon, 5 Oct 2020 08:56:57 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2E46762470 for <tm-rid@ietf.org>; Mon, 5 Oct 2020 08:56:55 -0400 (EDT)
To: "tm-rid@ietf.org" <tm-rid@ietf.org>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <52fb8065-628f-0177-a34b-8456ca796197@labs.htt-consult.com>
Date: Mon, 05 Oct 2020 08:56:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/UxKjmcan6ZOSCPGJp197duaKrd4>
Subject: [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: Mon, 05 Oct 2020 12:57:08 -0000

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


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