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

Robert Moskowitz <rgm@labs.htt-consult.com> Thu, 19 September 2019 03:11 UTC

Return-Path: <rgm@labs.htt-consult.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 5D2E5120119 for <tm-rid@ietfa.amsl.com>; Wed, 18 Sep 2019 20:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sFCjqVxVYkIc for <tm-rid@ietfa.amsl.com>; Wed, 18 Sep 2019 20:11:31 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CAE1200FE for <tm-rid@ietf.org>; Wed, 18 Sep 2019 20:11:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3DBC662127; Wed, 18 Sep 2019 23:11:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oyuZxWQUdOXD; Wed, 18 Sep 2019 23:11:16 -0400 (EDT)
Received: from lx140e.htt-consult.com (rrcs-50-75-106-130.nys.biz.rr.com [50.75.106.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CAA0E60029; Wed, 18 Sep 2019 23:11:15 -0400 (EDT)
To: "Wiethuechter, Adam" <adam.wiethuechter@axenterprize.com>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <156830694118.16565.8372564577620839780.idtracker@ietfa.amsl.com> <22dea911-bafe-f3ee-db72-590915931326@labs.htt-consult.com> <fa929244-3347-6c6b-91aa-1fcdd8f20e83@labs.htt-consult.com> <CA+r8TqUqUdOoUFWaGSZDhSD32+2+Ni1G2kAKjGVtYQ6vivJ+Bg@mail.gmail.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <6a761520-08aa-be5a-159c-b566382fc0e0@labs.htt-consult.com>
Date: Wed, 18 Sep 2019 23:11:04 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <CA+r8TqUqUdOoUFWaGSZDhSD32+2+Ni1G2kAKjGVtYQ6vivJ+Bg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A98AF692359A54CCCD7C3F97"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/Ip1xN8mm5V0-Y9FI35YL3RlgQTo>
Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-hierarchical-hit-00.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: Thu, 19 Sep 2019 03:11:34 -0000


On 9/18/19 2:54 PM, Wiethuechter, Adam wrote:
> Bob,
>
> Some comments from me that could be useful.
>
> Section 3.1: "... provide an assertion as to why the claim should be 
> trusted and any additional side information about the device." To me 
> this is a series of secondary look-ups to other sources of information 
> that the party in question trusts to be valid and up to date. It is 
> out of scope in a sense as this can vary from use case to use case. 
> Bringing it up how you did I think is perfect to setup the discussion 
> of why this draft is being made.

This is not so uncommon in an Introduction that provides some of the 
justification for the rest of the document.  It basically states why 
have a hierarchy in the HITs at all.  I feel we have a better 
understanding of where HHITs can be used today then we did when I first 
proposed this back in Dec '99:

draft-moskowitz-hip-arch-00



>
> Seeing as I created the python script to create HHITs nothing is new 
> here for me either - its just formalized more. I have nothing much to 
> add here other than to confront the question you have brought up in 
> your recent email. I vote that we strongly consider (if my idea below 
> does not seem sound) a new prefix for HHITs on an initial reading.
>
> Reading 7401 (Section 5.2.10) it is noted that Suite ID is an octet in 
> length with the top 4 bits being the Suite ID and the lower bits set 
> to 0. This was done purposefully to fulfill this quote out out 7401: 
> "This difference is a measure to accommodate larger HIT Suite IDs if 
> the 16 available values prove insufficient.  In that case, one of the 
> 16 values, zero, will be used to indicate that four additional bits of 
> the ORCHID will be used to encode the HIT Suite ID.  Hence, the 
> current four-bit HIT Suite IDs only use the four higher-order bits in 
> the ID field.  Future documents may define the use of the four 
> lower-order bits in the ID field."
>
> Perhaps the lower field could denote if we are an HHIT (or something 
> else) and the upper field stays as is as not to exhaust the list? I 
> may need to think of this more, perhaps this was your first idea but 
> rejected it for a reason I don't see yet. From a programming stand 
> point things could get a bit messy if not standardized correctly, I am 
> hesitant because of this.

I am very hesitant to define HHIT suites by in a sense burning up the 
whole 9 - 16 space.

Plus I would have to take those 4 bits from something.  Either the HID 
or the hash.

HHIT HIT suite ID can be any of the current, plus the new ones I am 
defining.  Thus, for now, I will stay with a new prefix.

>
> If we need to update ORCHID RFC for a new prefix does it hurt to also 
> fold in the construction changes as well in that update?

Possibly.  We will have to see what the sense is from the chairs and AD 
on what documents to update.

>
> On Thu, Sep 12, 2019 at 2:33 PM Robert Moskowitz 
> <rgm@labs.htt-consult.com <mailto:rgm@labs.htt-consult.com>> wrote:
>
>     Some points about Hierarchical HITs.
>
>     The idea is not new.  See draft-moskowitz-hip-04 from 7/01. One
>     bit was used to identity Hierarchical HITs (HHITs) over flat HITs.
>
>     Since this concept was removed I am now faced with how to tell the
>     difference in the HIT encoding?
>
>     HHITs use a different ORCHID construction.  Kind of violation the
>     ORCHID rules.  Remains to be seen if it will take a direct
>     addendum to ORCHID for this.  The HID is included with the HI in
>     computing the ORCHID.  I often wondered if the HIT Suite should
>     have been included.  Since it wasn't we do have to be careful in
>     specifying HIT Suites so it is not possible to have identical
>     BIT-level HIs for different HIT Suites.  I am not attempting to
>     change this part; maybe I should.
>
>     So given a HIT in the wild (I1, or UAS RID broadcast), how do you
>     know if it is a HHIT.  Instead of burning through HIT suites as I
>     first thought in draft-moskowitz-hierarchical-hip, I am specifying
>     a unique HIT prefix for HHITs.
>
>     If anyone can see any other way, please speak up.  Again, the
>     ORCHID prefix is specified in the ORCHID RFC.  Will we best do an
>     update to ORCHID?
>
>     Please chime in.
>
>     Bob
>
>     On 9/12/19 12:52 PM, Robert Moskowitz wrote:
>>     Hello all.
>>
>>     Finally we are now funded to work on this project.  I am very
>>     unhappy at what it took to get to this point. Fortunately, I have
>>     been using the time to put together some notes that I am quickly
>>     turning into drafts.
>>
>>     So work on tm-rid is now open.  Two more drafts will be posted in
>>     the next couple days.  I welcome reviews and comments.
>>
>>     Also I will be working with the AD for time at IETF106.
>>
>>     Bob
>>
>>
>>     -------- Forwarded Message --------
>>     Subject: 	New Version Notification for
>>     draft-moskowitz-hip-hierarchical-hit-00.txt
>>     Date: 	Thu, 12 Sep 2019 09:49:01 -0700
>>     From: 	internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>     To: 	Stuart Card <stu.card@axenterprize.com>
>>     <mailto:stu.card@axenterprize.com>, Adam Wiethuechter
>>     <adam.wiethuechter@axenterprize.com>
>>     <mailto:adam.wiethuechter@axenterprize.com>, Robert Moskowitz
>>     <rgm@labs.htt-consult.com> <mailto:rgm@labs.htt-consult.com>,
>>     Stuart W. Card <stu.card@axenterprize.com>
>>     <mailto:stu.card@axenterprize.com>
>>
>>
>>
>>
>>     A new version of I-D, draft-moskowitz-hip-hierarchical-hit-00.txt
>>     has been successfully submitted by Robert Moskowitz and posted to the
>>     IETF repository.
>>
>>     Name: draft-moskowitz-hip-hierarchical-hit
>>     Revision: 00
>>     Title: Hierarchical HITs for HIPv2
>>     Document date: 2019-09-12
>>     Group: Individual Submission
>>     Pages: 9
>>     URL:
>>     https://www.ietf.org/internet-drafts/draft-moskowitz-hip-hierarchical-hit-00.txt
>>     Status:
>>     https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/
>>     Htmlized:
>>     https://tools.ietf.org/html/draft-moskowitz-hip-hierarchical-hit-00
>>     Htmlized:
>>     https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-hierarchical-hit
>>
>>
>>     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 <http://tools.ietf.org>.
>>
>>     The IETF Secretariat
>>
>>
>
>     -- 
>     Robert Moskowitz
>     Owner
>     HTT Consulting
>     C: 248-219-2059
>     F: 248-968-2824
>     E: rgm@labs.htt-consult.com <mailto:rgm@labs.htt-consult.com>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>     -- 
>     Tm-rid mailing list
>     Tm-rid@ietf.org <mailto:Tm-rid@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tm-rid
>
>
>
> -- 
> 73's,
> Adam T. Wiethuechter

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:rgm@labs.htt-consult.com

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