draft-ietf-hip-rfc4843-bis-00.txt   draft-ietf-hip-rfc4843-bis-01.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft QUALCOMM Inc. Internet-Draft Juniper Networks
Obsoletes: 4843 (if approved) F. Dupont Obsoletes: 4843 (if approved) F. Dupont
Intended status: Standards Track ISC Intended status: Standards Track ISC
Expires: February 21, 2011 August 20, 2010 Expires: September 15, 2011 March 14, 2011
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID) (ORCHID)
draft-ietf-hip-rfc4843-bis-00 draft-ietf-hip-rfc4843-bis-01
Abstract Abstract
This document introduces Overlay Routable Cryptographic Hash This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID) as a new, experimental class of IPv6-address- Identifiers (ORCHID) as a new, experimental class of IPv6-address-
like identifiers. These identifiers are intended to be used as like identifiers. These identifiers are intended to be used as
endpoint identifiers at applications and Application Programming endpoint identifiers at applications and Application Programming
Interfaces (API) and not as identifiers for network location at the Interfaces (API) and not as identifiers for network location at the
IP layer, i.e., locators. They are designed to appear as application IP layer, i.e., locators. They are designed to appear as application
layer entities and at the existing IPv6 APIs, but they should not layer entities and at the existing IPv6 APIs, but they should not
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 February 21, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 4 skipping to change at page 2, line 40
3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7
4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8 4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8
5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12
10.2. Informative references . . . . . . . . . . . . . . . . . . 12 10.2. Informative references . . . . . . . . . . . . . . . . . . 12
Appendix A. 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 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 Section 4), non-routable at the IP layer, and routable at sense (see Section 4), 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
will include a suitably encoded public cryptographic key. 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 (API) 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 (HIT) in the Host Identity Protocol
(HIP) [HIP-BASE] and Temporary Mobile Identifiers (TMI) for Mobile (HIP) [I-D.ietf-hip-rfc5201-bis] and Temporary Mobile Identifiers
IPv6 Privacy Extension [PRIVACYTEXT]. (TMI) for Mobile IPv6 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, co-ordination is desired to
make sure that an ORCHID is not inappropriately taken for a vanilla make sure that an ORCHID is not inappropriately taken for a vanilla
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 usage at the IP layer.
While being technically possible to use ORCHIDs between consenting While being technically possible to use ORCHIDs between consenting
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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 Section 4 for a differentiate between the different contexts; see Section 4 for a
discussion of the related API and kernel level implementation issues, discussion of the related API and kernel level implementation issues,
and Section 5 for the design choices explaining why the context and Section 5 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 (HIT) in the Host Identity
Protocol [HIP-BASE] and the Temporary Mobile Identifiers (TMI) in the Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile
Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT]. The format Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6
is designed to be extensible to allow other experimental proposals to [PRIVACYTEXT]. The format is designed to be extensible to allow
share the same namespace. other experimental proposals to share the same namespace.
1.4. Action Plan 1.4. Action Plan
This document requests IANA to allocate an experimental prefix out of This document requests IANA to allocate an experimental prefix out of
the IPv6 addressing space for Overlay Routable Cryptographic Hash the IPv6 addressing space for Overlay Routable Cryptographic Hash
Identifiers. 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 algorithm below. The algorithm An ORCHID is generated using the algorithm below. The algorithm
takes a bitstring and a context identifier as input and produces an takes a bitstring and a context identifier as input and produces an
ORCHID as output. ORCHID as output.
Input := any bitstring Input := any bitstring
Hash Input := Context ID | Input Hash Input := Context ID | Input
Hash := Hash_function( Hash Input ) Hash := Hash_function( Hash Input )
ORCHID := Prefix | Encode_100( Hash ) ORCHID := Prefix | Encode_100( 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.
Hash_function : The one-way hash function (i.e., hash function with Hash_function : The one-way hash function (i.e., hash function with
pre-image resistance and second pre-image pre-image resistance and second pre-image
resistance) to be used according to the document resistance) to be used according to the document
defining the context usage identified by the defining the context usage identified by the
Context ID. For example, the current version of Context ID. For example, the current version of
the HIP specification defines SHA1 [RFC3174] as the HIP specification defines SHA1 [RFC3174] as
the hash function to be used to generate ORCHIDs the hash function to be used to generate ORCHIDs
used in the HIP protocol [HIP-BASE]. used in the HIP protocol [I-D.ietf-hip-rfc5201-bis].
Encode_100( ) : An extraction function in which output is obtained Encode_100( ) : An extraction function in which output is obtained
by extracting the middle 100-bit-long bitstring by extracting the middle 100-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
(2001:10::/28). (2001:10::/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 7. Each specific experiment (such as HIP HITs specified in Section 7. Each specific experiment (such as HIP HITs
or MIP6 TMIs) is expected to allocate their own, specific context or MIP6 TMIs) is expected to allocate their own, specific context
identifier. identifier.
The input bitstring and context identifier are concatenated to form The input bitstring and context identifier are concatenated to form
skipping to change at page 11, line 20 skipping to change at page 11, line 20
needed, they MUST use a different Context ID. Consequently, the needed, they MUST use a different Context ID. Consequently, the
suggested method to react to the hash result becoming too short, due suggested method to react to the hash result becoming too short, due
to increased computational power, or to the used hash function to increased computational power, or to the used hash function
becoming insecure due to advances in cryptology, is to allocate a new becoming insecure due to advances in cryptology, is to allocate a new
Context ID and cease to use the present one. Context ID and cease to use the present one.
As of today, SHA1 [RFC3174] is considered as satisfying the second- As of today, SHA1 [RFC3174] is considered as satisfying the second-
preimage resistance requirement. The current version of the HIP preimage resistance requirement. The current version of the HIP
specification defines SHA1 [RFC3174] as the hash function to be used specification defines SHA1 [RFC3174] as the hash function to be used
to generate ORCHIDs for the Context ID used by the HIP protocol to generate ORCHIDs for the Context ID used by the HIP protocol
[HIP-BASE]. [I-D.ietf-hip-rfc5201-bis].
In order to preserve a low enough probability of collisions (see In order to preserve a low enough probability of collisions (see
Section 4), each method MUST utilize a mechanism that makes sure that Section 4), each method MUST utilize a mechanism that makes sure that
the distinct input bitstrings are either unique or statistically 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 100 bits), or a randomly generated public sufficient entropy (minimum 100 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
skipping to change at page 12, line 22 skipping to change at page 12, line 22
earlier, experimental version of this specification [RFC4843]. earlier, experimental version of this specification [RFC4843].
9. Acknowledgments 9. 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.
Julien Laganier is partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed
or implied, of the Ambient Networks project or the European
Commission.
10. References 10. References
10.1. Normative references 10.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs
Requirement Levels", BCP 14, RFC 2119, March 1997. to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC3972] Aura, T., "Cryptographically Generated Addresses [RFC3972] Aura, T., "Cryptographically Generated
(CGA)", RFC 3972, March 2005. Addresses (CGA)", RFC 3972, March 2005.
10.2. Informative references 10.2. Informative references
[HIP-BASE] Moskowitz, R., "Host Identity Protocol", Work [Hi3] Nikander, P., Arkko, J., and B. Ohlman,
in Progress, February 2007. "Host Identity Indirection Infrastructure
(Hi3)", November 2004.
[Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
Indirection Infrastructure (Hi3)", November 2004. T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-05 (work in
progress), March 2011.
[NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and
"A Node Identity Internetworking Architecture J. Rajahalme, "A Node Identity
(NodeID)", April 2006. Internetworking Architecture (NodeID)",
April 2006.
[PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension for Mobile [PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension
IPv6", Work in Progress, July 2006. for Mobile IPv6", Work in Progress,
July 2006.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg,
and E. Lear, "Address Allocation for Private D., Groot, G., and E. Lear, "Address
Internets", BCP 5, RFC 1918, February 1996. Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake, D. and P. Jones, "US Secure
(SHA1)", RFC 3174, September 2001. Hash Algorithm 1 (SHA1)", RFC 3174,
September 2001.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [RFC4270] Hoffman, P. and B. Schneier, "Attacks on
Hashes in Internet Protocols", RFC 4270, Cryptographic Hashes in Internet
November 2005. Protocols", RFC 4270, November 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 4291, February 2006. Addressing Architecture", RFC 4291,
February 2006.
[RFC4773] Huston, G., "Administration of the IANA Special [RFC4773] Huston, G., "Administration of the IANA
Purpose IPv6 Address Block", RFC 4773, December 2006. Special Purpose IPv6 Address Block",
RFC 4773, December 2006.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 [RFC4843] Nikander, P., Laganier, J., and F.
Prefix for Overlay Routable Cryptographic Hash Dupont, "An IPv6 Prefix for Overlay
Identifiers (ORCHID)", RFC 4843, April 2007. Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007.
Appendix A. Changes from RFC 4843
o Updated HIP references to revised HIP specifications.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
QUALCOMM Incorporated Juniper Networks
5775 Morehouse Drive 1094 North Mathilda Avenue
San Diego, CA 92121 Sunnyvale, CA 94089
USA USA
Phone: +1 858 858 3538 Phone: +1 408 936 0385
EMail: julienl@qualcomm.com EMail: julien.ietf@gmail.com
Francis Dupont Francis Dupont
ISC ISC
EMail: Francis.Dupont@fdupont.fr EMail: Francis.Dupont@fdupont.fr
 End of changes. 32 change blocks. 
83 lines changed or deleted 92 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/