Re: [Drip] HHIT field order

["Card, Stu" <[e-mail]>]

AFAIK the sole motivation for putting the HIT Suite / OGA ID to the right
of the RAA & HDA is to facilitate firewall filtering, which is assumed more
likely to care about RAA & HDA than about HIT Suite? If so... I argue that,
as cryptosystems are broken, deprecated & replaced with new ones, firewall
admins would be wiser to filter on HIT Suite, and we would be wiser to give
it 8 bits, thus --

PPPP : TtSS : RRRR : HHHH : <64 bit hash>

P: 16 bit IANA prefix for GRAIN
T: 4 bit GRAIN "platform" type for IPv6 compatible provable identifier
t: 4 bit subtype indicating HHIT
SS: 8 bit HIT Suite
RRRR: 16 bit RAA
HHHH: 16 bit HDA

16+4+4=24 would be effectively the prefix of GRAIN HHITs, 4 bits shorter
than the current /28 for generic (non-GRAIN) non-hierarchical HITs.

This also avoids the need for a long integer library just to handle the
hash. That may or may not be important, as treating the hash value as such
(rather than as just an arbitrary bit sequence) probably implies treating
part of what was hashed as a public key, probably further implying that we
will check signatures, requiring long integer ops.

Again, I think 64 bits is plenty for the hash, as HDAs should reject
attempts to register colliding proposed HHITs in their scope.

This suggestion is also partly political, with the subtype intended to
enlist aid rather than opposition from the promoters of IPv6 compatible
provable identifiers other than HHITs. ;-)

Of course, parameterizing the structure -- at least the field lengths &
possibly also their order -- is more general, but would require an embedded
format specifier, presumably implemented as an index, presumably in the
last few bits of the extended prefix.


On Wed, Oct 7, 2020, 9:11 AM Robert Moskowitz <[e-mail]>
wrote:

>
>
> On 10/7/20 5:35 AM, Alexandre Petrescu wrote:
>
>
>
> 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.
>
>
> In the next version of the draft, there will be an IANA discuss on the
> prefix size.
>
> First, I believe IANA and RIRs do allocations on nibbles.  So the likely
> IANA prefix will be /28 - /16.
>
> For a prefix there has to be an agreement on the RAA size.  The Suite ID
> is currently set at 4 bits.
>
> For each RAA for a given prefix to do its own HDA size and thus HI Hash
> size could be chaos for developers.
>
> In theory anything adding to 128 should work.  In practice...
>
>
> 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
>
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:      248-219-2059
> F:      248-968-2824
> E:      [e-mail]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid
>