draft-ietf-hip-rfc4843-bis-08.txt   rfc7343.txt 
Network Working Group J. Laganier Internet Engineering Task Force (IETF) J. Laganier
Internet-Draft Luminate Wireless, Inc. Request for Comments: 7343 Luminate Wireless, Inc.
Obsoletes: 4843 (if approved) F. Dupont Obsoletes: 4843 F. Dupont
Intended status: Standards Track Internet Systems Consortium Category: Standards Track Internet Systems Consortium
Expires: December 28, 2014 June 26, 2014 ISSN: 2070-1721 September 2014
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers An IPv6 Prefix for
Version 2 (ORCHIDv2) Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
draft-ietf-hip-rfc4843-bis-08
Abstract Abstract
This document specifies an updated Overlay Routable Cryptographic This document specifies an updated Overlay Routable Cryptographic
Hash Identifiers format that obsoletes RFC4843. These identifiers Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843.
are intended to be used as endpoint identifiers at applications and These identifiers are intended to be used as endpoint identifiers at
Application Programming Interfaces (API) and not as identifiers for applications and Application Programming Interfaces (APIs) and not as
network location at the IP layer, i.e., locators. They are designed identifiers for network location at the IP layer, i.e., locators.
to appear as application layer entities and at the existing IPv6 They are designed to appear as application-layer entities and at the
APIs, but they should not appear in actual IPv6 headers. To make existing IPv6 APIs, but they should not appear in actual IPv6
them more like regular IPv6 addresses, they are expected to be headers. To make them more like regular IPv6 addresses, they are
routable at an overlay level. Consequently, while they are expected to be routable at an overlay level. Consequently, while
considered non-routable addresses from the IPv6 layer point-of-view, they are considered non-routable addresses from the IPv6-layer
all existing IPv6 applications are expected to be able to use them in perspective, all existing IPv6 applications are expected to be able
a manner compatible with current IPv6 addresses. to use them in a manner compatible with current IPv6 addresses.
The Overlay Routable Cryptographic Hash Identifiers originally The Overlay Routable Cryptographic Hash Identifiers originally
defined in RFC4843 lacked a mechanism for cryptographic algorithm defined in RFC 4843 lacked a mechanism for cryptographic algorithm
agility. The updated ORCHID format specified in this document agility. The updated ORCHID format specified in this document
removes this limitation by encoding in the identifier itself an index removes this limitation by encoding, in the identifier itself, an
to the suite of cryptographic algorithms in use. index to the suite of cryptographic algorithms in use.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 28, 2014. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3 1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4 1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 1.3. Expected Use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . 5 2. Cryptographic Hash Identifier Construction . . . . . . . . . 5
3. Routing and Forwarding Considerations . . . . . . . . . . . . 7 3. Routing and Forwarding Considerations . . . . . . . . . . . . 7
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative references . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative references . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Collision Considerations . . . . . . . . . . . . . . 12 Appendix A. Collision Considerations . . . . . . . . . . . . . . 13
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 12 Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document introduces Overlay Routable Cryptographic Hash This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID), a new class of IP address-like identifiers. Identifiers (ORCHID), a new class of identifiers that are like IP
These identifiers are intended to be globally unique in a statistical addresses. These identifiers are intended to be globally unique in a
sense (see Appendix A), non-routable at the IP layer, and routable at statistical sense (see Appendix A), non-routable at the IP layer, and
some overlay layer. The identifiers are securely bound, via a secure routable at some overlay layer. The identifiers are securely bound,
hash function, to the concatenation of an input bitstring and a via a secure hash function, to the concatenation of an input
context tag. Typically, but not necessarily, the input bitstring bitstring and a context tag. Typically, but not necessarily, the
will include a suitably encoded public cryptographic key. input bitstring will include a suitably encoded public cryptographic
key.
1.1. Rationale and Intent 1.1. Rationale and Intent
These identifiers are expected to be used at the existing IPv6 These identifiers are expected to be used at the existing IPv6
Application Programming Interfaces (API) and application protocols Application Programming Interfaces (APIs) and application protocols
between consenting hosts. They may be defined and used in different between consenting hosts. They may be defined and used in different
contexts, suitable for different overlay protocols. Examples of contexts, suitable for different overlay protocols. Examples of
these include Host Identity Tags (HIT) in the Host Identity Protocol these include Host Identity Tags (HITs) in the Host Identity Protocol
(HIP) [I-D.ietf-hip-rfc5201-bis] and Temporary Mobile Identifiers (HIP) [HIPv2] and Temporary Mobile Identifiers (TMIs) for Mobile IPv6
(TMI) for Mobile IPv6 Privacy Extension [PRIVACYTEXT]. Privacy Extension [PRIVACYTEXT].
As these identifiers are expected to be used along with IPv6 As these identifiers are expected to be used along with IPv6
addresses at both applications and APIs, co-ordination is desired to addresses at both applications and APIs, coordination is desired to
make sure that an ORCHID is not inappropriately taken for a regular make sure that an ORCHID is not inappropriately taken for a regular
IPv6 address and vice versa. In practice, allocation of a separate IPv6 address and vice versa. In practice, allocation of a separate
prefix for ORCHIDs seems to suffice, making them compatible with IPv6 prefix for ORCHIDs seems to suffice, making them compatible with IPv6
addresses at the upper layers while simultaneously making it trivial addresses at the upper layers while simultaneously making it trivial
to prevent their usage at the IP layer. to prevent their use at the IP layer.
While being technically possible to use ORCHIDs between consenting While being technically possible to use ORCHIDs between consenting
hosts without any co-ordination with the IETF and the IANA, the IETF hosts without any coordination with the IETF and the IANA, the IETF
would consider such practice potentially dangerous. A specific would consider such practice potentially dangerous. A specific
danger would be realised if the IETF community later decided to use danger would be realized if the IETF community later decided to use
the ORCHID prefix for some different purpose. In that case, hosts the ORCHID prefix for some different purpose. In that case, hosts
using the ORCHID prefix would be, for practical purposes, unable to using the ORCHID prefix would be, for practical purposes, unable to
use the prefix for the other new purpose. That would lead to partial use the prefix for the other new purpose. That would lead to partial
balkanisation of the Internet, similar to what has happened as a balkanization of the Internet, similar to what has happened as a
result of historical hijackings of non-RFC 1918 [RFC1918] IPv4 result of historical hijackings of IPv4 addresses that are not RFC
addresses for private use. 1918 [RFC1918] for private use.
The whole need for the proposed allocation grows from the desire to The whole need for the proposed allocation grows from the desire to
be able to use ORCHIDs with existing applications and APIs. This be able to use ORCHIDs with existing applications and APIs. This
desire leads to the potential conflict, mentioned above. Resolving desire leads to the potential conflict, mentioned above. Resolving
the conflict requires the proposed allocation. the conflict requires the proposed allocation.
One can argue that the desire to use these kinds of identifiers via One can argue that the desire to use these kinds of identifiers via
existing APIs is architecturally wrong, and there is some truth in existing APIs is architecturally wrong, and there is some truth in
that argument. Indeed, it would be more desirable to introduce a new that argument. Indeed, it would be more desirable to introduce a new
API and update all applications to use identifiers, rather than API and update all applications to use identifiers, rather than
skipping to change at page 4, line 8 skipping to change at page 4, line 8
it viable to introduce any changes that, at once, require it viable to introduce any changes that, at once, require
applications to be rewritten and host stacks to be updated. Rather applications to be rewritten and host stacks to be updated. Rather
than that, we believe in piece-wise architectural changes that than that, we believe in piece-wise architectural changes that
require only one of the existing assets to be touched. ORCHIDs are require only one of the existing assets to be touched. ORCHIDs are
designed to address this situation: to allow people to implement with designed to address this situation: to allow people to implement with
protocol stack extensions, such as secure overlay routing, HIP, or protocol stack extensions, such as secure overlay routing, HIP, or
Mobile IP privacy extensions, without requiring them to update their Mobile IP privacy extensions, without requiring them to update their
applications. The goal is to facilitate large-scale deployments with applications. The goal is to facilitate large-scale deployments with
minimum user effort. minimum user effort.
For example, there already exists, at the time of this writing, HIP For example, at the time of this writing, there already exist HIP
implementations that run fully in user space, using the operating implementations that run fully in user space, using the operating
system to divert a certain part of the IPv6 address space to a user system to divert a certain part of the IPv6 address space to a user-
level daemon for HIP processing. In practical terms, these level daemon for HIP processing. In practical terms, these
implementations are already using a certain IPv6 prefix for implementations are already using a certain IPv6 prefix for
differentiating HIP identifiers from IPv6 addresses, allowing them differentiating HIP identifiers from IPv6 addresses, allowing them
both to be used by the existing applications via the existing APIs. both to be used by the existing applications via the existing APIs.
The Overlay Routable Cryptographic Hash Identifiers originally The Overlay Routable Cryptographic Hash Identifiers originally
defined in [RFC4843] lacked a mechanism for cryptographic algorithm defined in [RFC4843] lacked a mechanism for cryptographic algorithm
agility. The updated ORCHID format specified in this document agility. The updated ORCHID format specified in this document
removes this limitation by encoding in the identifier itself an index removes this limitation by encoding, in the identifier itself, an
to the suite of cryptographic algorithms in use. index to the suite of cryptographic algorithms in use.
Because the updated ORCHIDv2 format is not backward compatible with Because the updated ORCHIDv2 format is not backward compatible, IANA
the earlier one, IANA is requested to allocate a new 28-bit prefix has allocated a new 28-bit prefix out of the IANA IPv6 Special
out of the IANA IPv6 Special Purpose Address Block, namely Purpose Address Block, namely 2001:0000::/23, as per [RFC6890]. The
2001:0000::/23, as per [RFC6890]. The prefix that was temporarily prefix that was temporarily allocated for the experimental ORCHID was
allocated for the experimental ORCHID was returned to IANA in March returned to IANA in March 2014 [RFC4843].
2014 [RFC4843].
1.2. ORCHID Properties 1.2. ORCHID Properties
ORCHIDs are designed to have the following properties: ORCHIDs are designed to have the following properties:
o Statistical uniqueness; also see Appendix A o Statistical uniqueness (see also Appendix A).
o Secure binding to the input parameters used in their generation o Secure binding to the input parameters used in their generation
(i.e., the context identifier and a bitstring). (i.e., the Context Identifier and a bitstring).
o Aggregation under a single IPv6 prefix. Note that this is only o Aggregation under a single IPv6 prefix. Note that this is only
needed due to the co-ordination need as indicated above. Without needed due to the coordination need as indicated above. Without
such co-ordination need, the ORCHID namespace could potentially be such coordination need, the ORCHID namespace could potentially be
completely flat. completely flat.
o Non-routability at the IP layer, by design. o Non-routability at the IP layer, by design.
o Routability at some overlay layer, making them, from an o Routability at some overlay layer, making them, from an
application point of view, semantically similar to IPv6 addresses. application point of view, semantically similar to IPv6 addresses.
As mentioned above, ORCHIDs are intended to be generated and used in As mentioned above, ORCHIDs are intended to be generated and used in
different contexts, as suitable for different mechanisms and different contexts, as suitable for different mechanisms and
protocols. The context identifier is meant to be used to protocols. The Context Identifier is meant to be used to
differentiate between the different contexts; see Appendix A for a differentiate between the different contexts; see Appendix A for a
discussion of the related API and kernel level implementation issues, discussion of the related API issues implementation issues and
and Section 4 for the design choices explaining why the context Section 4 for the design choices explaining why the Context
identifiers are used. Identifiers are used.
1.3. Expected use of ORCHIDs 1.3. Expected Use of ORCHIDs
Examples of identifiers and protocols that are expected to adopt the Examples of identifiers and protocols that are expected to adopt the
ORCHID format include Host Identity Tags (HIT) in the Host Identity ORCHID format include Host Identity Tags (HITs) in the Host Identity
Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile Protocol [HIPv2] and the Temporary Mobile Identifiers (TMIs) in the
Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT]. The format
[PRIVACYTEXT]. The format is designed to be extensible to allow is designed to be extensible to allow other experimental proposals to
other experimental proposals to share the same namespace. share the same namespace.
1.4. Action Plan 1.4. Action Plan
This document requests IANA to allocate a prefix out of the IPv6 This document requests IANA to allocate a prefix out of the IPv6
addressing space for Overlay Routable Cryptographic Hash Identifiers. addressing space for Overlay Routable Cryptographic Hash Identifiers.
1.5. Terminology 1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Cryptographic Hash Identifier Construction 2. Cryptographic Hash Identifier Construction
An ORCHID is generated using the ORCHID Generation Algorithm (OGA) An ORCHID is generated using the ORCHID Generation Algorithm (OGA).
below. The algorithm takes a bitstring and a context identifier as The algorithm takes a bitstring and a Context Identifier as input and
input and produces an ORCHID as output. The hash function used in produces an ORCHID as output. The hash function used in the ORCHID
the ORCHID Generation Algorithm is defined for each OGA identifier by Generation Algorithm is defined for each OGA identifier by the
the specification for the respective usage context (e.g., HIPv2). specification for the respective usage context (e.g., HIPv2).
Input := any bitstring Input := any bitstring
OGA ID := 4-bits Orchid Generation Algorithm identifier OGA ID := 4-bit Orchid Generation Algorithm identifier
Hash Input := Context ID | Input Hash Input := Context ID | Input
Hash := Hash_function( Hash Input ) Hash := Hash_function( Hash Input )
ORCHID := Prefix | OGA ID | Encode_96( Hash ) ORCHID := Prefix | OGA ID | Encode_96( Hash )
where: where:
| : Denotes concatenation of bitstrings | : Denotes concatenation of bitstrings
Input : A bitstring that is unique or statistically unique Input : A bitstring that is unique or statistically unique
within a given context. The bitstring is intended within a given context. The bitstring is intended
to be associated with the to-be-created ORCHID in to be associated with the to-be-created ORCHID in
the given context. the given context.
Context ID : A randomly generated value defining the expected Context ID : A randomly generated value defining the expected
usage context for the particular ORCHID and the usage context for the particular ORCHID and the
hash function to be used for generation of ORCHIDs hash function to be used for generation of ORCHIDs
in this context. These values are allocated out of in this context. These values are allocated out of
the namespace introduced for CGA Type Tags; see RFC the namespace introduced for Cryptographically
3972 and Generated Addresses (CGA) Type Tags (see RFC 3972 and
http://www.iana.org/assignments/cga-message-types. http://www.iana.org/assignments/cga-message-types).
OGA ID : A 4-bit long identifier for the Hash_function OGA ID : A 4-bit-long identifier for the Hash_function
in use within the specific usage context. in use within the specific usage context.
Hash_function : The one-way hash function (i.e., hash function Hash_function : The one-way hash function (i.e., hash function
with pre-image resistance and second pre-image with preimage resistance and second-preimage
resistance) to be used as identified by the resistance) to be used as identified by the
value for the OGA ID according document value for the OGA ID according document
defining the context usage identified by the defining the context usage identified by the
Context ID. For example, the version 2 of the Context ID. For example, version 2 of the
HIP specification defines SHA1 [RFC3174] as HIP specification defines truncated SHA1 [RFC3174] as
the hash function to be used to generate the hash function to be used to generate
ORCHIDv2 used in the HIPv2 protocol when the ORCHIDv2 in the HIPv2 protocol when the
OGA ID is 3 [I-D.ietf-hip-rfc5201-bis]. OGA ID is 3 [HIPv2].
Encode_96( ) : An extraction function in which output is obtained Encode_96( ) : An extraction function in which output is obtained
by extracting the middle 96-bit-long bitstring by extracting the middle 96-bit-long bitstring
from the argument bitstring. from the argument bitstring.
Prefix : A constant 28-bit-long bitstring value Prefix : A constant 28-bit-long bitstring value
(IANA TBD 2001:????::/28 ?). (2001:20::/28).
To form an ORCHID, two pieces of input data are needed. The first To form an ORCHID, two pieces of input data are needed. The first
piece can be any bitstring, but is typically expected to contain a piece can be any bitstring, but it is typically expected to contain a
public cryptographic key and some other data. The second piece is a public cryptographic key and some other data. The second piece is a
context identifier, which is a 128-bit-long datum, allocated as Context Identifier, which is a 128-bit-long datum, allocated as
specified in Section 6. Each specific ORCHIDv2 application (such as specified in Section 6. Each specific ORCHIDv2 application (such as
HIP HITs or MIP6 TMIs) is expected to allocate their own, specific HIP HITs or MIP6 TMIs) is expected to allocate their own, specific
context identifier. Context Identifier.
The input bitstring and context identifier are concatenated to form The input bitstring and Context Identifier are concatenated to form
an input datum, which is then fed to the cryptographic hash function an input datum, which is then fed to the cryptographic hash function
to be used for the value of the OGA identifier according to the to be used for the value of the OGA identifier according to the
document defining the context usage identified by the Context ID. document defining the context usage identified by the Context ID.
The result of the hash function is processed by an encoding function, The result of the hash function is processed by an encoding function,
resulting in a 96-bit-long value. This value is prepended with the resulting in a 96-bit-long value. This value is prepended with the
concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The
result is the ORCHID, a 128-bit-long bitstring that can be used at result is the ORCHID, a 128-bit-long bitstring that can be used at
the IPv6 APIs in hosts participating to the particular experiment. the IPv6 APIs in hosts participating to the particular experiment.
The ORCHID prefix is allocated under the IPv6 global unicast address The ORCHID prefix is allocated under the IPv6 global unicast address
block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast
addresses. However, it should be noted that ORCHIDs do not conform addresses. However, it should be noted that ORCHIDs do not conform
with the IPv6 global unicast address format defined in Section 2.5.4 with the IPv6 global unicast address format defined in Section 2.5.4
of [RFC4291] since they do not have a 64-bit Interface ID formatted of [RFC4291] since they do not have a 64-bit Interface ID formatted
as described in Section 2.5.1. of [RFC4291]. as described in Section 2.5.1. of [RFC4291].
3. Routing and Forwarding Considerations 3. Routing and Forwarding Considerations
ORCHIDs are designed to serve as location independent endpoint- ORCHIDs are designed to serve as location-independent endpoint
identifiers rather than IP-layer locators. Therefore, routers MAY be identifiers rather than IP-layer locators. Therefore, routers MAY be
configured not to forward any packets containing an ORCHID as a configured not to forward any packets containing an ORCHID as a
source or a destination address. If the destination address is an source or a destination address. If the destination address is an
ORCHID but the source address is a valid unicast source address, ORCHID but the source address is a valid unicast source address,
routers MAY be configured to generate an ICMP Destination routers MAY be configured to generate an ICMP Destination
Unreachable, Administratively Prohibited message. Unreachable, Administratively Prohibited message.
ORCHIDs are not designed for use in IPv6 routing protocols, since ORCHIDs are not designed for use in IPv6 routing protocols, since
such routing protocols are based on the architectural definition of such routing protocols are based on the architectural definition of
IPv6 addresses. Future non-IPv6 routing systems, such as overlay IPv6 addresses. Future non-IPv6 routing systems, such as overlay
skipping to change at page 8, line 15 skipping to change at page 8, line 15
4. Design Choices 4. Design Choices
The design of this namespace faces two competing forces: The design of this namespace faces two competing forces:
o As many bits as possible should be preserved for the hash result. o As many bits as possible should be preserved for the hash result.
o It should be possible to share the namespace between multiple o It should be possible to share the namespace between multiple
mechanisms. mechanisms.
The desire to have a long hash result requires that the prefix be as The desire to have a long hash result requires that the prefix be as
short as possible, and use few (if any) bits for additional encoding. short as possible and use few (if any) bits for additional encoding.
The present design takes this desire to the maximum: all the bits The present design takes this desire to the maximum: all the bits
beyond the prefix and the ORCHID generation algorithm identifier are beyond the prefix and the ORCHID Generation Algorithm Identifier are
used as hash output. This leaves no bits in the ORCHID itself used as hash output. This leaves no bits in the ORCHID itself
available for identifying the context, however the 4 bits used to available for identifying the context; however, the 4 bits used to
encode the ORCHID generation algorithm identifier provides encode the ORCHID Generation Algorithm Identifier provides
cryptographich agility with respect to the hash function in use for a cryptographic agility with respect to the hash function in use for a
given context; see Section 5. given context (see Section 5).
The desire to allow multiple mechanisms to share the namespace has The desire to allow multiple mechanisms to share the namespace has
been resolved by including the context identifier in the hash- been resolved by including the Context Identifier in the hash
function input. While this does not allow the mechanism to be function input. While this does not allow the mechanism to be
directly inferred from a ORCHID, it allows one to verify that a given directly inferred from an ORCHID, it allows one to verify that a
input bitstring and ORCHID belong to a given context, with high- given input bitstring and ORCHID belong to a given context, with high
probability; but also see Section 5. probability (but also see Section 5).
5. Security Considerations 5. Security Considerations
ORCHIDs are designed to be securely bound to the Context ID and the ORCHIDs are designed to be securely bound to the Context ID and the
bitstring used as the input parameters during their generation. To bitstring used as the input parameters during their generation. To
provide this property, the ORCHID generation algorithm relies on the provide this property, the ORCHID Generation Algorithm relies on the
second-preimage resistance (a.k.a. one-way) property of the hash second-preimage resistance (a.k.a. one-way) property of the hash
function used in the generation [RFC4270]. To have this property and function used in the generation [RFC4270]. To have this property and
to avoid collisions, it is important that the allocated prefix is as to avoid collisions, it is important that the allocated prefix is as
short as possible, leaving as many bits as possible for the hash short as possible, leaving as many bits as possible for the hash
output. output.
For a given Context ID, all mechanisms using ORCHIDs MUST use exactly For a given Context ID, all mechanisms using ORCHIDs MUST use exactly
the same mechanism for generating an ORCHID from the input bitstring. the same mechanism for generating an ORCHID from the input bitstring.
Allowing different mechanisms, without explicitly encoding the Allowing different mechanisms, without explicitly encoding the
mechanism in the Context ID or the ORCHID itself, would allow so- mechanism in the Context ID or the ORCHID itself, would allow
called bidding-down attacks. That is, if multiple different hash so-called bidding-down attacks. That is, if multiple different hash
functions were allowed to construct ORCHIDs valid for the same functions were allowed to construct ORCHIDs valid for the same
Context ID, and if one of the hash functions became insecure, that Context ID, and if one of the hash functions became insecure, that
would allow attacks against even those ORCHIDs valid for the same would allow attacks against even those ORCHIDs valid for the same
Context ID that had been constructed using the other, still secure Context ID that had been constructed using the other, still secure
hash functions. hash functions.
An identifier for the hash function to be used for the ORCHID An identifier for the hash function to be used for the ORCHID
generation is encoded in the ORCHID itself, while the semantic for generation is encoded in the ORCHID itself, while the semantic for
the values taken by this identifier are defined separately for each the values taken by this identifier are defined separately for each
Context ID. Therefore, the present design allows the use of Context ID. Therefore, the present design allows the use of
different hash functions per given Context ID for constructing different hash functions per given Context ID for constructing
ORCHIDs from input bitstrings. The intent is that the protocol or ORCHIDs from input bitstrings. The intent is that the protocol or
application using an ORCHIDv2 allocates a Context ID for that use, application using an ORCHIDv2 allocates a Context ID for that use and
and defines, within the scope of that context ID, the registry for defines, within the scope of that Context ID, the registry for the
the ORCHID Generation Algorithm (OGA) ID. The rationale for this is ORCHID Generation Algorithm (OGA) ID. The rationale for this is to
to allow different applications to use different hash functions that allow different applications to use different hash functions that
satisfies best their specific requirements, such that the relatively best satisfy their specific requirements, such that the relatively
small OGA ID namespace (4 bits wide, i.e., 16 different values) does small OGA ID namespace (4 bits wide, i.e., 16 different values) does
not get exhausted too quickly. If more secure hash functions are not get exhausted too quickly. If more secure hash functions are
later needed, newer values for the ORCHID generation algorithm can be later needed, newer values for the ORCHID Generation Algorithm can be
defined for the given Context ID. defined for the given Context ID.
In order to preserve a low enough probability of collisions (see In order to preserve a low enough probability of collisions (see
Appendix A), each method MUST utilize a mechanism that makes sure Appendix A), each method MUST utilize a mechanism that makes sure
that the distinct input bitstrings are either unique or statistically that the distinct input bitstrings are either unique or statistically
unique within that context. There are several possible methods to unique within that context. There are several possible methods to
ensure this; for example, one can include into the input bitstring a ensure this; for example, one can include into the input bitstring a
globally maintained counter value, a pseudo-random number of globally maintained counter value, a pseudorandom number of
sufficient entropy (minimum 96 bits), or a randomly generated public sufficient entropy (minimum 96 bits), or a randomly generated public
cryptographic key. The Context ID makes sure that input bitstrings cryptographic key. The Context ID makes sure that input bitstrings
from different contexts never overlap. These together make sure that from different contexts never overlap. These together make sure that
the probability of collisions is determined only by the probability the probability of collisions is determined only by the probability
of natural collisions in the hash space and is not increased by a of natural collisions in the hash space and is not increased by a
possibility of colliding input bitstrings. possibility of colliding input bitstrings.
The generation of an ORCHIDv2 identifier from an input bitstring The generation of an ORCHIDv2 identifier from an input bitstring
involves truncation of a hash output to construct a fixed sized involves truncation of a hash output to construct a fixed-size
identifier in a fashion similar to the scheme specified in [RFC6920] identifier in a fashion similar to the scheme specified in "Naming
for "Naming Things with Hashes". Accordingly, the Security Things with Hashes" [RFC6920]. Accordingly, the Security
Considerations of [RFC6920] pertainig to truncation of the hash Considerations of [RFC6920] pertaining to truncation of the hash
output during identifier generation are also applicable to ORCHIDv2 output during identifier generation are also applicable to ORCHIDv2
generation. generation.
6. IANA Considerations 6. IANA Considerations
Because the updated ORCHIDv2 format is not backward compatible with Because the updated ORCHIDv2 format is not backward compatible with
the earlier one, IANA is requested to allocate a new 28-bit prefix the earlier one, IANA has allocated a new 28-bit prefix out of the
out of the IANA IPv6 Special Purpose Address Block, namely IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as
2001:0000::/23, as per [RFC6890]. The prefix that was temporarily per [RFC6890]. The prefix that was temporarily allocated for the
allocated for the experimental ORCHID was returned to IANA in March experimental ORCHID was returned to IANA in March 2014 [RFC4843].
2014 [RFC4843]. The registry information for the allocation is as The registry information for the allocation is as follows:
follows:
o Address Block: TBD-IANA o Address Block: 2001:20::/28
o Name: ORCHIDv2.
o RFC: TBD-RFC-Editor-RFC-to-be-ietf-hip-rfc4843-bis. o Name: ORCHIDv2
o Allocation Date - TBD-IANA o RFC: RFC 7343
o Termination Date - N/A. o Allocation Date: 2014-07
o Source: True. o Termination Date: N/A
o Destination: True. o Source: True
o Forwardable: True. o Destination: True
o Global: True. o Forwardable: True
o Reserved-by-Protocol: False. o Global: True
o Reserved-by-Protocol: False
The Context Identifier (or Context ID) is a randomly generated value The Context Identifier (or Context ID) is a randomly generated value
defining the usage context of an ORCHID and the hash function to be defining the usage context of an ORCHID and the hash function to be
used for generation of ORCHIDs in this context. This document used for generation of ORCHIDs in this context. This document
defines no specific value. The Context ID shares the name space defines no specific value. The Context ID shares the namespace
introduced for CGA Type Tags. Hence, defining new values follows the introduced for CGA Type Tags. Hence, defining new values follows the
rules of Section 8 of [RFC3972], i.e., First Come First Served. rules of Section 8 of [RFC3972], i.e., First Come, First Served.
However, no IANA actions are required.
7. Contributors 7. Contributors
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an
earlier, experimental version of this specification [RFC4843]. earlier, experimental version of this specification [RFC4843].
8. Acknowledgments 8. Acknowledgments
Special thanks to Geoff Huston for his sharp but constructive Special thanks to Geoff Huston for his sharp but constructive
critique during the development of this memo. Tom Henderson helped critique during the development of this memo. Tom Henderson helped
to clarify a number of issues. This document has also been improved to clarify a number of issues. This document has also been improved
by reviews, comments, and discussions originating from the IPv6, by reviews, comments, and discussions originating from the IPv6,
Internet Area, and IETF communities. Internet Area, and IETF communities.
9. References 9. References
9.1. Normative references 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
9.2. Informative references 9.2. Informative References
[I-D.ietf-hip-rfc5201-bis] [HIPv2] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", Work in
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- Progress, July 2014.
hip-rfc5201-bis-14 (work in progress), October 2013.
[PRIVACYTEXT] [PRIVACYTEXT]
Dupont, F., "A Simple Privacy Extension for Mobile IPv6", Dupont, F., "A Simple Privacy Extension for Mobile IPv6",
Work in Progress, July 2006. Work in Progress, July 2006.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
skipping to change at page 12, line 13 skipping to change at page 13, line 13
Hashes", RFC 6920, April 2013. Hashes", RFC 6920, April 2013.
Appendix A. Collision Considerations Appendix A. Collision Considerations
As noted earlier, the aim is that so long as keys are not reused, As noted earlier, the aim is that so long as keys are not reused,
ORCHIDs be globally unique in a statistical sense. That is, given ORCHIDs be globally unique in a statistical sense. That is, given
the ORCHID referring to a given entity, the probability of the same the ORCHID referring to a given entity, the probability of the same
ORCHID being used to refer to another entity elsewhere in the ORCHID being used to refer to another entity elsewhere in the
Internet must be sufficiently low so that it can be ignored for most Internet must be sufficiently low so that it can be ignored for most
practical purposes. We believe that the presented design meets this practical purposes. We believe that the presented design meets this
goal; see Section 4. goal (see Section 4).
As mentioned above, ORCHIDs are expected to be used at the legacy As mentioned above, ORCHIDs are expected to be used at the legacy
IPv6 APIs between consenting hosts. The context ID is intended to IPv6 APIs between consenting hosts. The Context ID is intended to
differentiate between the various experiments, or contexts, sharing differentiate between the various experiments, or contexts, sharing
the ORCHID namespace. However, the context ID is not present in the the ORCHID namespace. However, the Context ID is not present in the
ORCHID itself, but only in front of the input bitstring as an input ORCHID itself but is only in front of the input bitstring as an input
to the hash function. While this may lead to certain implementation- to the hash function. While this may lead to certain implementation-
related complications, we believe that the trade-off of allowing the related complications, we believe that the trade-off of allowing the
hash result part of an ORCHID being longer more than pays off the hash result part of an ORCHID being longer more than pays off the
cost. cost.
Because ORCHIDs are not routable at the IP layer, in order to send Because ORCHIDs are not routable at the IP layer, in order to send
packets using ORCHIDs at the API level, the sending host must have packets using ORCHIDs at the API level, the sending host must have
additional overlay state within the stack to determine which additional overlay state within the stack to determine which
parameters (e.g., what locators) to use in the outgoing packet. An parameters (e.g., what locators) to use in the outgoing packet. An
underlying assumption here, and a matter of fact in the proposals underlying assumption here, and a matter of fact in the proposals
that the authors are aware of, is that there is an overlay protocol that the authors are aware of, is that there is an overlay protocol
for setting up and maintaining this additional state. It is assumed for setting up and maintaining this additional state. It is assumed
that the state-set-up protocol carries the input bitstring, and that that the state-setup protocol carries the input bitstring and that
the resulting ORCHID-related state in the stack can be associated the resulting ORCHID-related state in the stack can be associated
back with the appropriate context and state-set-up protocol. back with the appropriate context and state-setup protocol.
Appendix B. Changes from RFC 4843 Appendix B. Changes from RFC 4843
o Updated HIP references to revised HIP specifications. o Updated HIP references to revised HIP specifications.
o The Overlay Routable Cryptographic Hash Identifiers originally o The Overlay Routable Cryptographic Hash Identifiers originally
defined in [RFC4843] lacked a mechanism for cryptographic defined in [RFC4843] lacked a mechanism for cryptographic
algorithm agility. The updated ORCHID format specified in this algorithm agility. The updated ORCHID format specified in this
document removes this limitation by encoding in the identifier document removes this limitation by encoding, in the identifier
itself an index to the suite of cryptographic algorithms in use. itself, an index to the suite of cryptographic algorithms in use.
o Moved the collision considerations section into an annex, and o Moved the "Collision Considerations" section into an appendix and
removed unnecessary discussions. removed unnecessary discussions.
o Removed the discussion on overlay routing. o Removed the discussion on overlay routing.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA USA
 End of changes. 77 change blocks. 
187 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/