One document matched: draft-jiang-hiprg-hhit-arch-02.txt
Differences from draft-jiang-hiprg-hhit-arch-01.txt
Network Working Group Sheng Jiang
Internet Draft Huawei Technologies Co., Ltd
Intended status: Informational May 11, 2009
Expires: November 08, 2009
Hierarchical Host Identity Tag Architecture
draft-jiang-hiprg-hhit-arch-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Jiang Expires November 08, 2009 [Page 1]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
Abstract
This document analyzes the problems and limitation of the current
flat-structured Host Identity Tag architecture. The document
specifies a hierarchical HIT architecture which is compatible with
the flat-structured HIT architecture. This architecture and the
process of HIT generation ensure the global uniqueness of HITs. This
architecture also enables the multiple Host Identity Protocol
management domains, solves the deployment problem of current flat-
structured HIT architecture. It also enhances the scalability and
resolution efficiency of the mapping system from HIT to IP or FQDN.
Table of Contents
1. Introduction................................................3
2. Analysis of the Current Flat-structured HIT Architecture......3
3. Hierarchical HIT Architecture................................5
3.1. Compatible flat-structured HITs.........................6
3.2. HITs on nodes..........................................6
4. Generating a hierarchical HIT................................7
5. Requirements for modification on HIP.........................7
6. Acknowledgements............................................8
7. Security Considerations......................................8
8. IANA Considerations.........................................8
9. References..................................................8
9.1. Normative References....................................8
9.2. Informative References..................................8
Author's Addresses.............................................9
Jiang Expires November 08, 2009 [Page 2]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
1. Introduction
This document analyzes the problems and limitation of the current
flat-structured Host Identity Tag (HIT, [RFC4423]) architecture in
the Host Identity Protocol (HIP, [RFC5201]). The document specifies a
hierarchical HIT architecture, which splits a HIT into two parts: a
HIP management domain tag and a host tag. The proposed hierarchical
HIT architecture is also compatible with the flat-structured HIT
architecture. The format of HIT and the detail process of HIT
generation are defined. This architecture and the process of HIT
generation ensure the global uniqueness of HITs. This architecture
also enables the multiple HIP management domains, solves the
deployment problem of current flat-structured HIT architecture. The
aggregation of HITs in this architecture also enhances the
scalability and resolution efficiency of the mapping system from HIT
to IP or FQDN.
2. Analysis of the Current Flat-structured HIT Architecture
The HIT concept was defined in [RFC5201]: "... the Host Identity Tag
(HIT), becomes the operational representation. It is 128 bits long
and is used in the HIP payloads and to index the corresponding state
in the end hosts."
In order to be able to represent hosts, the uniqueness of HITs is
required in global scope. "In the HIP packets, the HITs identify the
sender and recipient of a packet. Consequently, a HIT should be
unique in the whole IP universe as long as it is being used."
[RFC4423]
Although mathematically "the probability of HIT collision between two
hosts is very low" [RFC5201], there is no mechanism to ensure that a
HIT is global unique.
The current defined HIT is generated according to the ORCHID
generation method described in [RFC4843]: "several possible
methods ... to preserve a low enough probability of collisions".
However, it cannot guarantee the global uniqueness of HITs.
Furthermore, while the number of end devices continuously grows in
the future, the possibility of HIT collision will increase rapidly. A
technical mechanism is needed to ensure the global uniqueness of HITs,
particularly with the consideration that collisions may happen. When
such collision happens, more than one hosts will have the same HIT.
Then, the HIT cannot uniquely identify a certain host.
Jiang Expires November 08, 2009 [Page 3]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
Although there is a rough solution for how to distinguish duplicated
HITs, it is far from a feasible or best solution.
[RFC4423] states "In the extremely rare case of a single HIT mapping
to more than one Host Identity, the Host Identifiers (public keys)
will make the final difference." It means the mapping system between
HIP and IP must store or at least be aware of the Host Identifiers of
all hosts. Given the facts that the Host Identifiers are quite large
and may be in various lengths, the storage and management burden of
the mapping system could be quite high. If there was a mechanism to
ensure the global uniqueness of HITs, then, the mapping system would
not have to be aware the Host Identifiers.
Furthermore, within the flat-structured HIT architecture, the
robustness of resolution efficiency in the supporting mapping system
is in a big question mark: a mapping server has to hold or at least
to be able to access a large database that contains information on
all HITs in the global scope. There more than a billion hosts now on
the Internet and a global deployment of HIP would require an equal
amount of HITs. In the future, there could be even billions of
machines or even higher. The storage burden, maintenance consumption
and synchronization updating are problems that are very difficult to
solve. For each single lookup operation, one may search through most
of the database. It is unfeasible for both computing power and time
reasons.
One more disadvantage that the flat-structured HIT architecture is
the difficulties for management. There is nothing common between HITs
that were assigned by the same authority or that their represented
hosts have the same properties. Hence, it is difficult to categorize
HITs. Although this provides privacy to the end-hosts, the Access
Control Lists (ACLs) would have to have a full list of HITs
accessible to permitted services. Contrarily, the hierarchical HITs
are more aggregatable. It makes HITs manageable. HITs can be grouped
according to its belonging authority or domain. Each network operator
just needs to manage and maintain HITs and their mapping information
in a relatively small range.
According to the above analysis, it is natural to turn the flat HIT
architecture into hierarchy. It can effectively reduce the global
uniqueness requirement into much smaller scope uniqueness requirement.
In another word, if a hierarchical HIT with a global unique
management domain tag is locally unique, it is guaranteed to be
global unique. It can improve the resolution processing and enhance
the scalability and resolution efficiency. Furthermore, it can
optimize the management of both the host identity and the mapping
database. Each management domain is responsible only for a part of
Jiang Expires November 08, 2009 [Page 4]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
the global HIT architecture. However, it is useful that the new
hierarchical HIT architecture is compatible with the flat HIT
architecture for privacy purposes and other usage scenarios.
3. Hierarchical HIT Architecture
In this document, we introduce a two-level hierarchically structured
HIT architecture. HIT is "128 bits long value and is used in the HIP
payloads and to index the corresponding state in the end hosts."
[RFC5201] "In the HIP packets, the HITs identify the sender and
recipient of a packet." [RFC4423] HITs refer to nodes or virtual
nodes. All nodes are required to have at least one HIT. A single node
may also have multiple HITs. Applications on a same node may bind to
different HITs.
In the hierarchical HIT namespace, a 128-bit HIT consists of two
parts: 32-bit HIP management domain tag and 96-bit host tag. It can
represent maximum 2^32 management domains and 2^96 hosts within each
management domain.
| 32 bits | 96 bits |
+-------------------------------+---------------------------------+
| HIP management domain tag | host tag |
+-------------------------------+---------------------------------+
For the secure consideration, we assign more bits to the host tag,
which is a hash result, leaving less but enough bits for HIP
management domain tag. The more the number of bits the host tag is,
the more secure it is against brute-force attacks. In the worst case,
if the hash algorithm cannot be inverted, the expected number of
iterations required for a brute force attack is O(2^96) in order to
find a host identity that matches with a given host tag. It should be
noted that this draft does not take into account the ORCHID prefix
defined in [RFC4843]. It is because the /28 bit orchid prefix with
32-bit hierarchical HIP management domain tag would leave only 68
bits or even less for host tag part, which reduce the security
properties too low and increase collusion possibility too high.
The HIP management domain, as its literal, is a logic region in which
the HIs of all nodes are assigned by the same authority. Within a
same HIP management domain, all the nodes should have the same HIP
management domain tag or the same leftmost certain bits. Furthermore,
the authority may be organized internally hierarchically.
The HIP management domain tag should be assigned by a global
management organization with the principle that every HIP management
domain tag must be globally unique.
Jiang Expires November 08, 2009 [Page 5]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
Consequentially, the HIP management domain tags may be organized
hierarchically. For example, a big organization may obtain a block of
HIP management tags with an assigned 24-bit prefix. It then can
assign 32-bit HIP management domain tags to its sub-organizations.
All these sub-organizations have the same leftmost 24-bit.
The host tags remain the original meaning of HIT -"a hashed encoding
of the Host Identity". For each HIP management domain, it is
mandatory to maintain the uniqueness of all host tags. It is
guaranteed by the process of generating a HIT, see Section 5.
For resolution purposes, HITs are aggregatable with management domain
tags of arbitrary bit-length, similar to IPv4 addresses under
Classless Inter-Domain Routing [RFC4632].
3.1. Compatible flat-structured HITs
Obviously, not all hosts are willing to use hierarchical HITs in all
scenarios for various reasons, such as privacy. Therefore, it is
useful that the hierarchical HIT architecture keep compatible with
the flat HIT architecture.
The flat HITs can be defined as a specific sub-set of the
hierarchical HITs architecture. With the same reserved Flat HIT Tag
(2 or 3 bits) at the beginning and the number of bits that can be
chosen arbitrarily reduce 2 or 3 bits out of 128, flat HITs can be
used as defined in [RFC4423].
| 128 bits |
+-----------------------------------------------------------------+
|FHIT Tag| Flat host identity tag |
+-----------------------------------------------------------------+
3.2. HITs on nodes
HIP-enabled nodes may have considerable or little knowledge of the
internal structure of hierarchical HITs, depending on the role the
node plays (for instance, host versus mapping server). At a minimum,
a node may consider pre-generated HITs have no internal structure:
| 128 bits |
+-----------------------------------------------------------------+
| host identity tag |
+-----------------------------------------------------------------+
Jiang Expires November 08, 2009 [Page 6]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
Only sophisticated hosts may additionally be aware of the type of
their HITS and use the hierarchical structure of HITs to simplify the
resolution procedure.
4. Generating a hierarchical HIT
The process of generating a new hierarchical HIT takes three input
values: a 32-bit HIP management domain tag, a 2-bit collusion count,
the host identity (the public key of an asymmetric key pair). A
hierarchical HIT should be generated as follows:
1. Set the 2-bit collision count to zero.
2. Concatenate from left to right the HIP management domain tag,
the collusion count, and the host identity. Execute the SHA-1
algorithm on the concatenation. Take the 94 leftmost bits of
the SHA-1 hash value.
3. Concatenate from left to right the 32-bit HIP management
domain tag, the 2-bit collusion count and 94-bit hash output
to form a 128-bit HIT.
4. Perform duplicate detection within the HIP management domain
scope. If a HIT collision is detected, increment the collision
count by one and go back to step 2. However, after four
collisions, stop and report the error. (Note: the duplicate
detection mechanism is not discussed in this document. It may
be broadcast or central registration.)
The design that includes the HIP management domain tag in the hash
input is mainly against the re-computation attack: create a database
of HITs and matching public keys. With the design, an attacker must
create a separate database for each HIP management domain.
The design reduces the number of bit of hash output from 96 to 94. It
does reduce the safety. However, O(2^94) iterations is large enough
to prevent brute-force attacks.
For security reason, the abovementioned SHA-1 hash algorithm may be
replaced by any safer algorithm.
5. Requirements for modification on HIP
The usage of hierarchical HITs requires either a new version of HIP
protocol or a new critical flag in the header of HIP control packets.
The latter is considered easier and more fulfill.
Jiang Expires November 08, 2009 [Page 7]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
6. Acknowledgements
Useful comments were made by Miika Komu from HIIT, and other members
of the IRTF HIPRG research group.
7. Security Considerations
The most important security property of HIT is that it is self-
certifying (i.e., given a HIT, it is computationally hard to find a
Host Identity key that matches the HIT). Although this document
limits the hash output to be 94-bit long, it does not affect the self
certifying security property.
8. IANA Considerations
This document defines a new namespace: HIP management domain tag. It
is a 32-bit long value, which represents a globally unique HIP
management domain. IANA may found an authority institute to manage
the global assignment of HIP management domain tag.
9. References
9.1. Normative References
[RFC4423] R. Moskowitz, P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC4423, May 2006.
[RFC5201] R. Moskowitz, et al., "Host Identity Protocol", RFC 5201,
Oct 2007.
9.2. Informative References
[RFC4632] V. Fuller, T. Li, "Classless Inter-Domain Routing (CIDR):
The Internet Address Assignment and Aggregation Plan",
RFC4632, August 2006.
[RFC4843] P. Nikander, et al., "An IPv6 Prefix for Overlay Routable
Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April
2007.
Jiang Expires November 08, 2009 [Page 8]
Internet-Draft draft-jiang-hiprg-hhit-arch-02.txt May 2009
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836774
Email: shengjiang@huawei.com
Jiang Expires November 08, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 23:31:12 |