Network working group Dacheng Zhang
Internet Draft Xiaohu Xu
Category: Standards Track
Created: May 27, 2009 Huawei Technologies Co.,Ltd
Expires: November 2009
Extensions of Host Identity Protocol (HIP) with Hierarchical
Information
draft-zhang-hip-hierarchical-parameter-00.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 November 27, 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.
Zhang and Xu. Expires November 27, 2009 [Page 1]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
Abstract
This document briefly introduces the benefits brought by extending the
Host Identity Protocol (HIP) with hierarchical information. In
addition, two hierarchical extensions of HIP are introduced. The
first one aims to transport hierarchical information in a parameter
of the HIP header, while the second one extends DNS resource records
in order to contain hierarchical information.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction.................................................2
2. Benefits introduced by Hierarchical Information..............3
3. Candidate Solutions..........................................4
4. Hierarchical_HIT Parameter...................................5
5. HHIT Registration............................................7
6. Domain Name System (DNS) Extension...........................8
7. IANA Considerations..........................................9
8. Acknowledgments..............................................9
9. References...................................................9
Authors' Addresses.............................................10
1. Introduction
While having obtained a tremendous success, the current Internet
architecture shows its limits in many aspects. For example, the
current Internet cannot well support the incorporation of mobile and
multi-homed terminals, lacks essential security mechanisms, and
suffers from the issues caused by the explosively increased lengths
of routing tables. In order to address these challenges, a
comprehensive solution, the Host Identity Protocol (HIP), was
proposed. A simple principle behind HIP is to separate hosts'
identities from their topological locations in the Internet.
Currently, the basic architectures and protocols of HIP have been
developed, which are security-inherited and provides essential
supports for mobility and multi-homing features.
There is no hierarchy in existing HIP names, which is largely
because a flat HIP namespace is simple and easy for implementation.
Zhang and Xu. Expires November 27, 2009 [Page 2]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
In addition, hosts in the current HIP architecture are organized in
a "flat" way. This document first analyzes the benefits introduced
by integrating hierarchical information with HIP in terms of
security, management, integration with hierarchical overlays and etc.
Then, this document discusses the issues with the transport of
hierarchical information in HIP headers and the maintenance of
hierarchical information in DNS resource records.
2. Benefits introduced by Hierarchical Information
Hierarchy is a practical methodology in the design and organization
of non-trivial distributed systems, and has been adopted in many
large-scale networks and distributed systems (e.g., Internet). It
shows many advantages in terms of simplifying system architectures,
improving the capability of system management, facilitating audit
and security, and etc. To be consistent with the hierarchical
features of the Internet, two critical namespaces of the Internet,
IP and FQDN, are designed in hierarchical ways. However, based on
certain concerns (e.g., easy implementation), the HIT namespace is
flat; HIP itself does not provide any support for hierarchy either.
This section attempts to demonstrate that current HIP, by using
hierarchical information, can be more efficient and flexible in many
typical scenarios.
Firstly, hierarchical information is essential for the combination
of HIP with hierarchical overlays (e.g., hierarchical resolution
mechanisms). Compared with flat overlays where resources are
maintained at essentially random nodes, hierarchical overlays are
able to support reasonable business and trust models where resources
are managed by Administrative Domains (ADs) with distinct boundaries.
For example, it is normally not desired for a country to have its
resolution infrastructure and the related data resources managed by
other countries. In order to correctly route across hierarchical
overlays, hierarchical information (e.g., AD identifiers) is
required to identify the destination AD where the desired resources
are maintained, while the resource identifiers are used to locate
the resources.
Secondly, the hierarchical information can be used to address the
uniqueness verification issues with HITs in current HIP solutions.
In current HIP solutions, the HIT of each host is required to be
unique all over the world, which is very difficult to guarantee.
However, if the Internet is divided into multiple administration
domains, this problem is relatively easier to address. As
hierarchical information (i.e., AD identifier) can be used to
Zhang and Xu. Expires November 27, 2009 [Page 3]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
identify the AD of a HIT, it only needs to be guaranteed that the
HIT is unique within the AD. The process of verifying the uniqueness
of HITs can be performed when the host registers its HIT with the AD.
Moreover, hierarchical information has been widely employed in
advanced authorization systems (e.g., attributes based or role-based
authorization systems) to make the access control aggregates. By
using AD identifiers, it is possible for security managers to design
the access control policies based on the AD of hosts so as to reduce
the length of access control lists.
Apart from the advantages mentioned above, hierarchical information
may associate HIP with better HIT administrating and auditing
capabilities, which makes HIP easier to be accepted by the countries
which have relatively strict management policies on their networks.
3. Candidate Solutions
Basically, there are three types of solutions of embedding
hierarchical information in HIT Headers. The first type of solution
is to embed hierarchical information into HITs directly. For
instance, divide a HIT into two parts; the first indicates the
hierarchical information of the host, and the second is the
identifier of the host. The principle behind this type of solution
is similar with IP addresses. A criticism on this type of solution
is that the capability of an identifier in tolerating attacks is
affected as a part of the space of the identifier that is occupied
by the topological information. This issue can be largely addressed
by puzzles which have been employed in Cryptographically Generated
Addresses (CGA) [RFC3972]. However, this type of solution still has
an inherent disadvantage in protecting privacy. As hierarchical
information is integrated with HITs, this solution is not suitable
for the scenario where hosts do not intend to disclose their
hierarchical information.
The second type of solution is to encapsulate the hierarchical
information in a certificate and transport the certificate within
the CERT parameter of the HIT header. This type of solution is more
flexible than the first type of solution. One can attaches the
certificates to HIT headers only when hierarchical information is
needed. One concern of this type of solution is its efficiency. Some
parameters of a certificate (e.g., the name and the public key of
the subject) are already contained in HIT headers. When using a
certificate to transport hierarchical information, these parameters
may have to be transported again, causing redundancy. In addition,
certificates have to be signed by issuers. The signature of a
Zhang and Xu. Expires November 27, 2009 [Page 4]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
certificate can be used to verify the authenticity of the
transported hierarchical information, which is very useful when the
certificate is used to transport hierarchical information for the
source HIT of a HIP packet. However, when the certificate is used to
transport hierarchical information for the destination HIT of a HIP
packet, the signature is redundant because the receiver of the
packet needs not to verify the authenticity of its hierarchical
information. Another concern is performance. A HIT can be attached
with multiple certificates which are issued by diverse third parties
for the various purposes. The system thus may have to go through all
the certificates in order to find the proper certificate issued by
the AD and use it to assess the validity of the HIT.
The third type of solution is to transport hierarchical information
in a parameter. Compared with the first type of solution, this
solution shows its advantages in the privacy protection. The third
type of solution is as flexible as the second type of solution, but
more efficient. The solution proposed in this document is a third
type solution, which specifies a new parameter to transport
hierarchical information.
4. Hierarchical_HIT Parameter
This parameter contains the information about the AD and should be
transported in R1 and I2 packets of basic.
Type 61698
Length length in octets, excluding Type, Length, and
Padding
ADI Type type of the Administration Domain Identifier field
ADI Length length of the FQDN or NAI in octets
NB Length length of the Not Before Time field in octets
NA Length length of the Not After Time field in octets
AD Identifier the identifier of the AD of the sender
Not Before Time the beginning of the valid period of the HIT of the
sender
Not After Time the end of the valid period of the HIT of the sender
Zhang and Xu. Expires November 27, 2009 [Page 5]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
SIG alg signature algorithm
Signature the signature is generated by the AD previously,
calculated over the concatenation of Host Identity
field of HOST_ID, and AD Identifier, Not Before
Time, Not After Time fields of the Hierarchical_HIT
parameter.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ADIType| ADI Length | NB Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA Length | Sig Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIG alg | AD Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Not Before Time /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Not After Time /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following AID Types have been defined:
Type Value
none included 0
Zhang and Xu. Expires November 27, 2009 [Page 6]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
FQDN 1
NAI 2
FQDN Fully Qualified Domain Name, in binary format.
NAI Network Access Identifier
The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1.
The format for NAI is defined in [RFC4282]. Not Before Time and Not
After Time fields must either UTCTime or GeneralizedTime defined in
[RFC2459]. SIG alg is set to 0 when there is no signature included.
In this case, Sig Length is set 0 as well.
5. HHIT Registration
If the authenticity of the hierarchical information of a HIT needs
to be proved in practice, the HIT need to register with an AD and
obtain the signature. The registration process can be whether in-
band or out-of-band. In the following diagram, a protocol for HHIT
registration is illustrated.
+-----+ +------+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | AD |
| | I2(REG_REQ) |Server|
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +------+
This protocol is an extension of basic by using the HIP Registration
Extension [RFC5203]. In R1, AD Server sends the service it provides
to Initiator in the REG_INFO element. Initiator then attaches the
REG-REQ element and the HHIT parameter with the I2 message. The
Signature field in the parameter is left unfilled. The AD server
signs the HHIT and its parameters, and sends the signature back in
R2.
Zhang and Xu. Expires November 27, 2009 [Page 7]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
6. Domain Name System (DNS) Extension
This section introduces a DNS extension which further extends the
HIP RR Storage Format proposed in [RFC5205].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT Length | PK algorithm | PK Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ADIType| ADI Length | NB Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA Length | HIT /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Public Key /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Rendezvous Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | AD Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Not Before Time /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Not After Time /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |
+-+-+-+-+
Apart from the fields illustrated in [RFC5205], the extension
includes following fields: ADI type, ADI Length, NB Length, NA
Length, AD Identifier, Not Before Time, Not After Time. Because the
means of these fields is identical to their counterparts in the
Hierarchical_HIT Parameter, they are not introduced here in detail.
Zhang and Xu. Expires November 27, 2009 [Page 8]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
7. IANA Considerations
IANA is expected to allocate a type code for the Hierarchical_HIT
Parameter
8. Acknowledgments
Thanks Thomas.R.Henderson for his kindly prove-reading and precious
comments.
9. References
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, November 2005.
[RFC2459] Internet X.509 Public Key Infrastructure: Certificate and
CRL Profile January 1999.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203, April 2008.
Zhang and Xu. Expires November 27, 2009 [Page 9]
Internet-Draft Extensions of HIP with Hierarchical Information May 2009
Authors' Addresses
Dacheng Zhang
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Email: zhangdacheng@huawei.com
Xiaohu Xu
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Email: xuxh@huawei.com
Zhang and Xu. Expires November 27, 2009 [Page 10]