draft-ietf-hip-rfc4843-bis-05.txt   draft-ietf-hip-rfc4843-bis-06.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: June 14, 2014 December 11, 2013 Expires: December 25, 2014 June 23, 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-05 draft-ietf-hip-rfc4843-bis-06
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 June 14, 2014. This Internet-Draft will expire on December 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
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.
skipping to change at page 3, line 24 skipping to change at page 3, line 24
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 regular make sure that an ORCHID is not inappropriately taken for a regular
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
hosts without any co-ordination with the IETF and the IANA, the hosts without any co-ordination with the IETF and the IANA, the IETF
authors would consider such practice potentially dangerous. A would consider such practice potentially dangerous. A specific
specific danger would be realised if the IETF community later decided danger would be realised if the IETF community later decided to use
to use the ORCHID prefix for some different purpose. In that case, the ORCHID prefix for some different purpose. In that case, hosts
hosts using the ORCHID prefix would be, for practical purposes, using the ORCHID prefix would be, for practical purposes, unable to
unable to use the prefix for the other new purpose. That would lead use the prefix for the other new purpose. That would lead to partial
to partial balkanisation of the Internet, similar to what has balkanisation of the Internet, similar to what has happened as a
happened as a result of historical hijackings of non-RFC 1918 result of historical hijackings of non-RFC 1918 [RFC1918] IPv4
[RFC1918] IPv4 addresses for private use. addresses for private use.
The whole need for the proposed allocation grows from the desire to The whole need for the proposed allocation grows from the desire to
be able to use ORCHIDs with existing applications and APIs. This be able to use ORCHIDs with existing applications and APIs. This
desire leads to the potential conflict, mentioned above. Resolving desire leads to the potential conflict, mentioned above. Resolving
the conflict requires the proposed allocation. the conflict requires the proposed allocation.
One can argue that the desire to use these kinds of identifiers via One can argue that the desire to use these kinds of identifiers via
existing APIs is architecturally wrong, and there is some truth in existing APIs is architecturally wrong, and there is some truth in
that argument. Indeed, it would be more desirable to introduce a new that argument. Indeed, it would be more desirable to introduce a new
API and update all applications to use identifiers, rather than API and update all applications to use identifiers, rather than
locators, via that new API. That is exactly what we expect to happen locators, via that new API. That is exactly what we expect to happen
in the long run. in the long run.
However, given the current state of the Internet, we do not consider However, given the current state of the Internet, we do not consider
it viable to introduce any changes that, at once, require it viable to introduce any changes that, at once, require
applications to be rewritten and host stacks to be updated. Rather applications to be rewritten and host stacks to be updated. Rather
than that, we believe in piece-wise architectural changes that than that, we believe in piece-wise architectural changes that
require only one of the existing assets to be touched. ORCHIDs are require only one of the existing assets to be touched. ORCHIDs are
designed to address this situation: to allow people to experiment designed to address this situation: to allow people to implement with
with protocol stack extensions, such as secure overlay routing, HIP, protocol stack extensions, such as secure overlay routing, HIP, or
or Mobile IP privacy extensions, without requiring them to update Mobile IP privacy extensions, without requiring them to update their
their applications. The goal is to facilitate large-scale applications. The goal is to facilitate large-scale deployments with
experiments with minimum user effort. minimum user effort.
For example, there already exists, at the time of this writing, HIP For example, there already exists, at the time of this writing, HIP
implementations that run fully in user space, using the operating implementations that run fully in user space, using the operating
system to divert a certain part of the IPv6 address space to a user system to divert a certain part of the IPv6 address space to a user
level daemon for HIP processing. In practical terms, these level daemon for HIP processing. In practical terms, these
implementations are already using a certain IPv6 prefix for implementations are already using a certain IPv6 prefix for
differentiating HIP identifiers from IPv6 addresses, allowing them differentiating HIP identifiers from IPv6 addresses, allowing them
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 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 is to be returned to IANA in allocated for the experimental ORCHID was returned to IANA in March
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
(i.e., the context identifier and a bitstring). (i.e., the context identifier and a bitstring).
skipping to change at page 7, line 44 skipping to change at page 7, line 44
Unreachable, Administratively Prohibited message. Unreachable, Administratively Prohibited message.
ORCHIDs are not designed for use in IPv6 routing protocols, since ORCHIDs are not designed for use in IPv6 routing protocols, since
such routing protocols are based on the architectural definition of such routing protocols are based on the architectural definition of
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, is to be implemented via configuration rather than by
hardwired software code. At this time, it is RECOMMENDED that the hardwired software code, e.g., the ORCHID prefix can be blocked by a
default router configuration not handle ORCHIDs in any special way. simple configuration rule such as an Access Control List entry.
In other words, there is no need to touch existing or new routers due
to ORCHIDs. If such a 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.
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 33 skipping to change at page 9, line 33
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 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 is to be returned to IANA in allocated for the experimental ORCHID was returned to IANA in March
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.
7. Contributors 7. Contributors
 End of changes. 10 change blocks. 
28 lines changed or deleted 24 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/