draft-ietf-hip-rfc4843-bis-07.txt   draft-ietf-hip-rfc4843-bis-08.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 4843 (if approved) F. Dupont Obsoletes: 4843 (if approved) F. Dupont
Intended status: Standards Track Internet Systems Consortium Intended status: Standards Track Internet Systems Consortium
Expires: December 27, 2014 June 25, 2014 Expires: December 28, 2014 June 26, 2014
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
Version 2 (ORCHIDv2) Version 2 (ORCHIDv2)
draft-ietf-hip-rfc4843-bis-07 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 format that obsoletes RFC4843. These identifiers
are intended to be used as endpoint identifiers at applications and are intended to be used as endpoint identifiers at applications and
Application Programming Interfaces (API) and not as identifiers for Application Programming Interfaces (API) and not as identifiers for
network location at the IP layer, i.e., locators. They are designed network location at the IP layer, i.e., locators. They are designed
to appear as application layer entities and at the existing IPv6 to appear as application layer entities and at the existing IPv6
APIs, but they should not appear in actual IPv6 headers. To make APIs, but they should not appear in actual IPv6 headers. To make
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2014. This Internet-Draft will expire on December 28, 2014.
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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative references . . . . . . . . . . . . . . . . . . 10 9.1. Normative references . . . . . . . . . . . . . . . . . . 10
9.2. Informative references . . . . . . . . . . . . . . . . . 10 9.2. Informative references . . . . . . . . . . . . . . . . . 11
Appendix A. Collision Considerations . . . . . . . . . . . . . . 11 Appendix A. Collision Considerations . . . . . . . . . . . . . . 12
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 11 Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 12
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 IP address-like identifiers.
These identifiers are intended to be globally unique in a statistical These identifiers are intended to be globally unique in a statistical
sense (see Appendix A), non-routable at the IP layer, and routable at sense (see Appendix A), non-routable at the IP layer, and routable at
some overlay layer. The identifiers are securely bound, via a secure some overlay layer. The identifiers are securely bound, via a secure
hash function, to the concatenation of an input bitstring and a hash function, to the concatenation of an input bitstring and a
context tag. Typically, but not necessarily, the input bitstring context tag. Typically, but not necessarily, the input bitstring
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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 ?). (IANA TBD 2001:????::/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 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 experiment (such as HIP HITs specified in Section 6. Each specific ORCHIDv2 application (such as
or MIP6 TMIs) is expected to allocate their own, specific context HIP HITs or MIP6 TMIs) is expected to allocate their own, specific
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.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
called bidding-down attacks. That is, if multiple different hash 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 to use different Context ID. Therefore, the present design allows the use of
hash functions to be used per given Context ID for constructing different hash functions per given Context ID for constructing
ORCHIDs from input bitstrings. If more secure hash functions are ORCHIDs from input bitstrings. The intent is that the protocol or
application using an ORCHIDv2 allocates a Context ID for that use,
and defines, within the scope of that context ID, the registry for
the ORCHID Generation Algorithm (OGA) ID. The rationale for this is
to allow different applications to use different hash functions that
satisfies best their specific requirements, such that the relatively
small OGA ID namespace (4 bits wide, i.e., 16 different values) does
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 pseudo-random 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
involves truncation of a hash output to construct a fixed sized
identifier in a fashion similar to the scheme specified in [RFC6920]
for "Naming Things with Hashes". Accordingly, the Security
Considerations of [RFC6920] pertainig to truncation of the hash
output during identifier generation are also applicable to ORCHIDv2
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 is requested to allocate a new 28-bit prefix
out of the IANA IPv6 Special Purpose Address Block, namely out of the IANA IPv6 Special Purpose Address Block, namely
2001:0000::/23, as per [RFC6890]. The prefix that was temporarily 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily
allocated for the experimental ORCHID was returned to IANA in March allocated for the experimental ORCHID was returned to IANA in March
2014 [RFC4843]. 2014 [RFC4843]. The registry information for the allocation is as
follows:
o Address Block: TBD-IANA
o Name: ORCHIDv2.
o RFC: TBD-RFC-Editor-RFC-to-be-ietf-hip-rfc4843-bis.
o Allocation Date - TBD-IANA
o Termination Date - N/A.
o Source: True.
o Destination: True.
o Forwardable: True.
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 name space
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.
7. Contributors 7. Contributors
skipping to change at page 11, line 5 skipping to change at page 11, line 37
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013. 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 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.
 End of changes. 10 change blocks. 
15 lines changed or deleted 54 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/