draft-ietf-hip-rfc4843-bis-04.txt   draft-ietf-hip-rfc4843-bis-05.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Juniper Networks 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: November 7, 2013 May 6, 2013 Expires: June 14, 2014 December 11, 2013
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-04 draft-ietf-hip-rfc4843-bis-05
Abstract Abstract
This document specifies an updated Overlay Routable Cryptographic This document specifies an updated Overlay Routable Cryptographic
Hash Identifiers format that obsoletes the earlier format defined in Hash Identifiers format that obsoletes RFC4843. These identifiers
[RFC4843]. These identifiers are intended to be used as endpoint are intended to be used as endpoint identifiers at applications and
identifiers at applications and Application Programming Interfaces Application Programming Interfaces (API) and not as identifiers for
(API) and not as identifiers for network location at the IP layer, network location at the IP layer, i.e., locators. They are designed
i.e., locators. They are designed to appear as application layer to appear as application layer entities and at the existing IPv6
entities and at the existing IPv6 APIs, but they should not appear in APIs, but they should not appear in actual IPv6 headers. To make
actual IPv6 headers. To make them more like regular IPv6 addresses, them more like regular IPv6 addresses, they are expected to be
they are expected to be routable at an overlay level. Consequently, routable at an overlay level. Consequently, while they are
while they are considered non-routable addresses from the IPv6 layer considered non-routable addresses from the IPv6 layer point-of-view,
point-of-view, all existing IPv6 applications are expected to be able all existing IPv6 applications are expected to be able to use them in
to use them in a manner compatible with current IPv6 addresses. 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 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 index
to the suite of cryptographic algorithms in use. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 7, 2013. This Internet-Draft will expire on June 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 10
Appendix A. Collision Considerations . . . . . . . . . . . . . . 11 Appendix A. Collision Considerations . . . . . . . . . . . . . . 11
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . . 11 Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 11
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 4, line 35 skipping to change at page 4, line 24
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 index
to the suite of cryptographic algorithms in use. 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 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 2001: out of the IANA IPv6 Special Purpose Address Block, namely
0000::/23, as per [RFC4773]. The prefix that was temporarily 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily
allocated for the experimental ORCHID is to be returned to IANA in allocated for the experimental ORCHID is to be returned to IANA in
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; also see Appendix A
o Secure binding to the input parameters used in their generation o Secure binding to the input parameters used in their generation
skipping to change at page 6, line 13 skipping to change at page 6, line 13
the specification for the respective usage context (e.g., HIPv2). the 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-bits 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 | Encode_96( Hash ) ORCHID := Prefix | 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 CGA Type Tags; see RFC
3972 and 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 pre-image resistance and second pre-image
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
skipping to change at page 7, line 48 skipping to change at page 7, line 48
IPv6 addresses. Future non-IPv6 routing systems, such as overlay IPv6 addresses. Future non-IPv6 routing systems, such as overlay
routing systems, may be designed based on ORCHIDs. Any such ORCHID- routing systems, may be designed based on ORCHIDs. Any such ORCHID-
based routing system is out of scope of this document. based routing system is out of scope of this document.
Router software MUST NOT include any special handling code for Router software MUST NOT include any special handling code for
ORCHIDs. In other words, the non-routability property of ORCHIDs, if ORCHIDs. In other words, the non-routability property of ORCHIDs, if
implemented, MUST be implemented via configuration and NOT by implemented, MUST be implemented via configuration and NOT by
hardwired software code. At this time, it is RECOMMENDED that the hardwired software code. At this time, it is RECOMMENDED that the
default router configuration not handle ORCHIDs in any special way. default router configuration not handle ORCHIDs in any special way.
In other words, there is no need to touch existing or new routers due In other words, there is no need to touch existing or new routers due
to this experiment. If such a reason should later appear, for to ORCHIDs. If such a reason should later appear, for example, due
example, due to a faulty implementation leaking ORCHIDs to the IP to a faulty implementation leaking ORCHIDs to the IP layer, the
layer, the prefix can be and should be blocked by a simple prefix can be and should be blocked by a simple configuration rule.
configuration rule.
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.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
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.
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 2001: out of the IANA IPv6 Special Purpose Address Block, namely
0000::/23, as per [RFC4773]. The prefix that was temporarily 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily
allocated for the experimental ORCHID is to be returned to IANA in allocated for the experimental ORCHID is to be returned to IANA in
2014 [RFC4843]. 2014 [RFC4843].
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.
skipping to change at page 10, line 11 skipping to change at page 10, line 17
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
to Indicate Requirement Levels", BCP 14, Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2119, March 1997.
[RFC3972] Aura, T., "Cryptographically Generated [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Addresses (CGA)", RFC 3972, March 2005. RFC 3972, March 2005.
9.2. Informative references 9.2. Informative references
[Hi3] Nikander, P., Arkko, J., and B. Ohlman, [I-D.ietf-hip-rfc5201-bis]
"Host Identity Indirection Infrastructure Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
(Hi3)", November 2004. "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-14 (work in progress), October 2013.
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-11 (work in
progress), February 2013.
[NodeID] Ahlgren, B., Arkko, J., Eggert, L., and
J. Rajahalme, "A Node Identity
Internetworking Architecture (NodeID)",
April 2006.
[PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension [PRIVACYTEXT]
for Mobile IPv6", Work in Progress, Dupont, F., "A Simple Privacy Extension for Mobile IPv6",
July 2006. Work in Progress, July 2006.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
D., Groot, G., and E. Lear, "Address E. Lear, "Address Allocation for Private Internets", BCP
Allocation for Private Internets", BCP 5, 5, RFC 1918, February 1996.
RFC 1918, February 1996.
[RFC3174] Eastlake, D. and P. Jones, "US Secure [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
Hash Algorithm 1 (SHA1)", RFC 3174, (SHA1)", RFC 3174, September 2001.
September 2001.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Cryptographic Hashes in Internet Hashes in Internet Protocols", RFC 4270, November 2005.
Protocols", RFC 4270, November 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Addressing Architecture", RFC 4291, Architecture", RFC 4291, February 2006.
February 2006.
[RFC4773] Huston, G., "Administration of the IANA [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
Special Purpose IPv6 Address Block", for Overlay Routable Cryptographic Hash Identifiers
RFC 4773, December 2006. (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander, P., Laganier, J., and F. [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
Dupont, "An IPv6 Prefix for Overlay "Special-Purpose IP Address Registries", BCP 153, RFC
Routable Cryptographic Hash Identifiers 6890, April 2013.
(ORCHID)", RFC 4843, April 2007.
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.
skipping to change at page 12, line 19 skipping to change at page 12, line 10
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 annex, 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
Juniper Networks Luminate Wireless, Inc.
1094 North Mathilda Avenue Cupertino, CA
Sunnyvale, CA 94089
USA USA
Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
Francis Dupont Francis Dupont
Internet Systems Consortium Internet Systems Consortium
EMail: fdupont@isc.org EMail: fdupont@isc.org
 End of changes. 24 change blocks. 
93 lines changed or deleted 74 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/