< draft-ietf-hip-arch-02.txt   draft-ietf-hip-arch-03.txt >
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft ICSAlabs, a Division of TruSecure Internet-Draft ICSAlabs, a Division of TruSecure
Expires: July 11, 2004 Corporation Expires: February 2, 2006 Corporation
P. Nikander P. Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
January 11, 2004 August 1, 2005
Host Identity Protocol Architecture Host Identity Protocol Architecture
draft-ietf-hip-arch-02 draft-ietf-hip-arch-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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."
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 July 11, 2004. This Internet-Draft will expire on February 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo describes a snapshot of the reasoning behind a proposed new This memo describes a snapshot of the reasoning behind a proposed new
namespace, the Host Identity namespace, and a new protocol layer, the namespace, the Host Identity namespace, and a new protocol layer, the
Host Identity Protocol, between the internetworking and transport Host Identity Protocol, between the internetworking and transport
layers. Herein are presented the basics of the current namespaces, layers. Herein are presented the basics of the current namespaces,
their strengths and weaknesses, and how a new namespace will add their strengths and weaknesses, and how a new namespace will add
completeness to them. The roles of this new namespace in the completeness to them. The roles of this new namespace in the
protocols are defined. The memo describes the thinking of the protocols are defined. The memo describes the thinking of the
skipping to change at page 2, line 18 skipping to change at page 2, line 17
understanding. understanding.
Table of Contents Table of Contents
1. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Terms common to other documents . . . . . . . . . . . . . . 4 3.1 Terms common to other documents . . . . . . . . . . . . . . 4
3.2 Terms specific to this and other HIP documents . . . . . . . 4 3.2 Terms specific to this and other HIP documents . . . . . . . 4
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 A desire for a namespace for computing platforms . . . . . . 7 4.1 A desire for a namespace for computing platforms . . . . . . 6
5. Host Identity namespace . . . . . . . . . . . . . . . . . . 8 5. Host Identity namespace . . . . . . . . . . . . . . . . . . 8
5.1 Host Identifiers . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Host Identifiers . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Storing Host Identifiers in DNS . . . . . . . . . . . . . . 9 5.2 Storing Host Identifiers in DNS . . . . . . . . . . . . . . 9
5.3 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 10 5.3 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 10
5.4 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . . 10 5.4 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . . 10
6. New stack architecture . . . . . . . . . . . . . . . . . . . 10 6. New stack architecture . . . . . . . . . . . . . . . . . . . 10
6.1 Transport associations and end-points . . . . . . . . . . . 11 6.1 Transport associations and end-points . . . . . . . . . . . 11
7. End-host mobility and multi-homing . . . . . . . . . . . . . 12 7. End-host mobility and multi-homing . . . . . . . . . . . . . 12
7.1 Rendezvous mechanism . . . . . . . . . . . . . . . . . . . . 12 7.1 Rendezvous mechanism . . . . . . . . . . . . . . . . . . . . 12
7.2 Protection against flooding attacks . . . . . . . . . . . . 13 7.2 Protection against flooding attacks . . . . . . . . . . . . 13
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Disclaimer 1. Disclaimer
The purpose of this memo is to provide a stable reference point in The purpose of this memo is to provide a stable reference point in
the development of the Host Identity Protocol architecture. This the development of the Host Identity Protocol architecture. This
memo describes the thinking of the authors as of Fall 2003; their memo describes the thinking of the authors as of Fall 2003; their
thinking may have evolved since then. Occasionally, this memo may be thinking may have evolved since then. Occasionally, this memo may be
confusing or self-contradicting. That is (partially) intentional, confusing or self-contradicting. That is (partially) intentional,
and reflects the snapshot nature of this memo. and reflects the snapshot nature of this memo.
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and notes that the decision to publish is not based on IETF
review. However, the ideas put forth in this RFC have generated
significant interest, including the formation of the IETF HIP Working
Group and the IRTF HIP Research Group. There groups are expected to
generate further documents, sharing their findings with the whole
Internet Community.
2. Introduction 2. Introduction
The Internet has two important global namespaces: Internet Protocol The Internet has two important global namespaces: Internet Protocol
(IP) addresses and Domain Name Service (DNS) names. These two (IP) addresses and Domain Name Service (DNS) names. These two
namespaces have a set of features and abstractions that have powered namespaces have a set of features and abstractions that have powered
the Internet to what it is today. They also have a number of the Internet to what it is today. They also have a number of
weaknesses. Basically, since they are all we have, we try and do too weaknesses. Basically, since they are all we have, we try and do too
much with them. Semantic overloading and functionality extensions much with them. Semantic overloading and functionality extensions
have greatly complicated these namespaces. have greatly complicated these namespaces.
skipping to change at page 3, line 41 skipping to change at page 3, line 50
and the corresponding Host Identifier, can either be public (e.g. and the corresponding Host Identifier, can either be public (e.g.
published in the DNS), or unpublished. Client systems will tend to published in the DNS), or unpublished. Client systems will tend to
have both public and unpublished Identities. have both public and unpublished Identities.
There is a subtle but important difference between Host Identities There is a subtle but important difference between Host Identities
and Host Identifiers. An Identity refers to the abstract entity that and Host Identifiers. An Identity refers to the abstract entity that
is identified. An Identifier, on the other hand, refers to the is identified. An Identifier, on the other hand, refers to the
concrete bit pattern that is used in the identification process. concrete bit pattern that is used in the identification process.
Although the Host Identifiers could be used in many authentication Although the Host Identifiers could be used in many authentication
systems, such as IKEv2 [11], the presented architecture introduces a systems, such as IKEv2 [9], the presented architecture introduces a
new protocol, called the Host Identity Protocol (HIP), and a new protocol, called the Host Identity Protocol (HIP), and a
cryptographic exchange, called the HIP base exchange [6]; see also cryptographic exchange, called the HIP base exchange; see also
Section 8. The new protocol provides for limited forms of trust Section 8. The IETF HIP Working Group is chartered to develop
between systems. It enhances mobility, multi-homing and dynamic IP specifications on these protocol exchanges. The HIP protocols under
renumbering [9], aids in protocol translation / transition [6], and development provide for limited forms of trust between systems,
reduces certain types of denial-of-service (DoS) attacks [6]. enhance mobility, multi-homing and dynamic IP renumbering, aid in
protocol translation / transition, and reduce certain types of
denial-of-service (DoS) attacks.
When HIP is used, the actual payload traffic between two HIP hosts is When HIP is used, the actual payload traffic between two HIP hosts is
typically, but not necessarily, protected with IPsec. The Host typically, but not necessarily, protected with IPsec. The Host
Identities are used to create the needed IPsec Security Associations Identities are used to create the needed IPsec Security Associations
(SAs) and to authenticate the hosts. When IPsec is used, the actual (SAs) and to authenticate the hosts. When IPsec is used, the actual
payload IP packets do not differ in any way from standard IPsec payload IP packets do not differ in any way from standard IPsec
protected IP packets. protected IP packets.
3. Terminology 3. Terminology
3.1 Terms common to other documents 3.1 Terms common to other documents
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Public key | The public key of an asymmetric cryptographic key | | Public key | The public key of an asymmetric cryptographic key |
| | pair. Used as a publicly known identifier for | | | pair. Used as a publicly known identifier for |
| | cryptographic identity authentication. | | | cryptographic identity authentication. |
| | | | | |
| Private key | The private or secret key of an asymmetric | | Private key | The private or secret key of an asymmetric |
| | cryptographic key pair. Assumed to be known only | | | cryptographic key pair. Assumed to be known only |
| | to the party identified by the corresponding | | | to the party identified by the corresponding |
| | public key. Used by the identified party to | | | public key. Used by the identified party to |
| | authenticate its identity to other parties. | | | authenticate its identity to other parties. |
| | | | | |
| Public key | An asymmetric cryptographic key pair consisting of | | Public key | An asymmetric cryptographic key pair consisting of |
| pair | public and private keys. For example, | | pair | public and private keys. For example, |
| | Rivest-Shamir-Adelman (RSA) and Digital Signature | | | Rivest-Shamir-Adelman (RSA) and Digital Signature |
| | Algorithm (DSA) key pairs are such key pairs. | | | Algorithm (DSA) key pairs are such key pairs. |
| | | | | |
| End-point | A communicating entity. For historical reasons, | | End-point | A communicating entity. For historical reasons, |
| | the term 'computing platform' is used in this | | | the term 'computing platform' is used in this |
| | document as a (rough) synonym for end-point. | | | document as a (rough) synonym for end-point. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
3.2 Terms specific to this and other HIP documents 3.2 Terms specific to this and other HIP documents
It should be noted that many of the terms defined herein are It should be noted that many of the terms defined herein are
tautologous, self-referential or defined through circular reference tautologous, self-referential or defined through circular reference
to other terms. This is due to the succinct nature of the to other terms. This is due to the succinct nature of the
definitions. See the text elsewhere in this document for more definitions. See the text elsewhere in this document for more
elaborate explanations. elaborate explanations.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Term | Explanation | | Term | Explanation |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Computing | An entity capable of communicating and computing, | | Computing | An entity capable of communicating and computing, |
| platform | for example, a computer. See the definition of | | platform | for example, a computer. See the definition of |
| | 'End-point', above. | | | 'End-point', above. |
| | | | | |
| HIP base | A cryptographic protocol defined in [6]. See also | | HIP base | A cryptographic protocol; see also Section 8. |
| exchange | Section 8. | | exchange | |
| | | | | |
| HIP packet | An IP packet that carries a 'Host Identity | | HIP packet | An IP packet that carries a 'Host Identity |
| | Protocol' message. | | | Protocol' message. |
| | | | | |
| Host | An abstract concept assigned to a 'computing | | Host | An abstract concept assigned to a 'computing |
| Identity | platform'. See 'Host Identifier', below. | | Identity | platform'. See 'Host Identifier', below. |
| | | | | |
| Host | A name space formed by all possible Host | | Host | A name space formed by all possible Host |
| Identity | Identifiers. | | Identity | Identifiers. |
| namespace | | | namespace | |
| | | | | |
| Host | A protocol used to carry and authenticate Host | | Host | A protocol used to carry and authenticate Host |
| Identity | Identifiers and other information. | | Identity | Identifiers and other information. |
| Protocol | | | Protocol | |
| | | | | |
| Host | A 128-bit datum created by taking a cryptographic | | Host | A 128-bit datum created by taking a cryptographic |
skipping to change at page 6, line 16 skipping to change at page 6, line 16
The Internet is built from three principal components: computing The Internet is built from three principal components: computing
platforms (end-points), packet transport (i.e., internetworking) platforms (end-points), packet transport (i.e., internetworking)
infrastructure, and services (applications). The Internet exists to infrastructure, and services (applications). The Internet exists to
service two principal components: people and robotic services service two principal components: people and robotic services
(silicon based people, if you will). All these components need to be (silicon based people, if you will). All these components need to be
named in order to interact in a scalable manner. Here we concentrate named in order to interact in a scalable manner. Here we concentrate
on naming computing platforms and packet transport elements. on naming computing platforms and packet transport elements.
There are two principal namespaces in use in the Internet for these There are two principal namespaces in use in the Internet for these
components: IP numbers, and Domain Names. Email, HTTP, and SIP components: IP numbers, and Domain Names. Domain Names provide
addresses are really only extensions of Domain Names. hierarchically assigned names for some computing platforms and some
services. Each hierarchy is delegated from the level above; there is
no anonymity in Domain Names. Email, HTTP, and SIP addresses all
reference Domain Names.
IP numbers are a confounding of two namespaces, the names of a host's IP numbers are a confounding of two namespaces, the names of a host's
networking interfaces and the names of the locations ('confounding' networking interfaces and the names of the locations ('confounding'
is a term used in statistics to discuss metrics that are merged into is a term used in statistics to discuss metrics that are merged into
one with a gain in indexing, but a loss in informational value). The one with a gain in indexing, but a loss in informational value). The
names of locations should be understood as denoting routing direction names of locations should be understood as denoting routing direction
vectors, i.e., information that is used to deliver packets to their vectors, i.e., information that is used to deliver packets to their
destinations. destinations.
IP numbers name networking interfaces, and typically only when the IP numbers name networking interfaces, and typically only when the
interface is connected to the network. Originally, IP numbers had interface is connected to the network. Originally, IP numbers had
long-term significance. Today, the vast number of interfaces use long-term significance. Today, the vast number of interfaces use
ephemeral and/or non-unique IP numbers. That is, every time an ephemeral and/or non-unique IP numbers. That is, every time an
interface is connected to the network, it is assigned an IP number. interface is connected to the network, it is assigned an IP number.
In the current Internet, the transport layers are coupled to the IP In the current Internet, the transport layers are coupled to the IP
addresses. Neither can evolve separately from the other. IPng addresses. Neither can evolve separately from the other. IPng
deliberations were strongly shaped by the decision that a deliberations were strongly shaped by the decision that a
corresponding TCPng would not be created. corresponding TCPng would not be created.
Domain Names provide hierarchically assigned names for some computing
platforms and some services. Each hierarchy is delegated from the
level above; there is no anonymity in Domain Names.
Email, SIP and WWW addresses provide naming for humans, autonomous
applications, and documents. Email, SIP and WWW addresses are
extensions of Domain Names.
There are three critical deficiencies with the current namespaces. There are three critical deficiencies with the current namespaces.
Firstly, dynamic readdressing cannot be directly managed. Secondly, Firstly, dynamic readdressing cannot be directly managed. Secondly,
anonymity is not provided in a consistent, trustable manner. anonymity is not provided in a consistent, trustable manner.
Finally, authentication for systems and datagrams is not provided. Finally, authentication for systems and datagrams is not provided.
All of these deficiencies arise because computing platforms are not All of these deficiencies arise because computing platforms are not
well named with the current namespaces. well named with the current namespaces.
4.1 A desire for a namespace for computing platforms 4.1 A desire for a namespace for computing platforms
An independent namespace for computing platforms could be used in An independent namespace for computing platforms could be used in
skipping to change at page 7, line 43 skipping to change at page 7, line 38
bottom up, in a pairwise deployment. bottom up, in a pairwise deployment.
o The names should have a fixed length representation, for easy o The names should have a fixed length representation, for easy
inclusion in datagram headers and existing programming interfaces inclusion in datagram headers and existing programming interfaces
(e.g the TCB). (e.g the TCB).
o Using the namespace should be affordable when used in protocols. o Using the namespace should be affordable when used in protocols.
This is primarily a packet size issue. There is also a This is primarily a packet size issue. There is also a
computational concern in affordability. computational concern in affordability.
o The names must be statistically globally unique. 64 bits is o Name collisions should be avoided as much as possible. The
inadequate to make the probability of collisions sufficiently low mathematics of the birthday paradox can be used to estimate the
(1% chance of collision in a population of 640M); thus, chance of a collision in a given population and hash space. In
approximately 100 or more bits should be used. general, for a random hash space of size n bits, we would expect
to obtain a collision after approximately 1.2*sqrt(2**n) hashes
were obtained. For 64 bits, this number is roughly 4 billion. A
hash size of 64 bits may be too small to avoid collisions in a
large population; for example, there is a 1% chance of collision
in a population of 640M. For 100 bits (or more), we would not
expect a collision until approximately 2**50 (1 quadrillion)
hashes were generated.
o The names should have a localized abstraction so that it can be o The names should have a localized abstraction so that it can be
used in existing protocols and APIs. used in existing protocols and APIs.
o It must be possible to create names locally. This can provide o It must be possible to create names locally. This can provide
anonymity at the cost of making resolvability very difficult. anonymity at the cost of making resolvability very difficult.
* Sometimes the names may contain a delegation component. This * Sometimes the names may contain a delegation component. This
is the cost of resolvability. is the cost of resolvability.
o The namespace should provide authentication services. o The namespace should provide authentication services.
o The names should be long lived, but replaceable at any time. This o The names should be long lived, but replaceable at any time. This
impacts access control lists; short lifetimes will tend to result impacts access control lists; short lifetimes will tend to result
in tedious list maintenance or require a namespace infrastructure in tedious list maintenance or require a namespace infrastructure
for central control of access lists. for central control of access lists.
In this document, a new namespace approaching these ideas is called In this document, a new namespace approaching these ideas is called
the Host Identity namespace. Using Host Identities requires its own the Host Identity namespace. Using Host Identities requires its own
protocol layer, the Host Identity Protocol, between the protocol layer, the Host Identity Protocol, between the
internetworking and transport layers. The names are based on internetworking and transport layers. The names are based on public-
public-key cryptography to supply authentication services. Properly key cryptography to supply authentication services. Properly
designed, it can deliver all of the above stated requirements. designed, it can deliver all of the above stated requirements.
5. Host Identity namespace 5. Host Identity namespace
A name in the Host Identity namespace, a Host Identifier (HI), A name in the Host Identity namespace, a Host Identifier (HI),
represents a statistically globally unique name for naming any system represents a statistically globally unique name for naming any system
with an IP stack. This identity is normally associated with, but not with an IP stack. This identity is normally associated with, but not
limited to, an IP stack. A system can have multiple identities, some limited to, an IP stack. A system can have multiple identities, some
'well known', some unpublished or 'anonymous'. A system may 'well known', some unpublished or 'anonymous'. A system may self-
self-assert its own identity, or may use a third-party authenticator assert its own identity, or may use a third-party authenticator like
like DNSSEC [2], PGP, or X.509 to 'notarize' the identity assertion. DNSSEC [2], PGP, or X.509 to 'notarize' the identity assertion. It
It is expected that the Host Identifiers will initially be is expected that the Host Identifiers will initially be authenticated
authenticated with DNSSEC and that all implementations will support with DNSSEC and that all implementations will support DNSSEC as a
DNSSEC as a minimal baseline. minimal baseline.
In theory, any name that can claim to be 'statistically globally In theory, any name that can claim to be 'statistically globally
unique' may serve as a Host Identifier. However, in the authors' unique' may serve as a Host Identifier. However, in the authors'
opinion, a public key of a 'public key pair' makes the best Host opinion, a public key of a 'public key pair' makes the best Host
Identifier. As documented in the Host Identity Protocol Identifier. As will be specified in the Host Identity Protocol
specification [6], a public-key-based HI can authenticate the HIP specification, a public-key-based HI can authenticate the HIP packets
packets and protect them for man-in-the-middle attacks. Since and protect them for man-in-the-middle attacks. Since authenticated
authenticated datagrams are mandatory to provide much of HIP's datagrams are mandatory to provide much of HIP's denial-of-service
denial-of-service protection, the Diffie-Hellman exchange in HIP has protection, the Diffie-Hellman exchange in HIP has to be
to be authenticated. Thus, only public-key HI and authenticated HIP authenticated. Thus, only public-key HI and authenticated HIP
messages are supported in practice. In this document, the messages are supported in practice. In this document, the non-
non-cryptographic forms of HI and HIP are presented to complete the cryptographic forms of HI and HIP are presented to complete the
theory of HI, but they should not be implemented as they could theory of HI, but they should not be implemented as they could
produce worse denial-of-service attacks than the Internet has without produce worse denial-of-service attacks than the Internet has without
Host Identity. Host Identity.
5.1 Host Identifiers 5.1 Host Identifiers
Host Identity adds two main features to Internet protocols. The Host Identity adds two main features to Internet protocols. The
first is a decoupling of the internetworking and transport layers; first is a decoupling of the internetworking and transport layers;
see Section 6. This decoupling will allow for independent evolution see Section 6. This decoupling will allow for independent evolution
of the two layers. Additionally, it can provide end-to-end services of the two layers. Additionally, it can provide end-to-end services
skipping to change at page 9, line 30 skipping to change at page 9, line 30
the private key defines the Identity itself. If the private key is the private key defines the Identity itself. If the private key is
possessed by more than one node, the Identity can be considered to be possessed by more than one node, the Identity can be considered to be
a distributed one. a distributed one.
Architecturally, any other Internet naming convention might form a Architecturally, any other Internet naming convention might form a
usable base for Host Identifiers. However, non-cryptographic names usable base for Host Identifiers. However, non-cryptographic names
should only be used in situations of high trust - low risk. That is should only be used in situations of high trust - low risk. That is
any place where host authentication is not needed (no risk of host any place where host authentication is not needed (no risk of host
spoofing) and no use of IPsec. However, at least for interconnected spoofing) and no use of IPsec. However, at least for interconnected
networks spanning several operational domains, the set of networks spanning several operational domains, the set of
environments where the risk of host spoofing allowed by environments where the risk of host spoofing allowed by non-
non-cryptographic Host Identifiers is acceptable is the null set. cryptographic Host Identifiers is acceptable is the null set. Hence,
Hence, the current HIP documents do not specify how to use any other the current HIP documents do not specify how to use any other types
types of Host Identifiers but public keys. of Host Identifiers but public keys.
The actual Host Identities are never directly used in any Internet The actual Host Identities are never directly used in any Internet
protocols. The corresponding Host Identifiers (public keys) may be protocols. The corresponding Host Identifiers (public keys) may be
stored in various DNS or LDAP directories as identified elsewhere in stored in various DNS or LDAP directories as identified elsewhere in
this document, and they are passed in the HIP base exchange. A Host this document, and they are passed in the HIP base exchange. A Host
Identity Tag (HIT) is used in other protocols to represent the Host Identity Tag (HIT) is used in other protocols to represent the Host
Identity. Another representation of the Host Identities, the Local Identity. Another representation of the Host Identities, the Local
Scope Identifier (LSI), can also be used in protocols and APIs. Scope Identifier (LSI), can also be used in protocols and APIs.
5.2 Storing Host Identifiers in DNS 5.2 Storing Host Identifiers in DNS
The public Host Identifiers should be stored in DNS; the unpublished The public Host Identifiers should be stored in DNS; the unpublished
Host Identifiers should not be stored anywhere (besides the Host Identifiers should not be stored anywhere (besides the
communicating hosts themselves). The (public) HI is stored in a new communicating hosts themselves). The (public) HI is stored in a new
RR type, to be defined. This RR type is likely to be quite similar RR type, to be defined. This RR type is likely to be quite similar
to the IPSECKEY RR [7]. to the IPSECKEY RR [6].
Alternatively, or in addition to storing Host Identifiers in the DNS, Alternatively, or in addition to storing Host Identifiers in the DNS,
they may be stored in various kinds of Public Key Infrastructure they may be stored in various kinds of Public Key Infrastructure
(PKI). Such a practice may allow them to be used for purposes other (PKI). Such a practice may allow them to be used for purposes other
than pure host identification. than pure host identification.
5.3 Host Identity Tag (HIT) 5.3 Host Identity Tag (HIT)
A Host Identity Tag is a 128-bit representation for a Host Identity. A Host Identity Tag is a 128-bit representation for a Host Identity.
It is created by taking a cryptographic hash over the corresponding It is created by taking a cryptographic hash over the corresponding
skipping to change at page 10, line 31 skipping to change at page 10, line 31
a single HIT mapping to more than one Host Identity, the Host a single HIT mapping to more than one Host Identity, the Host
Identifiers (public keys) will make the final difference. If there Identifiers (public keys) will make the final difference. If there
is more than one public key for a given node, the HIT acts as a hint is more than one public key for a given node, the HIT acts as a hint
for the correct public key to use. for the correct public key to use.
5.4 Local Scope Identifier (LSI) 5.4 Local Scope Identifier (LSI)
An LSI is a 32-bit localized representation for a Host Identity. The An LSI is a 32-bit localized representation for a Host Identity. The
purpose of an LSI is to facilitate using Host Identities in existing purpose of an LSI is to facilitate using Host Identities in existing
protocols and APIs. LSI's advantage over HIT is its size; its protocols and APIs. LSI's advantage over HIT is its size; its
disadvantage is its local scope. The generation of LSIs is defined disadvantage is its local scope.
in the Host Identity Protocol specification [6].
Examples of how LSIs can be used include: as the address in an FTP Examples of how LSIs can be used include: as the address in an FTP
command and as the address in a socket call. Thus, LSIs act as a command and as the address in a socket call. Thus, LSIs act as a
bridge for Host Identities into IPv4-based protocols and APIs. bridge for Host Identities into IPv4-based protocols and APIs.
6. New stack architecture 6. New stack architecture
One way to characterize Host Identity is to compare the proposed new One way to characterize Host Identity is to compare the proposed new
architecture with the current one. As discussed above, the IP architecture with the current one. As discussed above, the IP
addresses can be seen to be a confounding of routing direction addresses can be seen to be a confounding of routing direction
vectors and interface names. Using the terminology from the IRTF vectors and interface names. Using the terminology from the IRTF
Name Space Research Group Report [8] and, e.g., the unpublished Name Space Research Group Report [7] and, e.g., the unpublished
Internet-Draft Endpoints and Endpoint Names [12] by Noel Chiappa, the Internet-Draft Endpoints and Endpoint Names [10] by Noel Chiappa, the
IP addresses currently embody the dual role of locators and end-point IP addresses currently embody the dual role of locators and end-point
identifiers. That is, each IP address names a topological location identifiers. That is, each IP address names a topological location
in the Internet, thereby acting as a routing direction vector, or in the Internet, thereby acting as a routing direction vector, or
locator. At the same time, the IP address names the physical network locator. At the same time, the IP address names the physical network
interface currently located at the point-of-attachment, thereby interface currently located at the point-of-attachment, thereby
acting as a end-point name. acting as a end-point name.
In the HIP architecture, the end-point names and locators are In the HIP architecture, the end-point names and locators are
separated from each other. IP addresses continue to act as locators. separated from each other. IP addresses continue to act as locators.
The Host Identifiers take the role of end-point identifiers. It is The Host Identifiers take the role of end-point identifiers. It is
skipping to change at page 11, line 27 skipping to change at page 11, line 27
| | | |
| | | |
| | | |
End-point | End-point --- Host Identity End-point | End-point --- Host Identity
\ | | \ | |
\ | | \ | |
\ | | \ | |
\ | | \ | |
Location --- IP address Location --- IP address Location --- IP address Location --- IP address
Figure 1 Figure 1
6.1 Transport associations and end-points 6.1 Transport associations and end-points
Architecturally, HIP provides for a different binding of Architecturally, HIP provides for a different binding of transport-
transport-layer protocols. That is, the transport-layer layer protocols. That is, the transport-layer associations, i.e.,
associations, i.e., TCP connections and UDP associations, are no TCP connections and UDP associations, are no longer bound to IP
longer bound to IP addresses but to Host Identities. addresses but to Host Identities.
It is possible that a single physical computer hosts several logical It is possible that a single physical computer hosts several logical
end-points. With HIP, each of these end-points would have a distinct end-points. With HIP, each of these end-points would have a distinct
Host Identity. Furthermore, since the transport associations are Host Identity. Furthermore, since the transport associations are
bound to Host Identities, HIP provides for process migration and bound to Host Identities, HIP provides for process migration and
clustered servers. That is, if a Host Identity is moved from one clustered servers. That is, if a Host Identity is moved from one
physical computer to another, it is also possible to simultaneously physical computer to another, it is also possible to simultaneously
move all the transport associations without breaking them. move all the transport associations without breaking them.
Similarly, if it is possible to distribute the processing of a single Similarly, if it is possible to distribute the processing of a single
Host Identity over several physical computers, HIP provides for Host Identity over several physical computers, HIP provides for
skipping to change at page 13, line 20 skipping to change at page 13, line 20
Although the idea of informing about address changes by simply Although the idea of informing about address changes by simply
sending packets with a new source address appears appealing, it is sending packets with a new source address appears appealing, it is
not secure enough. That is, even if HIP does not rely on the source not secure enough. That is, even if HIP does not rely on the source
address for anything (once the base exchange has been completed), it address for anything (once the base exchange has been completed), it
appears to be necessary to check a mobile node's reachability at the appears to be necessary to check a mobile node's reachability at the
new address before actually sending any larger amounts of traffic to new address before actually sending any larger amounts of traffic to
the new address. the new address.
Blindly accepting new addresses would potentially lead to flooding Blindly accepting new addresses would potentially lead to flooding
Denial-of-Service attacks against third parties [10]. In a Denial-of-Service attacks against third parties [8]. In a
distributed flooding attack an attacker opens high volume HIP distributed flooding attack an attacker opens high volume HIP
connections with a large number of hosts (using unpublished HIs), and connections with a large number of hosts (using unpublished HIs), and
then claims to all of these hosts that it has moved to a target then claims to all of these hosts that it has moved to a target
node's IP address. If the peer hosts were to simply accept the move, node's IP address. If the peer hosts were to simply accept the move,
the result would be a packet flood to the target node's address. To the result would be a packet flood to the target node's address. To
close this attack, HIP includes an address check mechanism where the close this attack, HIP includes an address check mechanism where the
reachability of a node is separately checked at each address before reachability of a node is separately checked at each address before
using the address for larger amounts of traffic. using the address for larger amounts of traffic.
Whenever HIP is used between two hosts that fully trust each other, Whenever HIP is used between two hosts that fully trust each other,
skipping to change at page 14, line 36 skipping to change at page 14, line 36
Bump-in-the-Wire (BITW) implementations, only ESP transport mode is Bump-in-the-Wire (BITW) implementations, only ESP transport mode is
supported. An ESP SA pair is indexed by the SPIs and the two HITs supported. An ESP SA pair is indexed by the SPIs and the two HITs
(both HITs since a system can have more than one HIT). The SAs need (both HITs since a system can have more than one HIT). The SAs need
not to be bound to IP addresses; all internal control of the SA is by not to be bound to IP addresses; all internal control of the SA is by
the HITs. Thus, a host can easily change its address using Mobile the HITs. Thus, a host can easily change its address using Mobile
IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs. IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs.
Since the transports are bound to the SA (via an LSI or a HIT), any Since the transports are bound to the SA (via an LSI or a HIT), any
active transport is also maintained. Thus, real-world conditions active transport is also maintained. Thus, real-world conditions
like loss of a PPP connection and its re-establishment or a mobile like loss of a PPP connection and its re-establishment or a mobile
handover will not require a HIP negotiation or disruption of handover will not require a HIP negotiation or disruption of
transport services [14]. transport services [12].
Since HIP does not negotiate any SA lifetimes, all lifetimes are Since HIP does not negotiate any SA lifetimes, all lifetimes are
local policy. The only lifetimes a HIP implementation must support local policy. The only lifetimes a HIP implementation must support
are sequence number rollover (for replay protection), and SA timeout are sequence number rollover (for replay protection), and SA timeout.
[6]. An SA times out if no packets are received using that SA. An SA times out if no packets are received using that SA.
Implementations may support lifetimes for the various ESP transforms. Implementations may support lifetimes for the various ESP transforms.
9. HIP and NATs 9. HIP and NATs
Passing packets between different IP addressing realms requires Passing packets between different IP addressing realms requires
changing IP addresses in the packet header. This may happen, for changing IP addresses in the packet header. This may happen, for
example, when a packet is passed between the public Internet and a example, when a packet is passed between the public Internet and a
private address space, or between IPv4 and IPv6 networks. The private address space, or between IPv4 and IPv6 networks. The
address translation is usually implemented as Network Address address translation is usually implemented as Network Address
Translation (NAT) [4] or NAT Protocol translation (NAT-PT) [3]. Translation (NAT) [4] or NAT Protocol translation (NAT-PT) [3].
skipping to change at page 16, line 34 skipping to change at page 16, line 34
o Reversible: A return header can always be formed by reversing the o Reversible: A return header can always be formed by reversing the
source and destination addresses. source and destination addresses.
o Omniscient: Each host knows what address a partner host can use to o Omniscient: Each host knows what address a partner host can use to
send packets to it. send packets to it.
Actually, the fourth can be inferred from 1 and 3, but it is worth Actually, the fourth can be inferred from 1 and 3, but it is worth
mentioning for reasons that will be obvious soon if not already. mentioning for reasons that will be obvious soon if not already.
In the current "post-classic" world, we are intentionally trying to In the current "post-classic" world, we are intentionally trying to
get rid of the second invariant (both for mobility and for get rid of the second invariant (both for mobility and for multi-
multi-homing), and we have been forced to give up the first and the homing), and we have been forced to give up the first and the fourth.
fourth. Realm Specific IP [5] is an attempt to reinstate the fourth Realm Specific IP [5] is an attempt to reinstate the fourth invariant
invariant without the first invariant. IPv6 is an attempt to without the first invariant. IPv6 is an attempt to reinstate the
reinstate the first invariant. first invariant.
Few systems on the Internet have DNS names that are meaningful. That Few systems on the Internet have DNS names that are meaningful. That
is, if they have a Fully Qualified Domain Name (FQDN), that name is, if they have a Fully Qualified Domain Name (FQDN), that name
typically belongs to a NAT device or a dial-up server, and does not typically belongs to a NAT device or a dial-up server, and does not
really identify the system itself but its current connectivity. really identify the system itself but its current connectivity.
FQDNs (and their extensions as email names) are application-layer FQDNs (and their extensions as email names) are application-layer
names; more frequently naming services than a particular system. names; more frequently naming services than a particular system.
This is why many systems on the Internet are not registered in the This is why many systems on the Internet are not registered in the
DNS; they do not have services of interest to other Internet hosts. DNS; they do not have services of interest to other Internet hosts.
skipping to change at page 17, line 23 skipping to change at page 17, line 23
addresses in the network-layer protocol are reversible, then things addresses in the network-layer protocol are reversible, then things
work ok because HIP takes care of host identification, and work ok because HIP takes care of host identification, and
reversibility allows one to get a packet back to one's partner host. reversibility allows one to get a packet back to one's partner host.
You do not care if the network-layer address changes in transit You do not care if the network-layer address changes in transit
(mutable) and you don't care what network-layer address the partner (mutable) and you don't care what network-layer address the partner
is using (non-omniscient). is using (non-omniscient).
12.1 HIP's answers to NSRG questions 12.1 HIP's answers to NSRG questions
The IRTF Name Space Research Group has posed a number of evaluating The IRTF Name Space Research Group has posed a number of evaluating
questions in their report [8]. In this section, we provide answers questions in their report [7]. In this section, we provide answers
to these questions. to these questions.
1. How would a stack name improve the overall functionality of the 1. How would a stack name improve the overall functionality of the
Internet? Internet?
HIP decouples the internetworking layer from the transport HIP decouples the internetworking layer from the transport
layer, allowing each to evolve separately. The decoupling layer, allowing each to evolve separately. The decoupling
makes end-host mobility and multi-homing easier, also across makes end-host mobility and multi-homing easier, also across
IPv4 and IPv6 networks. HIs make network renumbering easier, IPv4 and IPv6 networks. HIs make network renumbering easier,
and they also make process migration and clustered servers and they also make process migration and clustered servers
skipping to change at page 18, line 36 skipping to change at page 18, line 36
7. If we add an additional layer would it make the address list in 7. If we add an additional layer would it make the address list in
SCTP unnecessary? SCTP unnecessary?
Yes Yes
8. What additional security benefits would a new naming scheme 8. What additional security benefits would a new naming scheme
offer? offer?
HIP reduces dependency on IP addresses, making the so called HIP reduces dependency on IP addresses, making the so called
address ownership [13] problems easier to solve. In practice, address ownership [11] problems easier to solve. In practice,
HIP provides security for end-host mobility and multi-homing. HIP provides security for end-host mobility and multi-homing.
Furthermore, since HIP Host Identifiers are public keys, Furthermore, since HIP Host Identifiers are public keys,
standard public key certificate infrastructures can be applied standard public key certificate infrastructures can be applied
on the top of HIP. on the top of HIP.
9. What would the resolution mechanisms be, or what characteristics 9. What would the resolution mechanisms be, or what characteristics
of a resolution mechanisms would be required? of a resolution mechanisms would be required?
For most purposes, an approach where DNS names are resolved For most purposes, an approach where DNS names are resolved
simultaneously to HIs and IP addresses is sufficient. simultaneously to HIs and IP addresses is sufficient.
skipping to change at page 19, line 22 skipping to change at page 19, line 22
that potentially could be more damaging to a host's ability to that potentially could be more damaging to a host's ability to
conduct business as usual. conduct business as usual.
Resource exhausting denial-of-service attacks take advantage of the Resource exhausting denial-of-service attacks take advantage of the
cost of setting up a state for a protocol on the responder compared cost of setting up a state for a protocol on the responder compared
to the 'cheapness' on the initiator. HIP allows a responder to to the 'cheapness' on the initiator. HIP allows a responder to
increase the cost of the start of state on the initiator and makes an increase the cost of the start of state on the initiator and makes an
effort to reduce the cost to the responder. This is done by having effort to reduce the cost to the responder. This is done by having
the responder start the authenticated Diffie-Hellman exchange instead the responder start the authenticated Diffie-Hellman exchange instead
of the initiator, making the HIP base exchange 4 packets long. There of the initiator, making the HIP base exchange 4 packets long. There
are more details on this process in the Host Identity Protocol are more details on this process in the Host Identity Protocol under
specification [6]. development.
HIP optionally supports opportunistic negotiation. That is, if a HIP optionally supports opportunistic negotiation. That is, if a
host receives a start of transport without a HIP negotiation, it can host receives a start of transport without a HIP negotiation, it can
attempt to force a HIP exchange before accepting the connection. attempt to force a HIP exchange before accepting the connection.
This has the potential for DoS attacks against both hosts. If the This has the potential for DoS attacks against both hosts. If the
method to force the start of HIP is expensive on either host, the method to force the start of HIP is expensive on either host, the
attacker need only spoof a TCP SYN. This would put both systems into attacker need only spoof a TCP SYN. This would put both systems into
the expensive operations. HIP avoids this attack by having the the expensive operations. HIP avoids this attack by having the
responder send a simple HIP packet that it can pre-build. Since this responder send a simple HIP packet that it can pre-build. Since this
packet is fixed and easily replayed, the initiator only reacts to it packet is fixed and easily replayed, the initiator only reacts to it
skipping to change at page 21, line 25 skipping to change at page 21, line 25
these NATs of the change of the HIT. This is mandatory for systems these NATs of the change of the HIT. This is mandatory for systems
that function as responders behind a NAT. In a similar vein, if a that function as responders behind a NAT. In a similar vein, if a
host is notified of a change in a HIT of an initiator, it should host is notified of a change in a HIT of an initiator, it should
notify its NAT of the change. In this manner, NATs will get updated notify its NAT of the change. In this manner, NATs will get updated
with the HIT change. with the HIT change.
13.2 Non-security considerations 13.2 Non-security considerations
The definition of the Host Identifier states that the HI need not be The definition of the Host Identifier states that the HI need not be
a public key. It implies that the HI could be any value; for example a public key. It implies that the HI could be any value; for example
a FQDN. This document does not describe how to support such a a FQDN. This document does not describe how to support such a non-
non-cryptographic HI. A non-cryptographic HI would still offer the cryptographic HI. A non-cryptographic HI would still offer the
services of the HIT or LSI for NAT traversal. It would be possible services of the HIT or LSI for NAT traversal. It would be possible
to carry HITs in HIP packets that had neither privacy nor to carry HITs in HIP packets that had neither privacy nor
authentication. Since such a mode would offer so little additional authentication. Since such a mode would offer so little additional
functionality for so much addition to the IP kernel, it has not been functionality for so much addition to the IP kernel, it has not been
defined. Given how little public key cryptography HIP requires, HIP defined. Given how little public key cryptography HIP requires, HIP
should only be implemented using public key Host Identities. should only be implemented using public key Host Identities.
If it is desirable to use HIP in a low security situation where If it is desirable to use HIP in a low security situation where
public key computations are considered expensive, HIP can be used public key computations are considered expensive, HIP can be used
with very short Diffie-Hellman and Host Identity keys. Such use with very short Diffie-Hellman and Host Identity keys. Such use
skipping to change at page 21, line 50 skipping to change at page 21, line 50
not on cryptographic strength. not on cryptographic strength.
14. IANA considerations 14. IANA considerations
This document has no actions for IANA. This document has no actions for IANA.
15. Acknowledgments 15. Acknowledgments
For the people historically involved in the early stages of HIP, see For the people historically involved in the early stages of HIP, see
the Acknowledgements section in the Host Identity Protocol the Acknowledgements section in the Host Identity Protocol
specification [6]. specification.
During the later stages of this document, when the editing baton was During the later stages of this document, when the editing baton was
transfered to Pekka Nikander, the comments from the early transfered to Pekka Nikander, the comments from the early
implementors and others, including Jari Arkko, Tom Henderson, Petri implementors and others, including Jari Arkko, Tom Henderson, Petri
Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim
Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. Finally, Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. Finally,
Lars Eggert, Spencer Dawkins and Dave Crocker provided valuable input Lars Eggert, Spencer Dawkins and Dave Crocker provided valuable input
during the final stages of publication, most of which was during the final stages of publication, most of which was
incorporated but some of which the authors decided to ignore in order incorporated but some of which the authors decided to ignore in order
to get this document published in the first place. to get this document published in the first place.
16 Informative references 16. Informative references
[1] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [1] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC [2] Eastlake, D., "Domain Name System Security Extensions",
2535, March 1999. RFC 2535, March 1999.
[3] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [3] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[5] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm [5] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001. Specific IP: Framework", RFC 3102, October 2001.
[6] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 [6] Richardson, M., "A Method for Storing IPsec Keying Material in
(work in progress), June 2004. DNS", RFC 4025, March 2005.
[7] Richardson, M., "A method for storing IPsec keying material in
DNS", draft-ietf-ipseckey-rr-10 (work in progress), April 2004.
[8] Lear, E. and R. Droms, "What's In A Name:Thoughts from the
NSRG", draft-irtf-nsrg-report-10 (work in progress), September
2003.
[9] Nikander, P., "End-Host Mobility and Multi-Homing with Host [7] Lear, E. and R. Droms, "What's In A Name: Thoughts from the
Identity Protocol", draft-ietf-hip-mm-00 (work in progress), NSRG", draft-irtf-nsrg-report-10 (work in progress),
October 2004. September 2003.
[10] Nikander, P., "Mobile IP version 6 Route Optimization Security [8] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-00 (work in Design Background", draft-ietf-mip6-ro-sec-03 (work in
progress), April 2004. progress), May 2005.
[11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[12] Chiappa, J., "Endpoints and Endpoint Names: A Proposed [10] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", URL Enhancement to the Internet Architecture",
http://users.exis.net/~jnc/tech/endpoints.txt, 1999. URL http://users.exis.net/~jnc/tech/endpoints.txt, 1999.
[13] Nikander, P., "Denial-of-Service, Address Ownership, and Early [11] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", in Proceesings of Security Authentication in the IPv6 World", in Proceesings of Security
Protocols, 9th International Workshop, Cambridge, UK, April Protocols, 9th International Workshop, Cambridge, UK, April
25-27 2001, LNCS 2467, pp. 12-26, Springer, 2002. 25-27 2001, LNCS 2467, pp. 12-26, Springer, 2002.
[14] Bellovin, S., "EIDs, IPsec, and HostNAT", in Proceedings of [12] Bellovin, S., "EIDs, IPsec, and HostNAT", in Proceedings
41th IETF, Los Angeles, CA, March 1998. of 41th IETF, Los Angeles, CA, March 1998.
Authors' Addresses Authors' Addresses
Robert Moskowitz Robert Moskowitz
ICSAlabs, a Division of TruSecure Corporation ICSAlabs, a Division of TruSecure Corporation
1000 Bent Creek Blvd, Suite 200 1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA Mechanicsburg, PA
USA USA
EMail: rgm@icsalabs.com Email: rgm@icsalabs.com
Pekka Nikander Pekka Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com Email: pekka.nikander@nomadiclab.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 24, line 41 skipping to change at page 24, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 53 change blocks. 
119 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/