draft-laganier-ipv6-khi-04.txt | draft-laganier-ipv6-khi-05.txt | |||
---|---|---|---|---|
Network Working Group P. Nikander | Network Working Group P. Nikander | |||
Internet-Draft Ericsson Research Nomadic Lab | Internet-Draft Ericsson Research Nomadic Lab | |||
Expires: February 12, 2007 J. Laganier | Expires: March 12, 2007 J. Laganier | |||
DoCoMo Euro-Labs | DoCoMo Euro-Labs | |||
F. Dupont | F. Dupont | |||
CELAR | CELAR | |||
August 11, 2006 | September 8, 2006 | |||
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers | |||
(ORCHID) | (ORCHID) | |||
draft-laganier-ipv6-khi-04 | draft-laganier-ipv6-khi-05 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 38 | skipping to change at page 1, line 38 | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on February 12, 2007. | This Internet-Draft will expire on March 12, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
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 end- | like identifiers. These identifiers are intended to be used as end- | |||
point identifiers at applications and APIs and not as identifiers for | point identifiers at applications and Application Programming | |||
network location at the IP layer, i.e., locators. They are designed | Interfaces (API) and not as identifiers for network location at the | |||
to appear as application layer entities and at the existing IPv6 | IP layer, i.e., locators. They are designed to appear as application | |||
APIs, but they should not appear in actual IPv6 headers. To make | layer entities and at the existing IPv6 APIs, but they should not | |||
them more like vanilla IPv6 addresses, they are expected to be | appear in actual IPv6 headers. To make them more like vanilla IPv6 | |||
routable at an overlay level. Consequently, while they are | addresses, they are expected to be routable at an overlay level. | |||
considered as non-routable addresses from the IPv6 layer point of | Consequently, while they are considered as non-routable addresses | |||
view, all existing IPv6 applications are expected to be able to use | from the IPv6 layer point of view, all existing IPv6 applications are | |||
them in a manner compatible with current IPv6 addresses. | expected to be able to use them in a manner compatible with current | |||
IPv6 addresses. | ||||
This document requests IANA to allocate a temporary prefix out of the | This document requests IANA to allocate a temporary prefix out of the | |||
IPv6 addressing space for Overlay Routable Cryptographic Hash | IPv6 addressing space for Overlay Routable Cryptographic Hash | |||
Identifiers. | Identifiers. | |||
Table of Contents | ||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | ||||
1.1. Rationale and intent . . . . . . . . . . . . . . . . . . . 3 | ||||
1.2. ORCHID properties . . . . . . . . . . . . . . . . . . . . 4 | ||||
1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 | ||||
1.4. Action plan . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 | ||||
3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 6 | ||||
3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7 | ||||
4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8 | ||||
5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | ||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | ||||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
9.1. Normative references . . . . . . . . . . . . . . . . . . . 12 | ||||
9.2. Informative references . . . . . . . . . . . . . . . . . . 12 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 14 | ||||
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 APIs | These identifiers are expected to be used at the existing IPv6 | |||
and application protocols between consenting hosts. They may be | Application Programming Interfaces (API) and application protocols | |||
defined and used in different contexts, suitable for different | between consenting hosts. They may be defined and used in different | |||
overlay protocols. Examples of these include Host Identity Tags | contexts, suitable for different overlay protocols. Examples of | |||
(HIT) in the Host Identity Protocol (HIP) [I-D.ietf-hip-base] and | these include Host Identity Tags (HIT) in the Host Identity Protocol | |||
Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension | (HIP) [I-D.ietf-hip-base] and Temporary Mobile Identifiers (TMI) for | |||
[I-D.dupont-mip6-privacyext]. | Mobile IPv6 Privacy Extension [I-D.dupont-mip6-privacyext]. | |||
As these identifiers are expected to be used alongside with IPv6 | As these identifiers are expected to be used alongside 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 10, line 17 | skipping to change at page 11, line 17 | |||
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 bit strings. | possibility of colliding input bit strings. | |||
7. IANA Considerations | 7. IANA Considerations | |||
IANA is requested to allocate a temporary non-routable prefix from | IANA is requested to allocate a temporary non-routable prefix from | |||
the IPv6 address space. As per [I-D.huston-ipv6-iana-specials], the | the IPv6 address space. As per [I-D.huston-ipv6-iana-specials], the | |||
prefix shall be drawn out of the 2001:0000::/23 block in support of | prefix shall be drawn out of the IANA Special Purpose Address Block, | |||
the experimental usage described in this document. The allocation | namely 2001:0000::/23, in support of the experimental usage described | |||
will require updating | in this document. The allocation will require updating the IANA IPv6 | |||
http://www.iana.org/assignments/ipv6-address-space | Special Purpose Address Registry. | |||
During the discussions related to this draft, it was suggested that | During the discussions related to this draft, it was suggested that | |||
other identifier spaces may be later allocated from this block. | other identifier spaces may be later allocated from this block. | |||
However, this document does not define such a policy or allocations. | However, this document does not define such a policy or allocations. | |||
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 a ORCHID. This document defines no | defining the usage context of a ORCHID. This document defines no | |||
specific value. | specific value. | |||
We propose sharing the name space introduced for CGA Type Tags. | We propose sharing the name space introduced for CGA Type Tags. | |||
Hence, defining new values would follow the rules of Section 8 of | Hence, defining new values would follow the rules of Section 8 of | |||
[RFC3972], i.e., on a First Come First Served basis. The policy will | [RFC3972], i.e., on a First Come First Served basis. The policy will | |||
require updating the policy for | require updating the policy for assignment in the CGA Message Type | |||
http://www.iana.org/assignments/cga-message-types | name space. | |||
8. Acknowledgments | 8. Acknowledgments | |||
Special thanks to Geoff Huston for his sharp but constructive critic | Special thanks to Geoff Huston for his sharp but constructive critic | |||
during the development of this memo. Tom Henderson helped to clarify | during the development of this memo. Tom Henderson helped to clarify | |||
a number of issues. | a number of issues. This document has also been improved by reviews, | |||
comments and discussions originating from the IPv6, Internet Area, | ||||
and IETF communities. | ||||
Julien Laganier is partly funded by Ambient Networks, a research | Julien Laganier is partly funded by Ambient Networks, a research | |||
project supported by the European Commission under its Sixth | project supported by the European Commission under its Sixth | |||
Framework Program. The views and conclusions contained herein are | Framework Program. The views and conclusions contained herein are | |||
those of the authors and should not be interpreted as necessarily | those of the authors and should not be interpreted as necessarily | |||
representing the official policies or endorsements, either expressed | representing the official policies or endorsements, either expressed | |||
or implied, of the Ambient Networks project or the European | or implied, of the Ambient Networks project or the European | |||
Commission. | Commission. | |||
9. References | 9. References | |||
End of changes. 10 change blocks. | ||||
27 lines changed or deleted | 52 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |