Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-update

Stuart William Card <stu.card@critical.com> Mon, 17 October 2022 13:27 UTC

Return-Path: <stu.card@critical.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9918C152590 for <dtn@ietfa.amsl.com>; Mon, 17 Oct 2022 06:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzL_LDxEJp7T for <dtn@ietfa.amsl.com>; Mon, 17 Oct 2022 06:27:46 -0700 (PDT)
Received: from mail.critical.com (mail.critical.com [209.217.211.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8FC152597 for <dtn@ietf.org>; Mon, 17 Oct 2022 06:27:45 -0700 (PDT)
Received: by mail.critical.com (Postfix, from userid 99) id 3DDAC3801D; Mon, 17 Oct 2022 09:22:13 -0400 (EDT)
Received: from www.critical.com (unknown [192.168.6.38]) by mail.critical.com (Postfix) with ESMTP id BDCD14FE6; Mon, 17 Oct 2022 09:22:10 -0400 (EDT)
Received: from 72.10.210.250 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Mon, 17 Oct 2022 09:27:41 -0400
Message-ID: <4165c124b081adcc080faf38e2ff483c.squirrel@www.critical.com>
In-Reply-To: <add82918-af9b-857c-fdae-77bbfbff7a7@solarnetone.org>
References: <5a288120-b4f1-6751-7cf2-4fe107089154@critical.com> <94AFBEAC-82F1-4D39-B2B9-C879824C6DAB@gmail.com> <add82918-af9b-857c-fdae-77bbfbff7a7@solarnetone.org>
Date: Mon, 17 Oct 2022 09:27:41 -0400
From: Stuart William Card <stu.card@critical.com>
To: scott@solarnetone.org, Jorge Amodio <jmamodio@gmail.com>
Cc: Rick Taylor <rick@tropicalstormsoftware.com>, dtn@ietf.org
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/9HRo_dr8XOHcB3QaDEZIT7g3xvA>
Subject: Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-update
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2022 13:27:50 -0000

I love the reasonably accurate analogy (especially as a D&D player myself).

In the context of the Host Identity Protocol (HIP), another metaphor would
be the popular fictional idea of being "out of phase". Using Host Identity
Tags (HITs) as endpoint identifiers, e.g. for transport layer protocols,
means connectivity can only be established between endpoints that can use
their HITs to complete a HIP "base exchange", after which communications
are ESP tunneled between them, using any/all logical locators (IP
addresses) their interfaces possess. So the endpoint identifiers are "out
of phase", in a different logical space, despite being assigned from the
overall IPv6 address space. This is _somewhat_ akin to the typical NAT
usage of RFC 1918 private IPv4 addresses, but far from exactly, as NAT
merely maps between global-but-imprecise locators and precise-but-local
locators.

Another aspect of this is that what we typically call a "host" address is
really an _interface_ address. A multihomed host has more than one
interface and typically one unique IP address for each interface; however,
it is still only a single host, and for must purposes it would be
convenient for it to have only a single identifier. One way this can be
accomplished is to give it a single FQDN, but in DNS resolve that one FQDN
to multiple IP addresses.  HITs serve some of the same functions as FQDNs,
but: HITs are OSI Layer 3 (or 3.5, if you like) objects, FQDNs are OSI
Layer 5; each node generates its own HIT from its public key, thus
intrinsically binding them, so only the holder of the corresponding
private key can authenticate as being the owner of that HIT; and there are
ways to use HITs w/o DNS lookups (obviously very handy in DTN).

At last, to directly address Jorge's question. No, Hierarchical HITs are
only in IETF drafts currently, they have not been published as standards.
However, they have been tentatively adopted by the International Civil
Aviation Organization (ICAO) as one class of identifier in the emerging
International Aviation Trust Framework (IATF) for the entire aviation
ecosystem (air and ground, government and private). Their predecessors,
flat HITs, are in the IETF HIP standards, have been used by a couple of
defense aerospace contractors, and are used by one of the world's largest
industrial controls vendors to put their controllers "out of phase" from
(or, in their marketing language, "invisible" to) attackers. Our company
has used them for years, but so far only in prototypes and field tests,
not real deployments; our real deployments have used Mobile IP, but we
intend to replace it with HIP.

> Hi Jorge,
>
>> Just confessing my own ignorance, has HHIT been adopted as a standard
>> even experimental ?
>> What are the use cases/applications?
>
> It has... shields.  And armor.  Plate mail on top of chainmail, but
> reasonably light and unencumbering.  Plus, your armor only fits you, so
> nobody can steal it and use it against you.  Is that about right, Stuart,
> or have I missed key features in translation to analogy?
>
>>
>> I guess it can be used as an alternated scheme.
>
> I vote for this.  Stuart has a good idea here, and there exists a
> mechanism to add new schemes.  It makes lots of sense to use that facility
> to extend functionality in a modular fashion, allowing desired featuresets
> to be implemented without interfering with existing ones.
>
>>
>>> Any node ought to be able to have as many IDs as it likes, e.g., for
>>> different purposes, and as many addresses as it likes, and these ought
>>> to have _nothing to do with each other_,
>>
>> I believe there are no limitations at least on ION to have more than one
>> ID as long as it is unique.
>
> At present that is the case, yes, although certain improvements are being
> brewed up at present, in an ad-hoc "as necessary" basis in experimental
> branches, that better facilitate the handling and configuration of this
> functionality.
>
> Enjoy,
> ScottJ
>
>


-- 
Stuart W. Card, VP & Chief Scientist
Critical Technologies Inc. (CTI)
<stu.card@critical.com>