Subject: [Drip] drip-rid - Suite IDs and HIT size

From: Robert Moskowitz <[email-masked]>
Date: Wed, 22 Dec 2021 15:53:44 -0500

fellow drippers.

Stu and I have been privately debating about potential number of Suite 
IDs and how to balance this all.  Plus Stu thinks a CIDR model would 
work for HIDs...

First, I do NOT want to even consider the ORCHID hash shorter than 64 
bits.  Just don't want to deal with potential baggage of 2nd pre-image 
attack issues.

So 64 bits to work with for Prefix, HID, and OGA (Suite IDs).

Right now that is a 28,32,4 bit division.  We are almost out of 
available Suite IDs in that 4-bit space.  Yes, RFC 7401 defines how to 
add 15 more by taking 4 bits from the hash, but see above for concerns.

So Stu's view to increase the OGA to 8 bits is reasonable on some level 
of reasonablity.

This can only be done with either a /24 prefix or a 28-bit HID.  So I 
looked hard at how to work with 28 bits for the HID.

I discard a CIDR approach.  I participated in the original CIDR wg and 
remember Tony Li and others presenting.  I also remember what it took to 
implement this for IPv4.  And the YEARS to put in place the processes to 
support it with IPv6.  IMHO, this is only a viable approach if one of 
the current IPv6 address managers stepped forward and said, "No problem, 
we can easily and cost affordably provide the process here."  Not 
likely.  So what can we do with fixed sizes for RAA and HDA?

Here are my thoughts:

14 bits for each RAA and HDA.  That is 16K for each.

Now there are 193 state members in ICAO.  Say 2 RAAs for starters for 
each state (civil and military) and toss in a few non-state RAAs and we 
are still within 512 RAAs.  OK, double that for good measure and up to 
1024 or only 10 bits needed.  So whoever takes on the RAA number 
assignment process could spread out the numbering such that IF some 
entity comes back asking for another number assignment, it will tend to 
be the next over, making a CIDR-like assignment.

Same thing for an RAA to do with its HDA space.  Spread out the number 
assignment such that if an HDA entity needs more it can get neighboring 
space.  This is actually a real concern for an HDA entity that is 
supporting delivery service UAS that may use a DET per day or per operation.

Now IMO, this is all out of scope of drip-rid, but important to talk 
about to slice down the HID to 28 bits.  I COULD capture this in an 
appendix, but after we agree here, I don't really see the need other for 
people not on this list to see the decision process behind a 14|14 HID.

Going to an 8-bit HHIT Suite ID, would be a new IANA registry, perhaps 
still in the HIP registry space.  It would cleanly map the 4-bit and 4x4 
bit HIPv2 Suite ID and go from there.

Discussion PLEASE.

Oh, as of current with the ICAO routable address space work, DETs have 
an effective /20 prefix.  Either 32-bit HIDs or just larger ORCHID 
hash.  I lean for same HID allocation model, so larger hash.

I want to either make or drop this change for a version I will put 
together early January.

Bob

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 22 Dec 2021 18:47:59 -0500

Thanks Bob.

My argument is simply that CIDR now has been working for many years to
manage the precious pool of addresses in a manner that avoids sparsity
while still enabling growth.
The registries themselves (RAA and HDA in the simple 2 level model, but
this would be generalized) should be the CIDR sub-allocators.
Assuming that the acceptance we are currently getting in aviation leads to
broad adoption there, other sectors will want to adopt this.
That means a single /28 and simple 2 level hierarchy won't cut it.

I propose that we state explicitly in the DET draft that arbitrary prefixes
can be used, provided they accommodate a hash of at least 64 bits and a
HHIT Suite ID of 8 bits.
The HID is however many bits remain after the prefix and before the HHIT
Suite ID and hash.
We would ask for an initial IANA allocation of a /28 for experimental and
general non-intensive use, which leaves 28 bits for the HID.
Meanwhile ICAO is already getting a /16 from IANA for aviation intensive
use, to which they append a 4 bit "platform type", of which a DET/HHIT is
one, so effectively that's a /20 prefix, but they want a 72 bit hash, so
again we have 28 bits for the HID (in a second, separate prefix, with more
likely to follow for other sectors).
Don't forget that HHITs (unlike their predecessor HITs) _are aggregatable_!
Not in IP locator based underlay routing, but in IP identifier based
overlay routing.

On Wed, Dec 22, 2021 at 3:54 PM Robert Moskowitz <[email-masked]>
wrote:

> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 23 Dec 2021 09:15:54 -0500

Stu,

I have been giving this careful thought.

Yes, we (the Internet) now have a lot of experience with CIDR.  Will one 
such organization step up now to include the necessary processes so this 
will get through and be deployed?

Adding CIDR support now without a commitment for deployment, for a lot 
of the world will significantly delay adoption.

And it gets more complicated as you move away for well established parts 
of the world with working policies.

But I have been looking hard at this from the other direction.  You 
receive a DET, how do you learn more about the UAS?  With the fixed 
RAA|HDA structure, with just the HDA attestation of the DET and 
{RAA,HDA} cache, the receiver knows the beginnings about the UAS and how 
to learn more with forward lookups.

With a CIDR approach, the HID becomes an opaque block at first.  The 
cache is of HIDs and some flexible structure for working out what the 
hierarchy is for this DET.  Lot more attestations will be needed.  The 
full chain?  More air time?

Will you please work out what this cache structure is for basic 
interoperability development?  Please provide text for the draft?

Regional caches (vs worldwide) may be harder to support.  Don't know for 
sure, maybe not an issue.

With Internet access, a 'classic' ip6.arpa reverse lookup, returning a 
PTR would return some arbitrary FQDN to find the HDA,USS and what 
hierarchy that HDA,USS is working under.  Minimum of two round trips to 
DNS, versus only one for fixed RAA|HDA.  When you only have 
milliseconds, help is seconds away.

Now there is an attraction to more hierarchy:

Whoever runs the US civil RAA may very much NOT want to deal with each 
US university wanting their own HDA and would welcome turning this over 
to Internet2.  Of course Internet2 may well want their own RAA as they 
are international and would, perhaps, offer services to any university.  
Or Internet2 may get a few RAAs to regionalize the registered UAS into 
regional HDAs.

True, we just DON'T know how best to make deployment simpler.

I am still basically not convinced on the complete value of flexible 
Hierarchy here (CIDR approach).

  * It adds significantly to deployment complexity.
  * It adds significantly to receiver resolution of DET,UAS.
  * It brings more challenges to less developed Internet regions that
    lack IPv6 support.
  * Probably more.

IF someone takes on both adding needed text to the draft AND commits to 
this getting deployed on all aspects of the UAS ecosystem, I am willing 
to bring such someone on board.

I do not see this as easy, nor that a simple change to the drip-rid doc 
to say use flexible, CIDR-like, hierarchy is in our best interest for 
smooth and long-term adoption/use.

Bob

On 12/22/21 18:47, Card, Stu wrote:
> The registries themselves (RAA and HDA in the simple 2 level model, 
> but this would be generalized) should be the CIDR sub-allocators.
> Assuming that the acceptance we are currently getting in aviation 
> leads to broad adoption there, other sectors will want to adopt this.
> I propose that we state explicitly in the DET draft that arbitrary 
> prefixes can be used, provided they accommodate a hash of at least 64 
> bits and a HHIT Suite ID of 8 bits.
> The HID is however many bits remain after the prefix and before the 
> HHIT Suite ID and hash.
> We would ask for an initial IANA allocation of a /28 for experimental 
> and general non-intensive use, which leaves 28 bits for the HID.
> Meanwhile ICAO is already getting a /16 from IANA for aviation 
> intensive use, to which they append a 4 bit "platform type", of which 
> a DET/HHIT is one, so effectively that's a /20 prefix, but they want a 
> 72 bit hash, so again we have 28 bits for the HID (in a second, 
> separate prefix, with more likely to follow for other sectors).
> Don't forget that HHITs (unlike their predecessor HITs) _are 
> aggregatable_! Not in IP locator based underlay routing, but in IP 
> identifier based overlay routing.
>
>
> On Wed, Dec 22, 2021 at 3:54 PM Robert Moskowitz 
> <[email-masked]> wrote:
>
>     fellow drippers.
>