Re: [Drip] HHIT field order

[Robert Moskowitz <[e-mail]>]

Michael Richardson pointed out the strongest argument for Suite ID after 
HID:

The entity registering the RAAs and allocating HHIT prefix space has an 
'easier job' if Suite ID as after RAA as in:

PPPP RRRR HHHH SID HASH

Otherwise the HHIT prefix owner is actually doing 16 allocations to the 
RAA; one for each Suite ID value.

I agree in large measure that the HI Hash size is perhaps addressing 
politics.  But there is the dynamic per operation (or even only day) 
unique HHIT that puts the numbers up into real collision challenges.  I 
am working on the numbers for this...

Bob

On 10/7/20 9:55 AM, Card, Stu wrote:
> 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] <mailto:[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
>>>
>>