Subject: [Drip] HHIT field order

From: Robert Moskowitz <[email-masked]>
Date: Mon, 5 Oct 2020 08:56:44 -0400

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

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 5 Oct 2020 09:58:53 -0400

I address here only the one question Bob directed specifically to me.

Yes, ASTM F3411 (cited by EASA & FAA) requires that all mandatory elements
of information in UAS RID be the same whether sent via Broadcast or Network.

The UAS ID itself is the most fundamental of these.

This obviously may have implications for HHIT structure given the different
prefix lengths of generic HIP vs GRAIN etc.

I feel we may be obsessing excessively about hash collisions, as the most
basic function of a HDA should be to reject attempts to register colliding
HHITs.

Adam & I are flight testing for FAA all week, with 1 of 2 major focii being
UAS RID (the other is UTM interoperability of several USS from different
providers).

That is positive for DRIP but means our attention to this email list,
including responses to queries driving editing of drafts, will be limited.

Fortunately, except for the questions I asked over the weekend, some of the
most recent review, & final proofreading, the Requirements draft is done
per inputs received from all prior reviews & meetings. :-)

On Mon, Oct 5, 2020, 8:57 AM Robert Moskowitz <[email-masked]>
wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Oct 2020 16:44:02 -0400

> This note is going to ask for thoughts on the order of the fields in a

So, this is fundamentally about how the reverse-DNS delegation is going to work.
Who delegates to who.

    > Prefix | Suite ID | RAA | HDA | HI Hash

In this scenario, the RAA has to go IANA to get a specific SuiteID prefix.
This means that there is potentially an expert review involved in that step.
OTOH, nobody is going to do this until some Suite is now going to get deployed.

    > Prefix | RAA | HDA | Suite ID | HI Hash

This empowers the HDAs to experiment with new Suites on their own.

    > higher cost to be in GRAIN, but there are some advantages to

I don't quite understand this issue as it relates to order.

    > 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

okay, I can buy that argument.

    > so and so far he is the only coder active...

Do tell what the coding challenges are.
I'd think that the biggest challenge is know what Bob is thinking, and
getting it into code.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Oct 2020 11:35:24 +0200

> Prefix | RAA | HDA | Suite ID | HI 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

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 7 Oct 2020 09:11:26 -0400

On 10/7/20 5:35 AM, Alexandre Petrescu wrote:
>> This note is going to ask for thoughts on the order of the fields in 
>> a HHIT.  Either
>>

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...

>> "[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]"
>>
>> impact Network Remote ID.  The actual Remote ID SHOULD be the same 
>> for each mode.  (Stu does the reqs say this?)
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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."
>>
>> 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."
>>
>> ========================
>>
>> 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...
>>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 7 Oct 2020 09:55:15 -0400

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 <[email-masked]>
wrote:

> But I am proposing a different arrangement in the ICAO/GRAIN IPv6 scheme.
> First a bit about GRAIN.
>
> 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?)
>
> 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.
>
> GRAIN.  In doing this I came to thinking two reasons for altering the field
> order.
>
> 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."
>
> 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."
>
> ========================
>
> 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...
>
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 7 Oct 2020 10:43:01 -0400

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 --
>
> 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.
>
> 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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>>>     This note is going to ask for thoughts on the order of the
>>>     fields in a HHIT.  Either
>>>
>     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.
>
>>>     But I am proposing a different arrangement in the ICAO/GRAIN
>>>     IPv6 scheme.  First a bit about GRAIN.
>>>
>>>     "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
>>>     "[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?)
>>>
>>>     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.
>>>
>>>     "ICAO DELEGATED NETWORKS /16 FOR PLATFORM TYPE 13 – Hierarchical
>>>     Host Identifier Tags (HHITs)
>>>     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."
>>>
>>>     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
>>>     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.
>>>

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Thu, 8 Oct 2020 13:01:47 -0400

Being the coder I will address your final point (poorly).

My main thing is reading the HHIT and by extension parsing it. If you need
to parse off a nibble/byte/word/dword boundary things get annoying. For
example:

2001:0005:000a:0014:3456:7893:21cb:abcd

Is very easy to understand how HHITs are currently defined. 2001:000 is the
prefix length, 5 is the OGA ID, 000a is the RAA, 0014 is HDA and the rest
is hash.
My concern is losing this readability to quickly and easily parse the HHIT
as such. If two off the fields are odd lengths and cause a hextet to be a
combination of two fields human readability (for those who know the format
and can do it quickly in their head) is lost.

I agree that the Suite ID should be closer to the Hash to allow for
flexibility. However I worry this will make things harder in some cases
when attempting to use on firewalls when parsing the HHIT. Would you need
to have a rule for every Suite ID in the permutation?

On Mon, Oct 5, 2020 at 4:44 PM Michael Richardson <[email-masked]>
wrote:

> a
> GRAIN
> good
> think

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 8 Oct 2020 13:14:25 -0400

On 10/8/20 1:01 PM, Wiethuechter, Adam wrote:
> My main thing is reading the HHIT and by extension parsing it. If you 
> need to parse off a nibble/byte/word/dword boundary things get 
> annoying. For example:
>
> Is very easy to understand how HHITs are currently defined. 2001:000 
> is the prefix length, 5 is the OGA ID, 000a is the RAA, 0014 is HDA 
> and the rest is hash.
> My concern is losing this readability to quickly and easily parse the 
> HHIT as such. If two off the fields are odd lengths and cause a hextet 
> to be a combination of two fields human readability (for those who 
> know the format and can do it quickly in their head) is lost.
>
> flexibility. However I worry this will make things harder in some 
> cases when attempting to use on firewalls when parsing the HHIT. Would 
> you need to have a rule for every Suite ID in the permutation?

In our discussions on the GRAIN call, the firewall people wanted policy 
stuff closer to the prefix and reduce the number of rules.

For HHITs, it is thought that policy rules will probably be by RAA 
(maybe by HDA) and any Suite ID allowed, as the endpoints will 'decide' 
which they can process.

>
> On Mon, Oct 5, 2020 at 4:44 PM Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Robert Moskowitz <[email-masked]
>     <mailto:[email-masked]>> wrote:
>         > 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
>
>         > Prefix | RAA | HDA | Suite ID | HI Hash
>
>         >    *  16 bit Registered Assigning Authority (RAA)
>         >    *  16 bit Hierarchical HIT Domain Authority (HDA)
>         >    *  64 bit ORCHID hash
>
>         > 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.
>
>         > 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...
>
>     Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
>     [email-masked] <mailto:[email-masked]>

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Thu, 8 Oct 2020 13:17:40 -0400

Bob,

The Suite ID is still intended to be allocated by IANA correct?
My thought (and I am not sure if this is the direction intended) is that an
HDA could say they only allow certain Suite IDs (up to 16 that they could
define out of a much larger list) and this could mean that Suite ID tables
need to be maintained from HDA to HDA. If IANA is still controlling what
the 16 values are then this problem goes away (I think?).

On Thu, Oct 8, 2020 at 1:14 PM Robert Moskowitz <[email-masked]>
wrote:

> Is very easy to understand how HHITs are currently defined. 2001:000 is
> the prefix length, 5 is the OGA ID, 000a is the RAA, 0014 is HDA and the
> rest is hash.
> For HHITs, it is thought that policy rules will probably be by RAA (maybe
> by HDA) and any Suite ID allowed, as the endpoints will 'decide' which they
> can process.
>
>
>

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 8 Oct 2020 13:47:06 -0400

> The Suite ID is still intended to be allocated by IANA correct?

Not so much as allocated in terms of address, rather registered with 
IANA at:

https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml

> My thought (and I am not sure if this is the direction intended) is 
> that an HDA could say they only allow certain Suite IDs (up to 16 that 
> they could define out of a much larger list) and this could mean that 
> Suite ID tables need to be maintained from HDA to HDA. If IANA is 
> still controlling what the 16 values are then this problem goes away 
> (I think?).

An HDA MUST NOT make up its own Suite ID.  I will include this in the 
draft.  Chaos otherwise.

>
> On Thu, Oct 8, 2020 at 1:14 PM Robert Moskowitz 
>>     My main thing is reading the HHIT and by extension parsing it. If
>>     you need to parse off a nibble/byte/word/dword boundary things
>>     get annoying. For example:
>>
>>     Is very easy to understand how HHITs are currently defined.
>>     2001:000 is the prefix length, 5 is the OGA ID, 000a is the RAA,
>>     0014 is HDA and the rest is hash.
>>     My concern is losing this readability to quickly and easily parse
>>     the HHIT as such. If two off the fields are odd lengths and cause
>>     a hextet to be a combination of two fields human readability (for
>>     those who know the format and can do it quickly in their head) is
>>     lost.
>>
>>     I agree that the Suite ID should be closer to the Hash to allow
>>     for flexibility. However I worry this will make things harder in
>>     some cases when attempting to use on firewalls when parsing the
>>     HHIT. Would you need to have a rule for every Suite ID in the
>>     permutation?
>
>     In our discussions on the GRAIN call, the firewall people wanted
>     policy stuff closer to the prefix and reduce the number of rules.
>
>     (maybe by HDA) and any Suite ID allowed, as the endpoints will
>     'decide' which they can process.
>
>
>>
>>             > This note is going to ask for thoughts on the order of
>>         the fields in a
>>             > HHIT.   Either
>>
>>             > or out of GRAIN.   It will be interesting, as I suspect
>>         it will be a
>>             > 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
>>             > But does it cause any coding or other challenges.  Adam
>>         seems to think
>     E: [email-masked] <mailto:[email-masked]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>
>
>
> -- 
> 73's,
> Adam T. Wiethuechter
> AX Enterprize, LLC
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Oct 2020 13:59:53 -0400

> prefix length, 5 is the OGA ID, 000a is the RAA, 0014 is HDA and the rest

Sure. Humans aren't supposed to look at that :-)
Yes, shifting in the brain is hard.
I think the above was our original proposal, and the new proposal
moves the suiteID to the right.

    > to have a rule for every Suite ID in the permutation?

Why would a firewall parse a HHIT?

Even if you did, you can write firewall rules on any prefix length, not just
multiples of four.

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 8 Oct 2020 16:22:27 -0400

Firewalls & routers like true _prefixes_, in the coding sense, not
arbitrary bit masks. Thus, if an admin wanted to filter traffic that uses a
deprecated (presumably broken crypto) HIT Suite, that would be far easier
if it were to the left of the hierarchy.  OTOH filtering on RAA is easier
if that is to the left. While perhaps RAA filtering may be more likely due
to politics, HIT Suite filtering is more important from a security
perspective.

On Thu, Oct 8, 2020, 2:00 PM Michael Richardson <[email-masked]>
wrote:

> you need
> is the
> cases

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Oct 2020 10:13:18 -0400

Card, Stu <[email-masked]> wrote:
    > arbitrary bit masks. Thus, if an admin wanted to filter traffic that

What traffic?

I wasn't aware that HHIT's would be routable a multi-hop, multi-AS sense in
any of the proposals today.

I can see that they might eventually be /128s that could be fed into a mesh.
This is a really cool thing, and there are existing not-quite-RFCs (any day
now) from ANIMA that provide precedent for C&C links.

but, I'm unaware of where any of this would occur now.

---

From: "Card, Stu" <[email-masked]>
Date: Fri, 9 Oct 2020 10:28:12 -0400

All correct... but also correct in case of RAA & HDA being to left
(MSB-wards) of HIT Suite...

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Oct 2020 10:45:14 -0400

> Why would a firewall parse a HHIT?

When HHITs are used in HIP, a firewall may have rules about what 
hierarchy can connect.  At least this is the thinking from one of the 
companies looking to use this.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Oct 2020 10:47:14 -0400

On 10/8/20 4:22 PM, Card, Stu wrote:
> uses a deprecated (presumably broken crypto) HIT Suite, that would be 
> far easier if it were to the left of the hierarchy.  OTOH filtering on 
> RAA is easier if that is to the left. While perhaps RAA filtering may 
> be more likely due to politics, HIT Suite filtering is more important 
> from a security perspective.

Hmmm.

caught both ways.

>
>
> On Thu, Oct 8, 2020, 2:00 PM Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Wiethuechter, Adam <[email-masked]
>     <mailto:[email-masked]>> wrote:
>         > My main thing is reading the HHIT and by extension parsing
>     it. If you need
>         > to parse off a nibble/byte/word/dword boundary things get
>     annoying. For
>         > example:
>
>         > 2001:0005:000a:0014:3456:7893:21cb:abcd
>
>         > Is very easy to understand how HHITs are currently defined.
>     2001:000 is the
>         > prefix length, 5 is the OGA ID, 000a is the RAA, 0014 is HDA
>     and the rest
>         > is hash.
>
>         > I agree that the Suite ID should be closer to the Hash to
>     allow for
>         > flexibility. However I worry this will make things harder in
>     some cases
>         > when attempting to use on firewalls when parsing the HHIT.
>     Would you need
>         > to have a rule for every Suite ID in the permutation?
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Oct 2020 10:51:10 -0400

> but, I'm unaware of where any of this would occur now.

Potential NRID applications.

But in the HIP I1 payload, not as an IPv6 header.

then there is in ESP, but HIP enables BEET instead of Tunnel mode.

Might be other uses down the road.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 9 Oct 2020 16:57:02 +0200

> any of the proposals today.

I am wondering the same: will HHITs as IP addresses be assigned to 
interfaces?  Will routing table entries contain these IP addresses?

> but, I'm unaware of where any of this would occur now.

I agree, /128s injected in limited domains might work, but I am not sure 
a drone would be allowed to inject its /128 HHOT into the cellular 
network for example.

Alex

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Oct 2020 11:05:21 -0400

On 10/9/20 10:57 AM, Alexandre Petrescu wrote:
>>      > Firewalls & routers like true _prefixes_, in the coding sense, 
>> not
>>      > arbitrary bit masks. Thus, if an admin wanted to filter 
>> traffic that
>>
>> What traffic?
>>

No to Interfaces.  Will they be routed?  GRAIN is allowing for it, but 
most likely not even there.  An Overlay like HIPBONE?

> I agree, /128s injected in limited domains might work, but I am not 
> sure a drone would be allowed to inject its /128 HHOT into the 
> cellular network for example.

Not intended, but firewall rules act more than just on IP and transport 
headers.

However, a cellular provider would have no trouble building out a 5G 
network slide with HHITs for routing prefixes if they could bill for 
it....  :(

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Oct 2020 17:19:50 -0400

> Not intended, but firewall rules act more than just on IP and transport

I would question if there is any value to any ordering, because the rules
will all be /128 rules.

    > However, a cellular provider would have no trouble building out a 5G network
    > slide with HHITs for routing prefixes if they could bill for it....  :(

I claim those would all be /128 routes.
If someone is going to filter on a specific HDA, then the suite ID won't
bother them.

I don't think that there is any reasonable ordering that helps, and I've
built wire-speed packet classifier hardware.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Card, Stu" <[email-masked]>
Date: Fri, 9 Oct 2020 17:37:39 -0400

To paraphrase _The Princess Bride_, clearly you know something that I do
not know. :-) Why would all the rules be /128? I can easily imagine
filtering on IANA prefix, GRAIN "platform type", HIT Suite (as it reflects
choices among cryptosystems, some of which someday will be become too weak
so deprecated), RAA (politics) and/or HDA (reputation for standards
compliance & technical competence). Looking even at fairly modern firewall
rules languages (e.g. Linux nftables), I see built-in support for filtering
on prefixes but not arbitrary bit masks (to match fields somewhere out in
the middle of the 128 bits). Please help me understand your comment. Tnx!

On Fri, Oct 9, 2020, 5:19 PM Michael Richardson <[email-masked]> wrote:

> network

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Oct 2020 16:31:13 -0400

> not know. :-) Why would all the rules be /128? I can easily imagine

Because mesh networking distributes /128 routes, i.e.. specific hosts.
That's the only point of using the HHIT as a source/destination address:
within a mesh of UAS. It has the advantage that we have a credential with that value attested to.

I see no use case for using them to talk to the Internet.
Thus no reason to firewall anything more specific than the /28 that would
keep all HHITs from passing some interface.

1) regardless of the ordering within the HHIT they don't aggregate in a
   useful way in my opinion.  "All the UAS within this square-km" would be
   a useful filter, but that isn't encoded.
   "All the UAS from devices I own", also not encoded except as a list of /128s.
   "All the UAS of my friends", also not encoded.

2) If you had a mesh network among UAS (such as RFC6550), then both IPv6 and
   RPL explicitely support assigning /128s from an upstream /64 to each node.
   This is how Internet connectivity would work.

3) If some 5G operator built out, and had a clue, then they'd be assigning
   addresses over the PPP link, not accepting the HHITs for announcement.