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>
- [dtn] Using HHITs for draft-taylor-dtn-ipn-update Robert Moskowitz
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… Rick Taylor
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… scott
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… Rick Taylor
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… scott
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… Stuart W. Card
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… Erik Kline
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… Jorge Amodio
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… scott
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… sburleig.sb
- Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-up… Stuart William Card