RFC 7343

RFC 7343: An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) 🎀

bestie, this one is by J. Laganier (Luminate Wireless, Inc.) and F. Dupont (Internet Systems Consortium) 💖 It's a Standards Track doc from the IETF, published September 2014, with ISSN 2070-1721. It obsoletes RFC 4843 and doesn't update anything. 🌸

Abstract ✨

okay so this doc specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that replaces the one from RFC 4843 🦋 These identifiers are meant to be endpoint identifiers at applications and Application Programming Interfaces (APIs), and not identifiers for network location at the IP layer, i.e., locators. They're built to look like application-layer entities and show up at the existing IPv6 APIs, but they should not appear in actual IPv6 headers 🙈 To feel more like regular IPv6 addresses, they're expected to be routable at an overlay level. So even though they count as non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. iconic, honestly 👑

The ORCHIDs from RFC 4843 had no way to swap out cryptographic algorithms (no cap, that was a real gap 💀). This updated ORCHID format fixes that by putting an index to the suite of cryptographic algorithms in use right inside the identifier itself ✨

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7343.

Copyright Notice 🌈

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Rationale and Intent  . . . . . . . . . . . . . . . . . .   3
  1.2.  ORCHID Properties . . . . . . . . . . . . . . . . . . . .   4
  1.3.  Expected Use of ORCHIDs . . . . . . . . . . . . . . . . .   5
  1.4.  Action Plan . . . . . . . . . . . . . . . . . . . . . . .   5
  1.5.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
2.  Cryptographic Hash Identifier Construction  . . . . . . . . .   5
3.  Routing and Forwarding Considerations . . . . . . . . . . . .   7
4.  Design Choices  . . . . . . . . . . . . . . . . . . . . . . .   8
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Appendix A.  Collision Considerations . . . . . . . . . . . . . .  13
Appendix B.  Changes from RFC 4843  . . . . . . . . . . . . . . .  13

1. Introduction ✨

this doc introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID), a brand-new class of identifiers that are basically like IP addresses 💅 They're meant to be globally unique in a statistical sense (see Appendix A), non-routable at the IP layer, and routable at some overlay layer. They're securely bound, via a secure hash function, to the concatenation of an input bitstring and a context tag. Typically, but not necessarily, the input bitstring will include a suitably encoded public cryptographic key 🔐

1.1. Rationale and Intent

these identifiers are expected to be used at the existing IPv6 Application Programming Interfaces (APIs) and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different overlay protocols. Examples of these include Host Identity Tags (HITs) in the Host Identity Protocol (HIP) [HIPv2] and Temporary Mobile Identifiers (TMIs) for Mobile IPv6 Privacy Extension [PRIVACYTEXT] 🧚

since these identifiers get used alongside IPv6 addresses at both applications and APIs, we need coordination so an ORCHID doesn't get mistaken for a regular IPv6 address, and vice versa. In practice, allocating a separate prefix for ORCHIDs seems to do the trick. That keeps them compatible with IPv6 addresses at the upper layers while making it super easy to block their use at the IP layer 🎀

Using ORCHIDs between consenting hosts without any coordination with the IETF and the IANA is technically possible, but the IETF would consider that practice potentially dangerous 😬 A specific danger would show up if the IETF community later decided to use the ORCHID prefix for some different purpose. Hosts already using the ORCHID prefix would, for practical purposes, be unable to use the prefix for that other new purpose. That would lead to partial balkanization of the Internet, kind of like what happened when IPv4 addresses that are not RFC 1918 [RFC1918] for private use got hijacked historically. messy 💀

The whole need for the proposed allocation comes from wanting to use ORCHIDs with existing applications and APIs. That desire is what creates the potential conflict mentioned above, and resolving the conflict requires the proposed allocation 💖

One can argue that wanting to use these kinds of identifiers via existing APIs is architecturally wrong, and honestly there's some truth in that argument 🙃 It would be more desirable to introduce a new API and update all applications to use identifiers, rather than locators, via that new API. That is exactly what we expect to happen in the long run ✨

Still, given the current state of the Internet, we don't consider it viable to introduce any changes that at once require applications to be rewritten and host stacks to be updated. Instead, we believe in piece-wise architectural changes that require only one of the existing assets to be touched. ORCHIDs are designed for exactly this situation: they let people implement with protocol stack extensions, such as secure overlay routing, HIP, or Mobile IP privacy extensions, without requiring them to update their applications. The goal is to facilitate large-scale deployments with minimum user effort 🫶

For example, at the time of this writing, there already exist HIP implementations that run fully in user space. They use the operating system to divert a certain part of the IPv6 address space to a user-level daemon for HIP processing. In practical terms, these implementations already use a certain IPv6 prefix to tell HIP identifiers apart from IPv6 addresses, which lets both be used by existing applications via existing APIs 🦋

The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] had no mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use 🔥

Because the updated ORCHIDv2 format is not backward compatible, IANA has allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily allocated for the experimental ORCHID was returned to IANA in March 2014 [RFC4843] 🍓

1.2. ORCHID Properties

ORCHIDs are designed to have the following properties:

• Statistical uniqueness (see also Appendix A).
• Secure binding to the input parameters used in their generation (i.e., the Context Identifier and a bitstring).
• Aggregation under a single IPv6 prefix. Note that this is only needed due to the coordination need as indicated above. Without such coordination need, the ORCHID namespace could potentially be completely flat.
• Non-routability at the IP layer, by design.
• Routability at some overlay layer, making them, from an application point of view, semantically similar to IPv6 addresses.

As mentioned above, ORCHIDs are intended to be generated and used in different contexts, as suitable for different mechanisms and protocols. The Context Identifier is meant to be used to differentiate between the different contexts; see Appendix A for a discussion of the related API issues implementation issues and Section 4 for the design choices explaining why the Context Identifiers are used 🌸

1.3. Expected Use of ORCHIDs

Examples of identifiers and protocols that are expected to adopt the ORCHID format include Host Identity Tags (HITs) in the Host Identity Protocol [HIPv2] and the Temporary Mobile Identifiers (TMIs) in the Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT]. The format is designed to be extensible to allow other experimental proposals to share the same namespace 🧚

1.4. Action Plan

This document requests IANA to allocate a prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers 🎀

1.5. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜

2. Cryptographic Hash Identifier Construction ✨

okay so every ORCHID gets made by the ORCHID Generation Algorithm (OGA) 💅. you feed it a bitstring plus a Context Identifier and it spits out an ORCHID 🦋. the hash function it uses is defined by whichever spec covers that usage context (like HIPv2), so the context is the one telling you what hash to use 🌸

 Input      :=  any bitstring
 OGA ID     :=  4-bit Orchid Generation Algorithm identifier
 Hash Input :=  Context ID | Input
 Hash       :=  Hash_function( Hash Input )
 ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )

where:

• | means concatenation of bitstrings 🔗
• Input is a bitstring that is unique or statistically unique within a given context. it's meant to be tied to the to-be-created ORCHID in that context 💖
• Context ID is a randomly generated value that says what usage context the ORCHID is for, and which hash function gets used for making ORCHIDs in that context. these values come out of the namespace set up for Cryptographically Generated Addresses (CGA) Type Tags (see RFC 3972 and http://www.iana.org/assignments/cga-message-types) 🎀
• OGA ID is a 4-bit identifier for the Hash_function used in the specific usage context 🔢
• Hash_function is the one-way hash function (meaning it has preimage resistance and second-preimage resistance) that gets used for whatever value the OGA ID picks. the document defining the context named by the Context ID is what says which one. for example, version 2 of the HIP specification says truncated SHA1 [RFC3174] is the hash to use for generating ORCHIDv2 in HIPv2 when the OGA ID is 3 [HIPv2] 🧠
• Encode_96( ) is an extraction function. its output is the middle 96-bit-long bitstring of the argument ✂️
• Prefix is a constant 28-bit-long bitstring value (2001:20::/28) 👑

To make an ORCHID you need two pieces of input data. the first one can be any bitstring, but it's usually expected to hold a public cryptographic key plus some other stuff 🔑. the second one is a Context Identifier, a 128-bit-long datum allocated the way Section 6 describes. each specific ORCHIDv2 application (like HIP HITs or MIP6 TMIs) is expected to get its own specific Context Identifier 💜

so the input bitstring and the Context Identifier get concatenated into one input datum. that datum goes into the cryptographic hash function that matches the OGA identifier, as set by the document defining the context named by the Context ID 🍓. the hash result then goes through an encoding function and comes out as a 96-bit-long value. that value gets the 28-bit ORCHID prefix and the 4-bit OGA ID stuck on the front. the final thing is the ORCHID: a 128-bit-long bitstring that can be used at the IPv6 APIs in hosts taking part in that particular experiment ✨

the ORCHID prefix comes from the IPv6 global unicast address block, so ORCHIDs look exactly like IPv6 global unicast addresses 👀. BUT, ngl, it should be noted that they don't follow the IPv6 global unicast address format from Section 2.5.4 of [RFC4291], because they don't have a 64-bit Interface ID formatted the way Section 2.5.1. of [RFC4291] describes 🙈

3. Routing and Forwarding Considerations 🦋

ORCHIDs are built to be location-independent endpoint identifiers, not IP-layer locators 📍. so routers MAY be configured not to forward any packet that has an ORCHID as its source or destination address 🚫. if the destination address is an ORCHID but the source address is a valid unicast source address, routers MAY be configured to send back an ICMP Destination Unreachable, Administratively Prohibited message 💀

ORCHIDs are not meant for IPv6 routing protocols, because those protocols are built on the architectural definition of IPv6 addresses 🙅‍♀️. future non-IPv6 routing systems, like overlay routing systems, may be designed around ORCHIDs. any ORCHID-based routing system like that is out of scope for this document 🧚

router software MUST NOT include any special handling code for ORCHIDs 🛑. put another way, if you want the non-routability property of ORCHIDs, it has to come from configuration and not from hardwired software code. for example, the ORCHID prefix can be blocked with a simple configuration rule, like an Access Control List entry 🔒

the big takeaway: don't hardcode ORCHID handling into router software. use config rules instead 💅

4. Design Choices 🎀

this namespace is juggling two competing forces 🤼‍♀️:

• as many bits as possible should be preserved for the hash result.
• it should be possible to share the namespace between multiple mechanisms.

wanting a long hash result means the prefix has to be as short as possible, using few (if any) bits for extra encoding. this design goes all the way with that: every bit past the prefix and the ORCHID Generation Algorithm Identifier is hash output 💪. the downside is there are no bits left in the ORCHID itself for identifying the context. BUT the 4 bits holding the ORCHID Generation Algorithm Identifier give you cryptographic agility for the hash function in use for a given context (see Section 5) 🦋

letting multiple mechanisms share the namespace is handled by putting the Context Identifier into the hash function input 🫶. this means you can't directly tell the mechanism from an ORCHID, but you can check that a given input bitstring and ORCHID belong to a given context, with high probability (but also see Section 5) 🔍

5. Security Considerations 🔐

ORCHIDs are designed to be securely bound to the Context ID and to the bitstring used as the input parameters when they're generated 💖. to get that property, the ORCHID Generation Algorithm relies on the second-preimage resistance (a.k.a. one-way) property of the hash function used in generation [RFC4270]. to keep that property and avoid collisions, it's important that the allocated prefix is as short as possible, leaving as many bits as possible for the hash output 😭

for a given Context ID, all mechanisms using ORCHIDs MUST use exactly the same mechanism for generating an ORCHID from the input bitstring 🚨. allowing different mechanisms without explicitly encoding the mechanism in the Context ID or in the ORCHID itself would enable so-called bidding-down attacks 💀. that means if multiple different hash functions were allowed to build ORCHIDs valid for the same Context ID, and one of those hash functions became insecure, attacks could then reach even the ORCHIDs for that same Context ID that were built with the other, still secure, hash functions 😱

an identifier for the hash function used in ORCHID generation is encoded in the ORCHID itself, while the meaning of the values that identifier can take is defined separately for each Context ID 🧩. so this design lets you use different hash functions per Context ID when building ORCHIDs from input bitstrings. the intent is that the protocol or application using an ORCHIDv2 allocates a Context ID for its use and defines, inside that Context ID's scope, the registry for the ORCHID Generation Algorithm (OGA) ID 📒. the reasoning: different applications can use different hash functions that best fit their needs, so the relatively small OGA ID namespace (4 bits wide, i.e., 16 different values) doesn't run out too fast ⏳. if more secure hash functions are needed later, newer values for the ORCHID Generation Algorithm can be defined for the given Context ID 🔄

to keep the collision probability low (see Appendix A), each method MUST use a mechanism that makes sure distinct input bitstrings are unique or statistically unique within that context 🛡️. there are a few ways to do this. for example, you can put a globally maintained counter value into the input bitstring, a pseudorandom number with sufficient entropy (minimum 96 bits), or a randomly generated public cryptographic key 🎲. the Context ID makes sure input bitstrings from different contexts never overlap. together these make sure the collision probability is decided only by the natural collision odds in the hash space, and isn't raised by the chance of colliding input bitstrings 📉

generating an ORCHIDv2 identifier from an input bitstring involves truncating a hash output to build a fixed-size identifier, similar to the scheme in "Naming Things with Hashes" [RFC6920] 🧃. so the Security Considerations of [RFC6920] about truncating the hash output during identifier generation also apply to ORCHIDv2 generation 🙌

6. IANA Considerations 📋

the updated ORCHIDv2 format isn't backward compatible with the earlier one, so IANA allocated a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per [RFC6890] 🌈. the prefix that was temporarily allocated for the experimental ORCHID got returned to IANA in March 2014 [RFC4843]. the registry info for the allocation looks like this:

Address Block: 2001:20::/28
Name: ORCHIDv2
RFC: RFC 7343
Allocation Date: 2014-07
Termination Date: N/A
Source: True
Destination: True
Forwardable: True
Global: True
Reserved-by-Protocol: False

the Context Identifier (or Context ID) is a randomly generated value that defines the usage context of an ORCHID and the hash function used to generate ORCHIDs in that context 💜. this document defines no specific value. the Context ID shares the namespace introduced for CGA Type Tags, so defining new values follows the rules of Section 8 of [RFC3972], meaning First Come, First Served 🥇. however, no IANA actions are required 🙌

7. Contributors 🫶

Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an earlier, experimental version of this specification [RFC4843] 🌸

8. Acknowledgments 💖

special thanks to Geoff Huston for his sharp but constructive critique during the development of this memo 👑. Tom Henderson helped clarify a number of issues 🧠. this document has also been improved by reviews, comments, and discussions from the IPv6, Internet Area, and IETF communities 🎀

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
           RFC 3972, March 2005.

9.2. Informative References ✨

• [HIPv2] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", Work in Progress, July 2014. 💜
• [PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006. 🦋
• [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🎀
• [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. 🔥
• [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. 💀
• [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 🌸
• [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. 🧚
• [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013. 🌈
• [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013. 🍓

---

Appendix A. Collision Considerations 🔮

Okay so, as we said earlier, the big goal is that as long as keys are not reused, ORCHIDs are globally unique in a statistical sense. ✨ In other words, if you've got an ORCHID pointing at one entity, the chance that the same ORCHID is being used to point at some other entity somewhere on the Internet has to be low enough that you can ignore it for basically every practical purpose. 💅 We're confident the design we picked hits that goal (see Section 4). 🫶

As mentioned above, ORCHIDs are expected to be used at the legacy IPv6 APIs between consenting hosts. 🌸 The Context ID is there to tell apart the different experiments, or contexts, that share the ORCHID namespace. 🎀 BUT here's the tea: the Context ID is not part of the ORCHID itself. It only sits in front of the input bitstring as an input to the hash function. 😭 Yes, this can cause some implementation-related complications, ngl. However, we think letting the hash result part of an ORCHID be longer totally pays off that cost. 💖

Because ORCHIDs are not routable at the IP layer, a sending host that wants to send packets using ORCHIDs at the API level needs extra overlay state inside its stack. 🦋 That state tells it which parameters (for example, which locators) to use in the outgoing packet. 🧚 An underlying assumption here, and a fact in the proposals the authors know about, is that there's an overlay protocol for setting up and maintaining this extra state. 👑 It's assumed that the state-setup protocol carries the input bitstring, and that the resulting ORCHID-related state in the stack can be linked back to the right context and state-setup protocol. 🔥 It's giving organised, honestly. ✨

---

Appendix B. Changes from RFC 4843 🌈

• Updated HIP references to revised HIP specifications. 💜
• Okay, the Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] didn't have a mechanism for cryptographic algorithm agility. 🙈 The updated ORCHID format in this document fixes that by encoding, right in the identifier itself, an index to the suite of cryptographic algorithms in use. 🔥 Iconic glow-up. 💅
• Moved the "Collision Considerations" section into an appendix and removed unnecessary discussions. 🎀
• Removed the discussion on overlay routing. 🦋

---

Authors' Addresses 🫶

Julien Laganier Luminate Wireless, Inc. Cupertino, CA USA

EMail: julien.ietf@gmail.com

Francis Dupont Internet Systems Consortium

EMail: fdupont@isc.org ⭐