One document matched: draft-laganier-ipv6-khi-02.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % I-D.ietf-hip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-base.xml" >
<!ENTITY % I-D.dupont-mip6-privacyext SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dupont-mip6-privacyext.xml" >
<!ENTITY % I-D.draft-huston-ipv6-iana-specials SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.huston-ipv6-iana-specials.xml">
<!ENTITY % RFC4270 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4270.xml" >
<!ENTITY % RFC3513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml" >
<!ENTITY % RFC3587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml" >
<!ENTITY % RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml" >
<!ENTITY % RFC3174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml" >
]>
<?rfc symrefs="yes" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="no" ?>
<rfc category="std" ipr="noModification3978" >
<front>
<title abbrev="Cryptographic Hash IDentifiers (ORCHID)">
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
</title>
<author initials="P." surname="Nikander" fullname="Pekka Nikander">
<organization>Ericsson Research Nomadic Lab</organization>
<address>
<postal>
<street />
<city>JORVAS</city>
<code>FI-02420</code>
<country>Finland</country>
</postal>
<phone>+358 9 299 1</phone>
<email>pekka.nikander@nomadiclab.com</email>
</address>
</author>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="DoCoMo Euro-Labs">
DoCoMo Communications Laboratories Europe GmbH
</organization>
<address>
<postal>
<street>
Landsberger Strasse 312
</street>
<city>Munich</city>
<code>80687</code>
<country>Germany</country>
</postal>
<phone>+49 89 56824 231</phone>
<email>julien.ietf@laposte.net</email>
<uri>http://www.docomolab-euro.com/</uri>
</address>
</author>
<author initials="F." surname="Dupont"
fullname="Francis Dupont">
<organization>CELAR</organization>
<address>
<email>Francis.Dupont@point6.net</email>
</address>
</author>
<date year="2006"/>
<area>Internet</area>
<keyword>I-D</keyword>
<keyword>Internet Draft</keyword>
<abstract>
<t> This document introduces Overlay Routable Cryptographic Hash Identifiers
(ORCHID) as a new, experimental class of IPv6-address-like
identifiers. These identifiers are intended to be used as end-point
identifiers at applications and APIs and not as identifiers for
network location at the IP layer, i.e., locators. They are designed to
appear as application layer entities and at the existing IPv6 APIs,
but they should not appear in actual IPv6 headers. To make them more
like vanilla IPv6 addresses, they are expected to be routable at an
overlay level. Consequently, while they are considered as non-routable
addresses from the IPv6 layer point of view, all existing IPv6
applications are expected to be able to use them in a manner
compatible with current IPv6 addresses. </t>
<t>
This document requests IANA to allocate a temporary prefix out of
the IPv6 addressing space for Overlay Routable Cryptographic Hash
Identifiers.
<!-- By default,
the prefix will be returned to IANA in 2009, continued use
requiring IETF consensus.-->
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> This document introduces Overlay Routable Cryptographic Hash Identifiers
(ORCHID), a new class of IP-address-like identifiers. These
identifiers are intended to be globally unique in a statistical
sense (see <xref target="sec-API-issues" />), non-routable at the IP
layer, and routable at some overlay layer. The identifiers are
securely bound, via a secure hash function, to the concatenation of
an input bitstring and a context tag. Typically, but not
necessarily, the input bitstring will include a suitably encoded
public cryptographic key. </t>
<section title="Rationale and intent">
<t> These identifiers are expected to be used at the existing IPv6
APIs and application protocols between consenting hosts. They may be
defined and used in different contexts, suitable for different
overlay protocols. Examples of these include Host Identity Tags
(HIT) in the <xref target="I-D.ietf-hip-base"> Host Identity Protocol
(HIP) </xref> and <xref target="I-D.dupont-mip6-privacyext">
Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension
</xref>. </t>
<t> As these identifiers are expected to be used alongside with IPv6
addresses at both applications and APIs, co-ordination is desired
to make sure that an ORCHID is not inappropriately taken for a
vanilla IPv6 address and vice versa. In practice, allocation of a
separate prefix for ORCHIDs seems to suffice, making them compatible
with IPv6 addresses at the upper layers while simultaneously making
it trivial to prevent their usage at the IP layer. </t>
<t> While being technically possible to use ORCHIDs between
consenting hosts without any co-ordination with the IETF and the
IANA, the authors would consider such practice
potentially dangerous. A specific danger would be realised if the
IETF community later decided to use the ORCHID prefix for some
different purpose. In that case, hosts using the ORCHID prefix would
be, for practical purposes, unable to use the prefix for the other,
new purpose. That would lead to partial balkanisation of the
Internet, similar to what has happened as a result of historical
hijackings of non-RFC1918 IPv4 addresses for private use.</t>
<t> The whole need for the proposed allocation grows from the desire
to be able to use ORCHIDs with existing applications and APIs. This
desire leads to the potential conflict, mentioned above. Resolving
the conflict requires the proposed allocation.</t>
<t> One can argue that the desire to use these kinds of identifiers
via existing APIs is architecturally wrong, and there is some truth
in that argument. Indeed, it would be more desirable to introduce a
new API and update all applications to use identifiers, rather than
locators, via that new API. That is exactly what we expect to happen
in the longer run.</t>
<t> However, given the current state of the Internet, we do not
consider it viable to introduce any changes that, at once, require
applications to be rewritten and host stacks to be updated. Rather
than that, we believe in piece-wise architectural changes that
require only one of the existing assets to be touched. ORCHIDs are
designed to address this situation: to allow people to experiment
with protocol stack extensions, such as secure overlay routing, HIP,
or Mobile IP privacy extensions, without requiring them to update
their applications. The goal is to facilitate large-scale
experiments with minimum user effort.</t>
<t> For example, there already exists, at the time of this writing,
HIP implementations that run fully in user space, using the
operating system to divert a certain part of the IPv6 address space
to a user level daemon for HIP processing. In practical terms, those
implementations are already now using a certain IPv6 prefix for
differentiating HIP identifiers from IPv6 addresses, allowing them
both to be used by the existing applications via the existing
APIs.</t>
<t>This document argues for no more than allocating an experimental
prefix for such purposes, thereby paving the way for large-scale
experiments with cryptographic identifiers without the dangers
caused by address-space hijacking. </t>
</section>
<section title="ORCHID properties">
<t>ORCHIDs are designed to have the following properties:
<list style="symbols">
<t> Statistically uniqueness; see also <xref
target="sec-API-issues" /> </t>
<t> Secure binding to the input parameters used in their
generation (i.e., the context identifier and a bitstring.) </t>
<t> Conformance with the IPv6 global unicast address format as
defined in Section 2.5.4 of <xref target="RFC3513"/>. </t>
<t> Aggregation under a single IPv6 prefix. Note that this is
only needed due to the co-ordination need, as indicated above.
Without such co-ordination need, the ORCHID name space could
potentially be completely flat. </t>
<t> Non-routability at the IP layer, by design. </t>
<t> Routability at some overlay layer, making them, from an
application point of view, semantically similar to IPv6
addresses. </t> </list> </t>
<t> As mentioned above, ORCHIDs are intended to be generated and
used in different contexts, as suitable for different mechanisms and
protocols. The context identifier is meant to be used to
differentiate between the different contexts; see <xref
target="sec-API-issues" /> for a discussion of the related API and
kernel level implementation issues, and <xref target="sec-design" />
for the design choices explaining why the context identifiers are
used. </t>
</section>
<section title="Expected use of ORCHIDs">
<t>
Examples of identifiers and protocols that are expected to adopt
the ORCHID format include Host Identity Tags (HIT) in
the
<xref target="I-D.ietf-hip-base">
Host Identity Protocol
</xref>
and the Temporary Mobile Identifiers (TMI) in the
<xref target="I-D.dupont-mip6-privacyext">
Simple Privacy Extension for Mobile IPv6
</xref>.
The format is designed to be extensible to allow other
experimental proposals to share the same name space.
</t>
</section>
<section title="Action plan">
<t> This document requests IANA to allocate an experimental prefix
out of the IPv6 addressing space for Overlay Routable Cryptographic
Hash Identifiers. </t>
</section>
</section>
<section title="Cryptographic Hash Identifier Construction">
<t>
An ORCHID is generated using the algorithm below. The algorithm takes a bitstring and a context identifier as input and produces an ORCHID as output.
</t>
<figure>
<artwork><![CDATA[
Input := any bitstring
Hash Input := Context ID | Input
Hash := SHA1( Hash Input )
ORCHID := Prefix | Encode_n( Hash )
where:
| : Denotes concatenation of bitstrings
Input : A bitstring unique or statistically unique within a
given context. The bitstring is intended to be
associated with the to-be-created ORCHID, in the
given context.
Context ID : A randomly generated value defining the expected usage
context for the particular ORCHID.
We propose sharing the name space introduced for CGA
Type Tags; see RFC 3972 and
http://www.iana.org/assignments/cga-message-types
Encode_n( ): An extraction function which output is obtained by
extracting the middle 100-bits long bitstring from the
argument bitstring.
Prefix : A constant 28-bits long bitstring value,
TBD, assigned by IANA.
]]></artwork>
</figure>
<t>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
public cryptographic key and some other data. The second piece is a
context identifier, which is an 128-bits-long datum, allocated as
specified in <xref target="sec-IANA" />. Each specific experiment
(such as HIP HITs or MIP6 TMIs) is expected to allocate their own,
specific context identifier.</t>
<t>The input bitstring and context identifier are concatenated to
form an input datum, which is then fed to the cryptographic hash
function SHA1 <xref target="RFC3174"/>.
The result of the hash function is processed by an
encoding function, resulting in an n-bits-long value. This value is
prepended with the ORCHID prefix. The result is the ORCHID, an
128-bits-long bitstring that can be used at the IPv6 APIs in hosts
participating to the particular experiment.</t>
</section>
<section title="Routing Considerations">
<t> ORCHIDs are designed to serve as location independent
end-point-identifiers rather than IP-layer locators. Therefore,
routers MAY be configured not to forward any packets containing an
ORCHID as a source or a destination address. If the destination
address is a ORCHID but the source address is a valid unicast source
address, routers MAY be configured to generate an ICMP Destination
Unreachable, Administratively Prohibited message. </t>
<t> Due to the experimental nature of ORCHIDs, router software MUST
NOT include any special handling code for ORCHIDs. In other words,
the non-routability property of ORCHIDs, if implemented, MUST be
implemented via configuration and NOT by hard-wired software code.
At this time, it is RECOMMENDED that the default router
configuration does not handle ORCHIDs in any special way. In other
words, there is no need to touch existing or new routers due to this
experiment. If such reason should later appear, for example, due to
a faulty implementation leaking ORCHIDs to the IP layer, the prefix
can be and should be blocked by a simple configuration rule. </t>
<section title="Overlay Routing">
<t> As mentioned multiple times, ORCHIDs are designed to be
non-routable at the IP layer. However, there are multiple ongoing
research efforts for creating various overlay routing and
resolution mechanisms for flat identifiers. For example, <xref
target="hi3">the Host Identity Indirection Infrastructure
(Hi3)</xref> proposal outlines a way for using a Distributed Hash
Table to forward HIP packets based on the Host Identity Tag.</t>
<t> What is common to the various research proposals is that they
create a new kind of resolution or routing infrastructure on the
top of the existing Internet routing structure. In practical
terms, they allow delivery of packets based on flat, non-routable
identifiers, utilising information stored in a distributed data
base. Usually the database used is based on Distributed Hash
Tables. This effectively creates a new routing network on the top
of the existing IP-based routing network, capable of routing
packets that are not addressed by IP addresses but some other kind
of identifiers.</t>
<t> Typical benefits from overlay routing include location
independence, more scalable multi-cast, any-cast, and multi-homing
support than in IP, and better DoS resistance than in the vanilla
Internet. The main drawback is typically an order of magnitude
slower performance, caused by an easily largish number of extra
look-up or forwarding steps needed. Consequently, in most
practical cases the overlay routing system is used only during
initial protocol state set-up (cf. TCP handshake), after which the
communicating end-points exchange packets directly with IP,
bypassing the overlay network.</t>
<t> The net result of the typical overlay routing approaches is a
communication service whose basic functionality is comparable to
that of provided by classical IP but that provides considerably
better resilience that vanilla IP in dynamic networking
environments. Some experiments also introduce additional
functionality, such as enhanced security or ability to effectively
route through several IP addressing domains.</t>
<t> The authors expect ORCHIDs to become fully routable, via one
or more overlay systems, before the end of the experiment. </t>
</section>
</section>
<section anchor="sec-API-issues" title="Collision Considerations">
<!--<section anchor="sec-API-issues" title="API, ULP and Related
Considerations">-->
<t> As noted above, the aim is that ORCHIDs are globally unique in a
statistical sense. That is, given the ORCHID referring to a given
entity, the probability of the same ORCHID being used to refer to
another entity elsewhere in the Internet must be sufficiently low so
that it can be ignored for most practical purposes. We believe that
the presented design meets this goal; see <xref target="sec-design"
/>.</t>
<t>Consider next the very rare case that some ORCHID happens to
refer to two different entities at the same time at two different
locations in the Internet. Even in that case the probability of this
fact becoming visible (and therefore a matter of consideration) at
any single location in the Internet is negligible. For the vast
majority of cases the two simultaneous uses of the ORCHID will never
cross each other. However, while rare such collisions are still
possible. This section gives reasonable guidelines on how to
mitigate the consequences in the case such a collision happens. </t>
<t> As mentioned above, ORCHIDs are expected to be used at the
legacy IPv6 APIs between consenting hosts. The context ID is
intended to differentiate between the various experiments, or
contexts, sharing the ORCHID name space. However, the context ID is
not present in the ORCHID itself, but only in front of the input
bitstring as an input to the hash function. While this may lead to
certain implementation-related complications, we believe that the
trade-off of allowing the hash result part of an ORCHID being longer
more than pays off the cost. </t>
<t> Now, 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 additional overlay state within the stack in order to
determine parameters (e.g. what locators) to use in the outgoing
packet. An underlying assumption here, and a matter of fact in the
proposals that the authors are aware of, is that there is an overlay
protocol for setting up and maintaining this additional state. It is
assumed that the state-set-up protocol carries the input bitstring,
and that the resulting ORCHID-related state in the stack can be
associated back with the appropriate context and state-set-up
protocol. </t>
<!--
<t>
In some cases hosts may receive ORCHIDs without having an
appropriate additional state in the stack. In such cases the
API or ULP operations SHOULD fail, with an implementation dependent
error code.
</t>
-->
<t> Even though ORCHID collisions are expected to be extremely rare,
two kinds of collisions may still happen. First, it is possible that
two different input bitstrings within the same context may map to
the same ORCHID. In that case, the state-set-up mechanism is
expected to resolve the conflict, for example, by indicating to the
peer that the ORCHID in question is already in use.</t>
<t> A second type of collision may happen if two input
bitstrings, used in different usage contexts, map to the same
ORCHID. In this case the main confusion is about which context to
use. In order to prevent these types of collisions, it is
RECOMMENDED that implementations that simultaneously support
multiple different contexts maintain a node-wide unified database of
known ORCHIDs, and indicate a conflict if any of the mechanisms
attempt to register a ORCHID that is already in use. For example, if
a given ORCHID is already being used as a HIT in HIP, it cannot
simultaneously be used as a TMI in Mobile IP. Instead, if Mobile IP
attempts to use the ORCHID, it will be notified (by the kernel) that
the ORCHID in question is already in use. </t>
<!--
<t>
According to the current understanding of the authors, it may
not be possible to avoid all collisions. For example, an
application level protocol may transfer a ORCHID to a new host
before the state-set-up protocol has a chance to set up the
needed additional state and detect a possible ORCHID collision.
If there is already state associated
with the given ORCHID, the host may interpret its semantics
wrongly. This is considered acceptable given the expected
rarity of the situation and the experimental nature of the name
space.
</t>
-->
</section>
<section anchor="sec-design" title="Design Choices">
<t>
The design of this name space faces two competing forces:
<list style="symbol">
<t>As many bits as possible should be preserved for the hash
result.</t>
<t>It should be possible to share the name space
between multiple mechanisms.</t>
</list>
</t>
<t>
The desire to have a long hash result requires the prefix to be
as short as possible, and to use few (if any) bits for
additional encoding. The present design takes this desire to
the maxim: all the bits beyond the prefix are used as hash
output. This leaves no bits in the ORCHID itself available for
identifying the context. Additionally, due to security
considerations, the present design REQUIRES that the hash
function used in constructing ORCHIDs be constant; see
<xref target="sec-security" />.
</t>
<t>
The authors explicitly considered including a hash extension
mechanism, similar to the one in CGA <xref target="RFC3972" />,
but decided to leave it out. There were two reasons: desire for
simplicity, and the somewhat unclear IPR situation around the
hash extension mechanism. If there is a future revision of this
document, we strongly advise the future authors to reconsider
the decision.
</t>
<t>
The desire to allow multiple mechanism to share the name space
has been resolved by including the context identifier in the
hash function input. While this does not allow the mechanism to
be directly inferred from a ORCHID, it allows one to verify that a
given input bitstring and ORCHID belong to a given context, with
high probability; but see also <xref target="sec-security" />.
</t>
</section>
<section anchor="sec-security" title="Security Considerations">
<t> ORCHIDs are designed to be securely bound to the context
identifier and the bitstring used as the input parameters during
their generation. To provide this property, the ORCHID generation
algorithm relies on the second-preimage resistance (a.k.a. one-way)
property of the hash function used in the generation <xref
target="RFC4270" />. To have this property, and to avoid collisions,
it is important that the allocated prefix is as short as possible,
leaving as many bits as possible for the hash output. </t>
<t> All mechanism using ORCHIDs MUST use exactly the same mechanism
for generating a ORCHID from the input bitstring. Allowing different
mechanisms, without explicitly encoding the mechanism in the ORCHID
itself, would allow so called bidding down attacks. That is, if
multiple different hash functions were allowed in constructing
ORCHIDs in a given shared name space, and if one of the hash
functions became insecure, that would allow attacks against even
those ORCHIDs that had been constructed using the other, still
secure hash functions. </t>
<t> Due to the desire to keep the hash output value as long as
possible, the present design allows only one method for constructing
ORCHIDs from input bitstrings. If other methods (perhaps using more
secure hash functions) are later needed, they MUST use a different
prefix. Consequently, the suggested method to react to the hash
result becoming too short, due to increased computational power or
to the used hash function becoming insecure due to advances in
cryptology, is to allocate a new prefix and cease to use the present
one. </t>
<t> As of today, SHA1 <xref target="RFC3174"/>
is considered as satisfying the
second-preimage resistance requirement
Hash output of 100
bits is considered to have a low
enough probability of collisions. </t>
<t> In order to preserve a low enough probability of collisions (see
<xref target="sec-API-issues" />), each method MUST utilize a
mechanism that makes sure that the distinct input bitstrings are
either unique or statistically unique, within that context. There are
several possible methods to ensure that; for example, one can include
into the input bitstring a globally maintained counter value, a
pseudo-random number of sufficient entropy (minimum 100 bits), or a
randomly generated <!--or pre-registered-->public cryptographic key.
The Context ID makes sure that input bitstrings from different
contexts never overlap. These together make sure that the probability
of collisions is determined only by the probability of natural
collisions in the hash space and is not increased by a possibility of
colliding input bit strings. </t>
</section>
<section anchor="sec-IANA" title="IANA Considerations">
<t> IANA is requested to allocate a temporary non-routable prefix
from the IPv6 address space. <!--As per Sections 2.5.1 and 2.5.4 of
the prefix must be allocated from the
0000::/3 block, since ORCHIDs do not have a 64-bit interface
identifier part.-->
As per <xref target="I-D.huston-ipv6-iana-specials"/>, the prefix shall be drawn
out of the
2001:0000::/23 block
in support of the experimental usage described in this document.
The allocation will require updating
http://www.iana.org/assignments/ipv6-address-space
During the discussions related
to this draft, it was suggested that other identifier spaces may be
later allocated from this block. However, this document does not
define such a policy or allocations. </t>
<t> The Context Identifier (or Context ID) is a randomly generated
value defining the usage context of a ORCHID. This document defines
no specific value. </t>
<t> We propose sharing the name
space introduced for CGA Type Tags. Hence, defining new values would
follow the rules of Section 8 of <xref target="RFC3972" />, i.e., on
a First Come First Served basis. The policy will require updating
the policy for http://www.iana.org/assignments/cga-message-types
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
<t> Special thanks to Geoff Huston for his sharp but constructive
critic during the development of this memo. Tom Henderson helped to
clarify a number of issues.</t>
</section>
<!--
<section title="Version history">
<section title="-00 to -01">
<t> The name Keyed Hash Identifier (KHI) was replaced with Overlay
Routable Cryptographic Hash Identifier (ORCHID). However, the
draft name was not changed.</t>
<t> More text added to explain the rationale behind the proposed
allocation.</t>
<t> Text changed to emphasise that while ORCHIDs are expected to
be non-routable at the IP-layer, they are expected to become fully
routable and/or resolvable at some upper, overlay layer, thereby
making their basic semantics fully compatible with IPv6 addresses.
</t>
<t> Removed the proposed expiration date. If such an expiration
date is needed, it can be added later during the discussions.</t>
</section>
</section>
-->
</middle>
<back>
<references title="Normative references">
&RFC3174;
&RFC3513;
&RFC3972;
&I-D.draft-huston-ipv6-iana-specials;
<!-- <reference anchor="I-D.irtf-cfrg-sha1-ime">
<front>
<title>SHA1-IME: A SHA-1 Variant with Provably Good Message
Expansion Code</title>
<author initials="U." surname="Blumenthal"
fullname="Uri Blumenthal">
<organization>Intel</organization>
</author>
<author initials="C.S." surname="Jutla">
<organization>IBM</organization>
</author>
<author initials="A.C." surname="Patthak">
<organization>UT Austin</organization>
</author>
<date year="2005" month="November" />
</front>
</reference>-->
</references>
<references title="Informative references">
&RFC3587;
&I-D.ietf-hip-base;
&I-D.dupont-mip6-privacyext;
&RFC4270;
<reference anchor="hi3">
<front>
<title> Host Identity Indirection Infrastructure (Hi3)</title>
<author initials="P." surname="Nikander">
<organization>Ericsson Research</organization>
</author>
<author initials="J." surname="Arkko">
<organization>Ericsson Research</organization>
</author>
<author initials="B." surname="Ohlman">
<organization>Ericsson Research</organization>
</author>
<date year="2004" month="Nov" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:44:32 |