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

"Wiethuechter, Adam" <adam.wiethuechter@axenterprize.com> Wed, 13 May 2020 21:56 UTC

Return-Path: <adam.wiethuechter@axenterprize.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560B43A09AB for <tm-rid@ietfa.amsl.com>; Wed, 13 May 2020 14:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sLHFzlDXVeR for <tm-rid@ietfa.amsl.com>; Wed, 13 May 2020 14:56:17 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7F93A09A9 for <tm-rid@ietf.org>; Wed, 13 May 2020 14:56:17 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id i13so22817604oie.9 for <tm-rid@ietf.org>; Wed, 13 May 2020 14:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7VGIX76TLnVvJPZeAoOdhfxKvxP3BwJ957JXVuGj7V8=; b=OFiTyJ+KccuEpDhmlFkXdKMlRT8LndP8+FhBuJA9zdYd0Xm6jXuzbt917+iG5rpASD x5uz3OyVkAKFpnRNoaSdybNmjoWskqPedZv05QYhteVMwiKnJ3G2rhyeAuoe5B+TokWX KkQ5v388D4i9RGkXpjIxGgx7pIjN/W8Rltx2g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7VGIX76TLnVvJPZeAoOdhfxKvxP3BwJ957JXVuGj7V8=; b=IYDtlUg5sUjCMA4KMa5lk3nBGzmTDyp/ntkDQ99CEoYhMjh1dx4q+tAV869u7xcsER wptXyfCxbg4v5+H74TQ/V2fozQvB7JhMU8cKrADjRetOeuyk5q3SVdIZwpgyRkXI9QVO GJGn1aH5OpXTxymjj3qZiX0lZDz8Ht0Kh/rFY/7nT0fQz82F1uvmlmVwtS3KfurLsNGc 2kQDRHtRWEoWdWgaGkhWKebfHF32wDi6NhteFVdAs3rQ+2TacSyeGNzMjpc2DD/H9/eV Outu5yeg4e6+9XKy5mAvZmJvujEFf/EGwcHHE9ZZ64D666HTMFyjqpZG5JSyzSGqUUT0 Ms3Q==
X-Gm-Message-State: AGi0Pua4I+ChFsKFzNQ+yO/6VZ/cTEJyr3cEzt35uE8rq3KoT3FUdtjL Vhsod40jUSs5zTOGhS/KzKIOgW5udZsB7NZQKd8Z23tp6w==
X-Google-Smtp-Source: APiQypIGZFhPih/hK7zDRuz3g+ca/0ahr9AX/5R0LP+BNa1znKCFys2/Pk+W+GqXDma8E4Ljg738OmMwzccZs67qz4Y=
X-Received: by 2002:a05:6808:207:: with SMTP id l7mr30015895oie.67.1589406976277; Wed, 13 May 2020 14:56:16 -0700 (PDT)
MIME-Version: 1.0
References: <158938322002.10797.13543842461767753800@ietfa.amsl.com> <1a0d0df8-6079-9ad4-eafe-23b511b2579f@labs.htt-consult.com>
In-Reply-To: <1a0d0df8-6079-9ad4-eafe-23b511b2579f@labs.htt-consult.com>
From: "Wiethuechter, Adam" <adam.wiethuechter@axenterprize.com>
Date: Wed, 13 May 2020 17:56:05 -0400
Message-ID: <CA+r8TqVnjuk7s+tVVG36osO0jcGpnEFE3TZLFT9uNvZxdOXzhw@mail.gmail.com>
To: Robert Moskowitz <rgm@labs.htt-consult.com>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000398ef705a58ea63f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/6vj9tJK6FGXjL2rcF3TPjCpYDvU>
Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-05.txt
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Trustworthy Multipurpose RemoteID <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 21:56:21 -0000

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 <rgm@labs.htt-consult.com>
wrote:

> 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: internet-drafts@ietf.org
> To: Robert Moskowitz <rgm@labs.htt-consult.com> <rgm@labs.htt-consult.com>,
> Stuart Card <stu.card@axenterprize.com> <stu.card@axenterprize.com>, Adam
> Wiethuechter <adam.wiethuechter@axenterprize.com>
> <adam.wiethuechter@axenterprize.com>, Stuart W. Card
> <stu.card@axenterprize.com> <stu.card@axenterprize.com>
>
>
> 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
>
>
> --
> Tm-rid mailing list
> Tm-rid@ietf.org
> https://www.ietf.org/mailman/listinfo/tm-rid
>


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