Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-05.txt

From: Robert Moskowitz <[email-masked]>
Date: Wed, 13 May 2020 11:22:46 -0400

Some text clean up and references to historical HHIT proposals.

Big item is changing hierarchy for 14/18 to 16/16 per earlier discussion.

We still need discussions on DNS formats.

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-moskowitz-hip-hierarchical-hit-05.txt
Date: 	Wed, 13 May 2020 08:20:20 -0700
From: 	[email-masked]
To: 	Robert Moskowitz <[email-masked]>, Stuart Card 
<[email-masked]>, Adam Wiethuechter 
<[email-masked]>, Stuart W. Card 
<[email-masked]>

A new version of I-D, draft-moskowitz-hip-hierarchical-hit-05.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-hierarchical-hit
Revision: 05
Title: Hierarchical HITs for HIPv2
Document date: 2020-05-12
Group: Individual Submission
Pages: 11
URL: 
https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/
Htmlized: 
https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-05
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-hierarchical-hit-05

Abstract:
This document describes using a hierarchical HIT to facilitate large
deployments of managed devices. Hierarchical HITs differ from HIPv2
flat HITs by only using 64 bits for mapping the Host Identity,
freeing 32 bits to bind in a hierarchy of Registering Entities that
provide services to the consumers of hierarchical HITs.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Wed, 13 May 2020 17:56:05 -0400

Bob,

I'll start some discussion on DNS formatting here.

I will start with what I currently have implemented as a base from which to
work from. It was my understanding that FQDNs can not use the ':' character
in them (I checked RFC952 for this, RFC1123 updates but does not change the
character set other than allowing numbers to lead the string) - so Bob's
method of just using the HHIT as a string of characters wouldn't work as
specified in the current draft.

I translate a HHIT to a FQDN in the following fashion:

2001:000a:bbcc:dddd:dddd:dddd:dddd --> dddddddddddddddd.cc.bb.remoteid.aero

All characters stay as hex through the translation. The HHIT is an exploded
IPv6 address (with 0 padding as needed). I drop the prefix (2001:000) here
as it is assumed to be for a HHIT in this form. I also unintentionally
dropped the OGA ID ('a') - this will be fixed as it is a bug on my side.
Adding in the OGA ID would result in a FQDN like this (at least as I
planned it - note the placement of the 'a'):

dddddddddddddddd.a.cc.bb.remoteid.aero

To discuss dropping the prefix; I did this as a silent optimization for the
current UAS use case. All systems in that implementation would be using
HHITs, we should never see a HIT. However, in the grander scheme of things
(as this draft is in the HIP WG) it makes HHITs more different from regular
HITs. This inherently might not be a bad thing, but perhaps having the
ability to perform a forward lookup of a FQDN based on a HIT may be useful
for some. If we wish to support such a thing when there is a mix of HHITs
and HITs in a network then the prefix can not be dropped. I see two ways
forward with this. I will use the HIT of 2001:000a.dddd.dddd.dddd.dddd.dddd
in my examples.

1. Just add the prefix as another field:
dddddddddddddddd.a.2001000.cc.bb.remoteid.aero. For a HIT it would be like
this: dddddddddddddddddddd.a.2001000.domain.com
2. Use a DNS zone titled hhit/hit to divide the space up:
dddddddddddddddd.a.cc.dd.hhit.remoteid.aero. For a HIT it would be like
this: dddddddddddddddddddd.a.hit.domain.com
3. Just place the HHIT/HIT as is (removing ':'):
2001000abbccdddddddddddddddd.cc.bb.remoteid.aero. For HIT it would be:
2001000adddddddddddddddddddd.domain.com

Both options 1 and 2 require the sending entity to create the FQDN
accordingly (substitute the string "hhit" or "hit" and break up it into
fields). The receiving entity would need to put everything back into order
and perform any necessary substitutions.

Option 3 is what Bob has been suggesting. For the sending entity, just
remove the illegal characters and affix the required domain and TLD (also
the RAA and HDA values if an HHIT to query the proper server). The
receiving entity would need to just put the ':' back in place (which is
trivial as it should be a full IPv6 address with padded 0s, so it's a ':'
every 4 characters).

In my opinion we should stick with using hex characters in the FQDN for all
fields that directly come from the HHIT/HIT. This means that Bob's examples
of a HID DNS entry (using RAA=100 and HDA=50) would look like this:
32.64.hhit.arpa. This means that switching between HHIT and FQDN is just
slicing the HHIT apart as is and requires no conversions to a different
base (base 16 to base 10).

So we have two things to sort out:
1. Do we convert the HDA and RAA fields from base 16 to base 10 when
creating the FQDN? *My answer here is no, keep it base 16.*
2. Do we include the prefix in the FQDN construction, and if so how? *My
answer here is that it should be, but I am not sure the cleanest way from a
design perspective.*

Questions, comments, concerns?

On Wed, May 13, 2020 at 11:23 AM Robert Moskowitz <[email-masked]>
wrote:

> To: Robert Moskowitz <[email-masked]> <[email-masked]>,
> Stuart Card <[email-masked]> <[email-masked]>, Adam
> Wiethuechter <[email-masked]>
> <[email-masked]> <[email-masked]>
>
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

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