Multi6 A. Nagarajan
Internet-Draft H. Tschofenig
Expires: April 18, 2005 Siemens
October 18, 2004
Comparative Analysis of Multi6 Proposals using a Locator/Identifier
Split
draft-nagarajan-multi6-comparison-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
An IP address serves as a locator and an identifier in the classical
Internet environment. This dual role of the IP address makes
mobility and multihoming a challenging task. There have been various
proposals to overcome this limitation, particularly from the Multi6
working group.
This memo makes a comparative analysis of these proposals that
support a locator/identifier split for multihoming in IPv6 from the
Nagarajan & Tschofenig Expires April 18, 2005 [Page 1]
Internet-Draft Multi6 Protocol Comparison October 2004
security point of view. The purpose is also to provide a common
framework under which future proposals can be compared and chosen for
various security requirements.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Strong Identity Multihoming . . . . . . . . . . . . . . . . . 4
2.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4
2.2 SIM Protocol Overview . . . . . . . . . . . . . . . . . . 4
2.3 SIM Security Considerations . . . . . . . . . . . . . . . 5
3. Multihoming without Identifiers . . . . . . . . . . . . . . . 9
3.1 Notational Conventions . . . . . . . . . . . . . . . . . . 9
3.2 NOID Protocol Overview . . . . . . . . . . . . . . . . . . 9
3.3 NOID Security Considerations . . . . . . . . . . . . . . . 10
4. Multihoming using 64-bit Crypto-Based IDs . . . . . . . . . . 12
4.1 Notational Conventions . . . . . . . . . . . . . . . . . . 12
4.2 CB64 Protocol Overview . . . . . . . . . . . . . . . . . . 13
4.3 CB64 Security Considerations . . . . . . . . . . . . . . . 14
5. Weak Identifier Multihoming Protocol . . . . . . . . . . . . . 15
5.1 Notational Conventions . . . . . . . . . . . . . . . . . . 15
5.2 WIMP Protocol Overview . . . . . . . . . . . . . . . . . . 16
5.3 WIMP Security Considerations . . . . . . . . . . . . . . . 17
6. Location Independent Network . . . . . . . . . . . . . . . . . 19
6.1 Notational Conventions . . . . . . . . . . . . . . . . . . 19
6.2 LIN6 Protocol Overview . . . . . . . . . . . . . . . . . . 20
6.3 LIN6 Security Considerations . . . . . . . . . . . . . . . 21
7. Host Identity Protocol . . . . . . . . . . . . . . . . . . . . 24
7.1 Notational Conventions . . . . . . . . . . . . . . . . . . 24
7.2 HIP Protocol Overview . . . . . . . . . . . . . . . . . . 24
7.3 HIP Security Considerations . . . . . . . . . . . . . . . 25
8. Other Security Considerations . . . . . . . . . . . . . . . . 28
9. Comparison of Multi6 Proposals . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 31
11.2 Informative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 33
Nagarajan & Tschofenig Expires April 18, 2005 [Page 2]
Internet-Draft Multi6 Protocol Comparison October 2004
1. Introduction
The Multi6 group aims at providing potential solutions for
multihoming support in IPv6. Most of these proposals try to define a
new convergence layer operating between the classic internet and the
transport layers [8]. This eventually splits the dual role of the IP
from being both locators and identifiers to only locators. For
naming the end hosts, new identifiers are thought of. Such locator/
identifier split multihoming solutions bring in new security
considerations.
The IETF draft [6] discusses some common threats relating to IPv6
multihoming solutions. In this memo we look into the security issues
of some Multi6 proposals that deal with the locator/identifier split
and try to compare them on the basis of the threats draft. We look
at the proposals from the following point of view: There is a
protocol which establishes state at two endpoints. For future state
updates (in case of multihoming and mobility) an authorization
problem exists as to who is allowed to modify the pre-established
state and how. We analyse the properties of the proposed protocols.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 3]
Internet-Draft Multi6 Protocol Comparison October 2004
2. Strong Identity Multihoming
The SIM proposal [1] assumes that the problem to be solved is site
multihoming, with the ability to have the set of site locator
prefixes change over time due to site renumbering. It also assumes
that public key signatures are not required for normal communication.
They are used for verification only at the time of locator prefix
changes for a host or when two hosts claim to use the same
identifier.
This proposal aims to achieve site multihoming by introducing an M6
shim layer between the classic IP and the transport layer. All the
applications and the upper layer protocols use identifiers to name
the hosts. These identifiers are hashes of the public key of the
hosts. The network layer uses IPv6 to locate the hosts on the
internet. The M6 layer is an extension header between the IP and the
transport layer that maps the identifiers to the locators and vice
versa. From the perspective of the upper layers, the packets seem to
travel end to end using identifiers, although they are rewritten with
locators on flight.
2.1 Notational Conventions
A is the initiating host and B is the responding host. X is a
potentially malicious host.
FQDN (A) is the domain name for A.
Ls(A) is the locator set for A, which consists of L1 (A), L2 (A)
until Ln (A).
ID(A) is an application ID for A.ID(A) is a 128 bit number
consisting of two fixed bits (e.g., 10) followed by 126 bits of a
truncated SHA1 hash of a public key that the host has generated.
CT(A) is a 64 bit "context tag" allocated by A and used when B
sends packets to A. The packets contain the low-order 32 bits of
the tag, named CT32 (A). The full tag is used for DoS-attack
prevention during the PK challenge/response.
2.2 SIM Protocol Overview
The SIM proposal is composed of two parts. The protocol starts with
a 3-way hand shake between the communicating parties where a context
state is established in the M6 layer. The context state includes
information on the peer and local identities, the locator set of the
peer and the local host, the verification status of each locator of
the peer and the context tags of the initiator and the receiver. The
Nagarajan & Tschofenig Expires April 18, 2005 [Page 4]
Internet-Draft Multi6 Protocol Comparison October 2004
context establishment as illustrated in Figure 1is composed of the
Context Request, Context Response and the Context Confirm messages.
The details of this message exchange can be looked into the IETF
draft [1].
I with ID(I) at L1(I)
R with ID(R) at L1(R)
I-->R, CReq :Nonce(I),ID(I),ID(R),CT(I)
R-->I, CRes :Nonce(I),Context[ID(I),ID(R),CT(I),CT(R),
L1(I),L1(R)],TimeStamp,Hash(Context,TimeStamp)
I-->R, CCon :Context[ID(I),ID(R),CT(I),CT(R),L1(I),L1(R)],
Hash(Context,TimeStamp)
Figure 1: SIM protocol Context Establishment
The second part of the SIM proposal is the challenge request-response
protocol shown in Figure 2 that is used when one of the hosts changes
its locator. The protocol relies on the fact that the mobile node
can prove the knowledge of the 64 bit context tags of both the
initiator and the receiver that was used only at the time of state
establishment.
I with ID(I) at L2(I)
R with ID(R) at L1(R)
I-->R, Data packet from unknown locator L2(I)
R-->I, ChaReq:Nonce(R),ID(I),ID(R),CT32(R),L2(I)
I-->R, ChaRes:[Nonce(R),CT32(R),L2(I),
Hash(Nonce(R),ID(I),ID(R),CT(I),CT(R)),PK(R)]Sign(R)
Figure 2: SIM protocol Readdressing
2.3 SIM Security Considerations
The initiator of the communication first tries to establish a
host-pair context with the peer based on information it learns from
the DNS.The responder later establishes some initial state with the
initiator using the context creation 3-way handshake. Locator
updates are later possible using signature verifications. However,
Nagarajan & Tschofenig Expires April 18, 2005 [Page 5]
Internet-Draft Multi6 Protocol Comparison October 2004
it is very crucial that these locator changes be authenticated to
avoid man in the middle attacks.
In order to prevent such attacks during locator updates, the SIM
protocol relies on the ability to verify that the entity requesting
redirection indeed holds the private key where the hash of the
corresponding public key hashes to the ID itself.
1. PREMEDIATED REDIRECTION
From our analysis of this proposal, it is evident that a
premediated redirection attack[6] on host B is possible due to
the absence of an initiator authentication. When host A
initiates a communication with B based on a DNS look up for B,
B initiates a 3-way exchange in order to establish a context
among themselves. However, B does not make any attempt to
reverse look up A in order to verify that A is who he claims
to be. They eventually establish a context pair and start
exchanging data packets. A malicious host X could easily
claim to be A and encourage B to exchange data with it
attempting a premediated redirection attack. A reverse lookup
with the L(X)->FQDN and then forward lookup for FQDN->ID(X)
would prove if X is who he claims to be. SIM fails to do this
and remains unknown about the redirection until A genuinely
initiates a communication with B.
2. REDIRECTING PACKETS TO ATTACKER
Any protocol that does not know how to authenticate locator
changes for a mobile host is open to redirection attacks. The
SIM protocol however uses public key signature verifications
to verify locator updates and is not susceptible to such
attacks. If Host X claims to be A that has just moved and
encourages B to send data packets to it, it (and A) will
receive a challenge request from B. B waits until it receives
the first correct response signed with the private key that
corresponds to the public key of A. It would be impossible
for anybody other than A (even X) to sign using A's private
key. However, host X could attempt to increase the cost of
computation on B's side by compelling it to verify more and
more signatures. This by itself could be a denial of service
attack.
3. REDIRECTING PACKETS TO A BLACK HOLE
This variant of the classic redirection attacks [6] is
different because this forces a host to send packets to a
nonexistent locator and eventually dropping them off.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 6]
Internet-Draft Multi6 Protocol Comparison October 2004
Assuming that A and B are already communicating and X sends a
locator update to B claiming that it is A and has moved (to a
black hole), both A and the black hole locator receive
challenge requests from B. It is evident that only A sends an
acceptable response forcing B to ignore the locator update
from X.
4. REDIRECTING PACKETS TO A THIRD PARTY
Mechanisms that prevent the previous redirection attacks can
prevent this one too. Assuming that A and B are already
communicating, the SIM proposal makes sure that no other host
other than A itself would be able to authenticate to B on the
basis of a challenge response that is signed with A's private
key.
5. PACKET INJECTION
The SIM protocol introduces a M6 shim layer between the IP and
the transport layers. This M6 layer is just an extension
header for the data packets as shown below. It would be
suffice for an attacker X to learn just the 32 bit context tag
to inject false packets in a sequence. Though it would be
difficult for nodes out of path between A and B to guess the
context tag, it would be sufficiently easy for those between
the communicating nodes to learn their context tags, create
new forged packets and inject them.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Type=0 (data) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: M6 packet header
This situation is no different from other IP packets of today
which do not experience any IPsec protection. As a proposed
solution, IPsec could be used along with the SIM proposal.
6. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS
Nagarajan & Tschofenig Expires April 18, 2005 [Page 7]
Internet-Draft Multi6 Protocol Comparison October 2004
During the initial phase of the context establishment, the
proposal avoids using heavy computations in order to remain
stateless. It does not introduce PK signature verifications
until there is a locator change and necessitates one.
However, this could in turn present a resource exhaustion
denial of service attack. The attacker could spoof one or
many challenge response packets to the receiver and force it
to do heavy PK signature verifications. This would exhaust
the responser's resources posing a denial of service to the
original initiator.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 8]
Internet-Draft Multi6 Protocol Comparison October 2004
3. Multihoming without Identifiers
The NOID proposal [2] assumes that the problem to be solved is site
multihoming, with the ability to have the set of site locator
prefixes change over time due to site renumbering. It also assumes
that the DNS infrastructure can be used for verification of the
relationship between locators on both the initiator of communication
and the responding peer. Further, doing a reverse look up for each
locator in the locator set to its FQDN is assumed not to create
significant problem.
NOID proposes an approach for endpoint identifier and locator
separation where the endpoint identifier space is drawn from the
locator space. Instead of creating a new namespace for endpoint
identifiers, the endpoint identifier may be chosen from the set of
locators itself. This initial locator could be used for
communication among hosts until one of them necessitate a locator
update.
3.1 Notational Conventions
A is the initiating host and B is the responding host. X is a
potentially malicious host.
FQDN (A) is the domain name for A.
Ls(A) is the locator set for A, which consists of L1 (A), L2 (A)
until Ln (A).
AID (A) is an application ID for A. In this proposal, AID (A) is
always one member of Ls (A).
3.2 NOID Protocol Overview
The NOID proposal is composed of two parts. The protocol starts with
a 3-way hand shake between the communicating parties where a context
state is established in the M6 layer. The context state includes
information on peer locator which the upper layer protocol uses as
the AID, the local locator which the application uses as the AID, the
locator set of the peer and the local host, the verification status
of each locator of the peer and the FlowIDs of the initiator and the
receiver. The second part of the NOID proposal is the locator
updates. Assuming that the initiator is mobile and sends a packet to
the receiver from a new locator L2(I), the receiver would now have to
perform some return routability test to make sure that the L2(I)
indeed belongs to the initiator. For this, NOID relies on DNS
verifications. The receiver performs a reverse look up for L2(I) to
see if L2 belongs to the locator set of I. This way, it confirms
Nagarajan & Tschofenig Expires April 18, 2005 [Page 9]
Internet-Draft Multi6 Protocol Comparison October 2004
that I is reachable at L2 and makes L2 as the preferred locator.
I with AID(I) at L1(I)
R with AID(R) at L1(R)
I-->R, CReq :Nonce(I),AID(I),AID(R),FlowID(I)
R-->I, CRes :Nonce(I),Context[AID(I),AID(R),FlowID(I),FlowID(R),
L1(I),L1(R)],TimeStamp,Hash(Context,TimeStamp)
I-->R, CCon :Context[AID(I),AID(R),FlowID(I),FlowID(R),L1(I),L1(R),
TimeStamp,Hash(Context,TimeStamp)
Figure 4: NOID protocol Context Establishment
3.3 NOID Security Considerations
Conceptually, the NOID proposal is similar to that of the SIM. It
adds a layer to the middle of IP above most IP processing, but below
IPsec, fragmentation and reassembly functions [7]. It assigns one of
the locators in the locator set of a host as the host identifier and
uses global DNS as a mapping system between IDs and Locators.
Since the NOID proposal does not make use of cryptographic
identifiers, it does not perform PK signature verifications like the
SIM. As an alternative to prevent redirection attacks, it relies on
the DNS (for the hosts which support this protocol) being maintained
with consistent forward and reverse maps.
1. PREMEDIATED REDIRECTION
We understand that the NOID proposal is quite secure from the
premediation attacks [6] due to timely reverse DNS lookups.
When an attacker X using L(X) spoofs like host A and sends a
M6 data packet to B to start a communication, B does not
authenticate X at this point. It sends the context request
message to initiate the 3 way exchange and waits for the
context response message from the initiator. However, after B
sends the context confirm message to the initiator, it starts
asynchronously and incrementally extracting and verifying the
locator set of the initiator from the DNS. This verification
would fail as L(X) would not look up to FQDN(A).NOID suggests
such packets be dropped and an unknown context error be sent.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 10]
Internet-Draft Multi6 Protocol Comparison October 2004
2. REDIRECTING THE PACKETS
In NOID, redirection attacks on the pretext of locator changes
are not possible by an attacker. This is because as soon as a
host receives packets from a new locator, it first looks up
the context states (already has a list of verified locators)
using the flow ID and the locators. If this look up succeeds
then the locator is acceptable for incoming packets. However,
if the locator has not been verified then it puts the new
locator on the top in the list of asynchronous DNS
verifications that are needed to be made. Assuming that A and
B are already communicating and X (using L(X) and FQDN(A)) is
attempting a redirection attack on B, X will never be
successful as its L(X) will not be looked up to FQDN (A) in
the DNS records.
The strength of the NOID proposal relies on the DNS look up
and it is important that any genuine host has authentic DNS
records. It is out of the scope of this draft to look at such
security threats. The DNS reverse look up method prevents all
kinds of redirection attacks including those to the attacker,
a third party or a black hole.
3. PACKET INJECTION
The current draft of the NOID proposal does not talk in detail
about the format of the data packets. It is however clear
that any node in the path between the hosts can look at the
source and destination locators and the flow IDs of the
packets being exchanged. Therefore, it should not be
difficult to inject false packets or manipulate the flow IDs
to affect the original data stream.
4. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS
The NOID proposal uses DNS look up to authenticate the peer
host and for locator changes verifications. Since DNS look up
are so important in NOID, it is also important that the DNS
that is looked up into also has only authentic DNS records.
Hence, a host could use a signed DNS zone or some secure
mechanism for forward or reverse look ups. For instance, when
an attacker X pretending to be host A, spoofs one or many
packets to host B, host B would put the locators of X on the
top of the list for DNS verifications. If it is a signed DNS
zone or a secure look up mechanism, it would end up consuming
a lot of resources of B.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 11]
Internet-Draft Multi6 Protocol Comparison October 2004
4. Multihoming using 64-bit Crypto-Based IDs
The CB64 proposal [3] is remarkably similar to the NOID and the SIM
proposals. It assumes that the problem to be solved is site
multihoming, with the ability to have the set of site locator
prefixes change over time due to site renumbering. It also assumes
that public key signatures are not required for normal communication.
They are used for verification only at the time of locator prefix
changes for a host or when two hosts claim to use the same
identifier.
According to the NOID proposal, hosts that interact with each other
are identified using the AIDs or application IDs. AIDs are also a
part of Ls and are of 128 bits. NOID makes use of flow IDs so that
mapping to the correct AID at the receiving end can be accomplished.
According to the SIM proposal, hosts that interact with each other
use 128 bit cryptographic identifiers that consist of a truncated
SHA1 hash of a public key that the host has generated. SIM also
makes use of context tags that allow the receiver to find the correct
context without relying on the locators in the packet.
CB64 tries to keep the AID and the Flow ID of NOID. However, AIDs in
CB64 are a combination of locators and cryptographic identifiers.
ID(A) which is a 64 bit hash of the public key is embedded in the
lower order bits of AID(A) [which is a part of the Ls (A)]. The
upper 64 bits is the subnet locator.
4.1 Notational Conventions
A is the initiating host and B is the responding host. X is a
potentially malicious host.
FQDN (A) is the domain name for A.
ID(A) is the 64 bit CBID for A
Ls(A) is the locator set for A, which consists of L1(A), L2(A),
until Ln(A). Each Lk(A) contains ID(A) in the low-order bits.
The high-order 64 bits of a locator are sometimes referred to as
the "subnet locator".(The protocol does not prevent a single host
having multiple identities, but that can be viewed multiple
entities A, B etc existing on the same host).
AID (A) is an application ID for A. In this proposal, AID (A) is
always one member of Ls (A).
Nagarajan & Tschofenig Expires April 18, 2005 [Page 12]
Internet-Draft Multi6 Protocol Comparison October 2004
4.2 CB64 Protocol Overview
The CB64 proposal is made of two parts. The protocol starts with a
3-way hand shake between the communicating parties where a context
state is established in the M6 layer. The context state includes
information on peer locator which the upper layer protocol uses as
the AID, the local locator which the application uses as the AID, the
locator set of the peer with each containing the same 64 bit ID in
the lower bits, the locator set of the local host with each locator
containing the same 64 bit ID in the lower bits, the verification
status of each locator of the peer and the FlowIDs of the initiator
and the receiver.
I with AID(I) at L1(I)
R with AID(R) at L1(R)
I-->R, CReq :Nonce(I),AID(I),AID(R),FlowID(I)
R-->I, CRes :Nonce(I),Context[AID(I),AID(R),FlowID(I),FlowID(R),
L1(I),L1(R)],TimeStamp,Hash(Context,TimeStamp)
I-->R, CCon :Context[AID(I),AID(R),FlowID(I),FlowID(R),L1(I),L1(R),
TimeStamp,Hash(Context,TimeStamp)
Figure 5: CB64 protocol Context Establishment
The second part of the CB64 proposal is the challenge
request-response protocol that is used when one of the hosts changes
its locator. The protocol relies on the fact that the mobile node
can prove the knowledge of the FlowIDs of both the initiator and the
receiver that was used only at the time of state establishment.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 13]
Internet-Draft Multi6 Protocol Comparison October 2004
I with AID(I) at L2(I)
R with AID(R) at L1(R)
I-->R, Data packet from unknown locator L2(I)
R-->I, ChaReq:Nonce(R),AID(I),AID(R),FlowID(R),L2(I)
I-->R, ChaRes:[Nonce(R),FlowID(R),L2(I),
Hash(Nonce(R),AID(I),AID(R),FlowID(I),FlowID(R))PK(R)]Sign(R)
Figure 6: CB64 protocol Readdressing
4.3 CB64 Security Considerations
CB64 uses 128 bit locators that are embedded with the cryptographic
identifiers to locate a host on the internet. Similar to the NOID
proposal, it does not use separate identifiers (like the SIM
proposal) but assigns one of these locators as the application
identifier for a host. However, since application identifiers hold
cryptographic identifiers, CB64 performs PK signature verifications
similar to SIM for locator updates verifications.
In order to prevent redirection attacks during locator updates, the
CB64 protocol relies on the ability to verify that the entity
requesting redirection indeed holds the private key where the hash of
the corresponding public key hashes to the ID itself.
1. PREMEDIATED REDIRECTION
From our analysis of this proposal, it is evident that a
premediated redirection attack [6] on host B is possible due
to the absence of an initiator authentication. This scenario
is quite similar to that of the SIM proposal
2. Other security issues
All the security issues of CB64 are exactly similar to that of
the SIM. This is because both the SIM and the CB64 rely on
similar PK signature verification mechanism for locator
changes authentication. Therefore, it is strongly recommended
that security considerations of the SIM proposal be referred.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 14]
Internet-Draft Multi6 Protocol Comparison October 2004
5. Weak Identifier Multihoming Protocol
The WIMP proposal [5] uses a new logical layer between networking and
transport layers that separates the end-point identifier and locator
roles from each other. The identifiers are used to name the
end-points, while IPv6 addresses are used for routing purposes.
Identifiers in WIMP are 128-bit non-routable IDs that are never used
in packets on the network. These IDs are locally generated for both
local and remote nodes by hashing a nonce (for the initiator's
endpoint identity) and the FQDN (for the responder's endpoint
identity). The WIMP layer manages the mapping between IDs and
locators based on internal state.
Communication between two end-points requires establishment of a WIMP
session. Once the session is established, it can be used for
multiple simultaneous or sequential connections to the same
end-point. During WIMP session establishment, WIMP introduces a
separate header into the data packets, between the IP and TCP/UDP
headers that contains information about the WIMP session. WIMP does
not introduce a separate header into all IPv6 (data) packets.
Instead, once a WIMP session is established, the IPv6 FlowID is used
to hold an identifier for the WIMP host-pair context associated with
a given packet. The FlowIDs serve as a convenient "compression tag"
without increasing the packet size.
5.1 Notational Conventions
A is the initiating host and B is the responding host. X is a
potentially malicious host.
ID(I) is an identifier for I and ID(R) is an identifier for R.
FQDN(R) is the domain name for R.
Ls(I) is the locator set for I, which consists of L1(I), L2(I)
until Ln(I).
Ls(R) is the locator set for R.
F(I) is a FlowID assigned by the initiator and used by the
responder. The responder uses F(I) in packets going to the
initiator.
F(R) is a FlowID assigned by the responder and used by the
initiator.
Hk(I) is k-th hash value in the initiator's reverse hash chain.
The H0(I) is the first revealed value, i.e. the "anchor" of the
Nagarajan & Tschofenig Expires April 18, 2005 [Page 15]
Internet-Draft Multi6 Protocol Comparison October 2004
reverse hash chain. Note that the parameter k defines the
revealing order, not the computation order.
Hk(R) is k-th hash value in a responder's reverse hash chain.
5.2 WIMP Protocol Overview
CONTEXT ESTABLISHMENT
Initiator Responder
compute hash chain
generate random ID(I)
select flowid F(I)
INIT: IDs, challenge_I,
HMAC_INIT{H0(I), (IDs|challenge_I|F(I))}
-------------------------->
compute temporary hash chain
CC: IDs, HMAC_INIT, HMAC_CC{H0_R, (IDs|HMAC_INIT)}
<-------------------------
remain stateless
CCR: IDs, H0(I), challenge_I, F(I), HMAC_INIT, HMAC_CC
-------------------------->
recompute the hash chain
verify HMAC_INIT and HMAC_CC
select flowid F(R)
CONF: IDs, H0(R), F(R)
<--------------------------
verify HMAC_CC
READDRESSING EXCHANGE
Initiator Responder
compute new hash chain
REA: IDs, Ls(I), H1(I), H0_new(I), challenge,
HMAC_REA{H2(I), (IDs|Ls(I)|H1(I)|H0_new(I)|challenge}
-------------------------->
verify H1(I)
generate a divided secret using H1(R
send AC per new locator
AC1: IDs, Key_count, Key_mask, key_piece, challenge
... <-------------------------
Nagarajan & Tschofenig Expires April 18, 2005 [Page 16]
Internet-Draft Multi6 Protocol Comparison October 2004
ACn <-------------------------
combine the key pieces
verify the combined key
ACR: IDs, Key_combined, Key_mask, H2(I)
-------------------------->
verify the combined key
H1(R)
verify HMAC_REA
Figure 7: WIMP protocol(context establishment and locator change
verification)
5.3 WIMP Security Considerations
In order to prevent redirection attacks WIMP relies on the ability to
verify that the entity requesting redirection indeed holds the
successor values of a hash chain and is able to combine a divided
secret that is sent via parallel paths.
WIMP uses reverse hash chains and context establishment is based on
opportunistic authentication. In other words, both the initiator and
the responder have to trust each other that the first message comes
from an authentic peer. Once the initial messages have been sent out
safely, the following messages are secure. It would be impossible
for an attacker who had not eaves dropped the initial messages spoof
the following messages and data exchange.
1. PREMEDIATED REDIRECTION
Premediated redirection [6] is possible in WIMP because there
is no authentication of the initial messages. The receiving
host is forced to trust its peer as whom it claims to be.
After the first message, all the other messages are
authenticated. A malicious host X could easily spoof as A to
initiate a communication with B. Since B needs to trust the
first message from the peer, B is fooled to trust X as A.
Then X can happily communicate with B pretending to be A.
As an alternative to avoid this, IPsec could be used for the
initial messages. However, this could have yet another set of
protocol overload problems like key exchanges and security
association establishments.
2. REDIRECTING THE PACKETS
Nagarajan & Tschofenig Expires April 18, 2005 [Page 17]
Internet-Draft Multi6 Protocol Comparison October 2004
The WIMP protocol is sufficiently secure against redirection
attacks because it verifies that the entity requesting
redirection indeed holds the successor values of a hash chain.
Assuming that A and B are already communicating and X spoofs
as A to pose a redirection attack to B, X sends a readdressing
or REA message to B. To avoid a possible redirection attack,
B must verify that the initiator indeed is who he claims to be
(by verifying if the hash value sent in the REA message is a
successor of the previous value) and is reachable at the
claimed locations (by sending a challenge message to all the
locators). In order to authenticate himself X must be able to
guess the successor hash value and to locate at different
topological locations, at the same time, to be able to answer
to the challenges. Since both of these are far from possible,
X would fail to make a successful redirection attack.
3. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS
WIMP uses hash chains as compared to the PK signatures for
host authentication and locator change verifications. The
trade-off between hash chain based message authentication and
signatures is that hash chains are vulnerable for a class of
man-in-the-middle attacks ONLY in the initial couple of
messages. However, if we accept that the first round-trip of
the context establishment exchange is open for such attacks
hash chains have other advantages. The hash chain computation
is a lightweight operation compared to signature verification
and consumes fewer resources at the time of resource
exhaustion attacks [5]. It could also be possible that
signature verifications be used only for the vulnerable
initial messages.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 18]
Internet-Draft Multi6 Protocol Comparison October 2004
6. Location Independent Network
LIN6 [4] is a protocol supporting multihoming and mobility in IPv6.
LIN6 introduces the node id, not the interface id, for each node.
Each node can be identified by its node id no matter where the node
is connected and no matter how many interfaces the node has. In the
IPv6 layer, 64-bit node id called LIN6 ID is used while 128-bit
node-id called LIN6 generalized ID is used above the Transport layer.
TCP connections and security associations can be preserved even if
the node moves to another subnet or the node changes the using
interface in a multihoming environment without modifying TCP or IPsec
LIN6 attempts to make transport connections at the TCP layer using
some form of a standard ID and then passed on the network layer.
When this reaches the network layer, the IPv6 layer overwrites the
standard ID with the network ID and then passes it on further.
6.1 Notational Conventions
A is the initiating host and B is the responding host. X is a
potentially malicious host.
MA-A is the Mobile Agent of A and MA-B is the Mobile Agent of B.
NS is the name server with AAAA records( network prefix of MA and
LIN6 ID of a node).
The LIN6 ID is the ID for a node in the network. This is the EUI
64 standard identifier. The EUI 64 has 64 bits, the upper 24 bits
is organizations unique ID (OUI) and is allocated by the IEEE to
the organization. The rest of the 40 bits is assigned randomly.
Here the organizations ID is the ID of the authors University and
is 0x00-0c-21.
<--24--> <---- 40 bits ----->
+-------+-------------------+
| OUI | Random assignment |
+-------+-------------------+
Figure 8
The LIN6 prefix is a predefined constant value that is attached to
the head of the LIN6 ID to form the LIN6 generalized ID.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 19]
Internet-Draft Multi6 Protocol Comparison October 2004
The LIN6 generalized ID is used to identify the hosts ONLY in the
transport layer. This ID is NOT used in the IP layer. These
LING6 generated ID are used to make SA among the hosts and for
IPsec. Therefore from the ULP and the transport layer point of
view, all data exchange are identified using the LIN6 generated
IDs.
<-------- 64 bits --------> <-------- 64 bits ------->
LIN6 +---------------------------+--------------------------+
generalized | LIN6 prefix (constant) | LIN6-ID |
ID +---------------------------+--------------------------+
Figure 9
The LIN6 address is used in the network layer and contains the
network prefix. The network identifies the network (locator).
The LIN6 address is formed by combining the network prefix and the
LIN6 ID.
+---------------------------+--------------------------+
| network prefix | LIN6-ID |
+---------------------------+--------------------------+
Figure 10
6.2 LIN6 Protocol Overview
Nagarajan & Tschofenig Expires April 18, 2005 [Page 20]
Internet-Draft Multi6 Protocol Comparison October 2004
+------------------+
| Mobile Agent (A) |
| |<---------------+
+------------------+ |
^ |
|4.Get N/W prefix(B) |
| from MA(B),create |
| IP(B) |1.Network prefix
| | Registration
| |
| |
|3.Create LIN6(B), |
| IP of MA(B) |
2.N/W prefix | |
of MA(B), | | 6.N/W prefix
+--------+ LIN6 ID(B) v 5.send pkt | of MA(A) +---------+
|Name | +------+ -----------> +------+ |Name |
|server |<---------->|Node A| <---------- |Node B| <-------> |server |
+--------+ +------+ 8.send pkt +------+ +---------+
| |
| |
| |
| |
| | 7.Get N/W prefix(A)
|1.Network prefix | from MA(A)
| Registration |
| |
| v
| +------------------+
| | Mobile Agent (B) |
+-------------->| |
+------------------+
Figure 11
6.3 LIN6 Security Considerations
The security issues of the LIN6 proposal are very similar to that of
the Mobile IPv6. This is because LIN6 also makes use of mobile
agents and requires binding updates. Assuming that there exists
proper authorization of the Binding Updates used by mobile agents
(which is still an open issue in the LIN6 proposal), we look at the
other security issues.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 21]
Internet-Draft Multi6 Protocol Comparison October 2004
1. PREMEDIATED REDIRECTION
When node A wishes to communicate with node B, it sends a
packet to B (after looking up the AAAA records and the MA-B
for B's network prefix). For B to send a packet back to A, I
has to obtain the network prefix of host A from MA-A. Host B
first obtains the FQDN of host A from the name server by
indicating the LIN6 ID of Node-A, and then obtains the MA-A:s
network prefix from the name server by indicating the FQDN of
Node-A. Finally, it obtains the network prefix of A from the
MA-A. Assuming that the DNS records are authentic, it would
not be possible of a malicious host X to spoof as A and
initiate a communication with B. AAAA records will indeed
show up that X is not A.
2. REDIRECTING THE PACKETS
LIN6 proposes three different solutions to support
multihoming. Two of these solutions make use of authenticated
header mechanism for registering the new IP with the mobile
agent. The third proposal makes use of cookies in addition to
the authentication headers. All of the proposals make sure
that redirection of packets to a third party locator is not
possible as long as the mobile agents can be trusted.
Assuming that the binding updates are secure and redirection
is not possible at the time of locator updates, there are
still possibilities for redirection at the time of DNS look
ups. The interface between the correspondent node and the DNS
server is very important because security of LIN6 is dependent
on the DNS request and response messages. The initial DNS
request by a correspondent node returns the address of the
Mapping Agent of the initiator. If this message is modified,
the correspondent node can be forced to learn the wrong
address of the Mapping Agent. A malicious node could easily
take advantage of this to perform a redirection a redirection
attack. It is also crucial in LIN6 that the DNS holds only
authentic AAAA records and are in the secure zone.
3. PACKET INJECTION
Packet injection is possible at the time of data exchange and
location updates. The binding update security is still TBD in
the LIN6 proposal. Assuming that binding updates always take
place using security associations (in the case of the first
proposal for mobility in LIN6), packet injection would be
difficult.
LIN6 also supports IPsec for data exchange. If IPsec is used
in connection establishment and payload protection, then it
Nagarajan & Tschofenig Expires April 18, 2005 [Page 22]
Internet-Draft Multi6 Protocol Comparison October 2004
would not be possible to inject packets or disrupt the flow of
the data stream. However, this could have extra overheads of
the IPsec like key generation and exchange.
It should also be noted that packet injection is possible at
the time of DNS request and reply. Since this problem is
generic to all redirection attacks, it is not a special
concern for packet injection problem.
4. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS
Any protocol that uses signature verifications could be
subjected to resource exhaustion attacks as these
verifications are often expensive for a host. When one of the
nodes in a LIN6 protocol is mobile, it has to inform the
mobile agent (MA) and/or the corresponding node (CN) about its
new location. The corresponding node can start using the new
locator ONLY after the new network prefix has been verified
for impersonation. Attackers can take advantage of such a
situation to send forged location updates to the corresponding
node. Its should be noted that LIN6 also makes proposals that
are based on SA between the Mobile Node and the Correspondent
Node for authenticating binding updates.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 23]
Internet-Draft Multi6 Protocol Comparison October 2004
7. Host Identity Protocol
The HIP proposal [9]is an ID/Locator separation mechanism intended to
solve a much wider problem space than site multi-homing. HIP uses
cryptographic identifiers termed Host Identity Tags (HITs) at the
application layer, which are mapped to locators (IP Addresses) by a
HIP protocol stack layer that interfaces between the transport layer
and network layer. The essential characteristic of HIP is it use of
opportunistic identity generation, as it uses a cryptographic host
identifier as the basis of the persistent identity. The transport
session can be agile across locators, or even across IP protocol
versions, as the HIT is used to determine session integrity allowing
the hosts to determine what packets legitimately form part of the
session.
HIP is proposed as a new protocol element, located at layer 3.5 (i.e.
above the internetwork IP layer and below the transport layer). The
presentation to the transport layer uses 128 bit hash values (the
HIT) in place of IP addresses, while the presentation to the internet
layer uses conventional IP addresses.
7.1 Notational Conventions
I is the initiating host and R is the responding host. X is a
potentially malicious host.
FQDN (R) is a fully qualified domain name of R and this is used to
uniquely identify R.
HI (R) is the Host Identifier of R. A host identifier is
cryptographic in nature and is the public key of an asymmetric
key-pair. Correspondingly, the host itself is the entity that
holds the private key of the key pair.
The Host Identity Tag or HIT is a 128 bit hash value of the Host
Identifier. Its fixed length makes for easier protocol coding and
presents and consistent format.
D-H key is the Diffie-Hellmann key used by a host to create a
session key (SK). The resultant session key is used to generate
the keying material or the KEYMAT to derive all the other keys for
integrity checks and encryption.
7.2 HIP Protocol Overview
Nagarajan & Tschofenig Expires April 18, 2005 [Page 24]
Internet-Draft Multi6 Protocol Comparison October 2004
Initiator Responder
I1: trigger exchange
-------------------------->
select pre-computed R1
R1: puzzle, D-H, key, sig
<-------------------------
check sig remain stateless
solve puzzle
I2: solution, D-H, {key}, sig
-------------------------->
compute D-H check cookie
check puzzle
check sig
R2: sig
<--------------------------
check sig compute D-H
Figure 12: HIP protocol(context establishment)
7.3 HIP Security Considerations
HIP is designed to provide secure authentication of hosts and to
provide a fast key exchange for IPsec ESP. HIP also attempts to
limit the exposure of the host to various denial-of-service and
man-in-the-middle attacks. This is achieved through security
associations and PK signature verifications.
In order to prevent redirection attacks during locator updates, the
CB64 protocol relies on the ability to verify that the entity
requesting redirection indeed holds the private key where the hash of
the corresponding public key hashes to the ID itself.
1. PREMEDIATED REDIRECTION
Premediated redirection is not possible in HIP because, HIP
tries to authenticate the initiator using PK signatures at the
time of base exchange itself. When an attacker X pretending
to be an initiator I, sends a spoofed trigger exchange message
to the host R, R creates a puzzle and generates a
Diffie-Hellmann key for the session and sends it back to the
attacker. The attacker needs to solve the puzzle, encrypt his
host identity (which is the public authentication key of A)
and then sign it (with the private key of X). The responder
decrypts the encrypted host identity and uses it to verify the
Nagarajan & Tschofenig Expires April 18, 2005 [Page 25]
Internet-Draft Multi6 Protocol Comparison October 2004
signature. The private key of the attacker and the public key
of A would not make a key pair for signature verification.
Authentication fails and the receiver stops the 3-way base
exchange. Since the Host Identity of a host is the public
authentication key, it is important that these are retrieved
from a signed DNS zone, a certificate or some secure methods.
2. REDIRECTING THE PACKETS
HIP proposes some ways to handle locator changes. One of them
is to use the readdressing parameter REA and the other is to
have Rendezvous Servers for efficient multihoming and
mobility.
The former method tries to make a new security association
with the hosts every time a mobile node changes its location
on the network. Since no other host, even those in the path
between the initiator and the receiver cannot know the session
keys (exchanged using Diffie-Hellmann key exchange protocol)
for the new security associations, it is impossible for a
middle man to issue false locator updates to one of the host
and redirect the packets.
The later method uses rendezvous servers which maintain a
mapping between the Host Identities of HIP nodes for which
they provide service and the node's current IP addresses. HIP
nodes must notify their Rendezvous Servers about any changes
in their IP addresses. It is important that the HIP mobile
nodes be authenticated before they update their new IP in
their respective Rendezvous Servers. Assuming so, it would be
difficult for a malicious host to make false location updates
on Rendezvous Servers that do not belong to it. Therefore
false location updates are difficult, making all kinds of
redirection attacks also difficult.
3. PACKET INJECTION
Since HIP makes use of IPsec ESP in order to secure all the
packets, packets that are injected would either be unencrypted
or would belong to irrelevant security associations. Such
packets could be ignored and this would not affect the regular
stream of data flow in HIP.
4. RESOURCE EXHAUSTION DENIAL OF SERVICE ATTACKS
Denial-of-service attacks take advantage of the cost of start
of state for a protocol on the Responder compared to the
cheapness on the Initiator. HIP makes no attempt to increase
the cost of the start of state on the Initiator, but makes an
effort to reduce the cost to the Responder. This is done by
Nagarajan & Tschofenig Expires April 18, 2005 [Page 26]
Internet-Draft Multi6 Protocol Comparison October 2004
having the Responder start the 3-way cookie exchange instead
of the initiator by sending a puzzle.
This shifting of the start of state cost to the Initiator in
creating the I2 HIP packet, presents yet another DoS attack.
The attacker spoofs the I1 HIP packet and sends out the R1 HIP
packet. This could tie up the initiator with evaluating the
R1 HIP packet and creating the I2 HIP packet. The defense
against this attack is to simply ignore any R1 packet where a
corresponding I1 or ESP data was not sent.
Message R2 also includes signature verification. However, the
responder verifies the signature ONLY if it receives the
correct solution for the puzzle it sent out. For an attacker
to force the receiver with signature verifications with I2
message, it needs to find the correct solution of the puzzle
that was sent out. This would be the price that he would pay
for one signature verification attack on the receiver.
Denial of service attack with R2 message is avoided by
including a HMAC value in the R2 message. The initiator would
verify the signature ONLY if the HMAC value of the message is
first verified. It would be impossible for an attacker to
compute the correct HMAC as this requires the integrity key
that the communicating hosts generated with the session key.
For rendezvous mechanisms for mobility management, the
security considerations are yet to be determined. It is
assumed that all requests and replies to and from the DNS are
secure and that DNS holds only authentic records in a secure
zone.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 27]
Internet-Draft Multi6 Protocol Comparison October 2004
8. Other Security Considerations
Replay attacks - The SIM, NOID and the CB64 proposals make use of
nonce and timestamp in the context establishment messages and
readdressing messages. This makes replay attacks difficult. This
is especially significant for SIM and CB64 proposals that involve
PK signature verifications for authentication. In the other
proposals like Lin6 and WIMP, replay attacks do not gain anything
significant for the attacker. In the HIP proposal, however,
replay attacks are avoided by using the cookie mechanism to
generate the puzzle. This mechanism makes use of a nonce to
calculate the index for the puzzle.
Protecting the context establishment itself - One big draw back of
all the proposals except the HIP is that they do not make any
attempt to protect the initial context establishment mechanism.
For instance, the WIMP proposal assumes that the initial two
messages need to be exchanged between authentic nodes. If the
initial messages itself are protected, nodes in the path will not
be able to create the same hash chain and use them for man in the
middle attacks. In the other proposals like SIM, NOID and CB64
protecting the context establishment could protect the Context Tag
or Flow ID as they are important for rewriting the locator values
back to the identifier values. Otherwise, the CTs and FlowIDs are
open to attacks.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 28]
Internet-Draft Multi6 Protocol Comparison October 2004
9. Comparison of Multi6 Proposals
The following table shows various attacks and relates them to the
individual proposals. The symbol 'x' indicates that the attack is
applicable to the respective protocol proposal.
+---------------+-------+-------+-------+-------+-------+-------+
| | SIM | NOID | CB64 | WIMP | LIN6 | HIP |
+---------------+-------+-------+-------+-------+-------+-------+
|Premediated | | | | | | |
|redirection | x | | x | x | | |
|attacks | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
|Redirecting | | | | | | |
|packets to the | | | | | x | |
|attacker | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
|Redirecting | | | | | | |
|packets to a | | | | | x | |
|third party | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
|Redirecting | | | | | | |
|packets to a | | | | | x | |
|black hole | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
|Packet | | | | | |
|injection | x | x | x | x | | |
| | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
|Resource | | | | | | |
|exhaustion DoS | x | x | x | | x | |
|attacks | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
Figure 13
Nagarajan & Tschofenig Expires April 18, 2005 [Page 29]
Internet-Draft Multi6 Protocol Comparison October 2004
10. Security Considerations
This document discusses security issues of Multi6 locator/identifier
split protocol proposals. As such, it contains a number of security
issues.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 30]
Internet-Draft Multi6 Protocol Comparison October 2004
11. References
11.1 Normative References
11.2 Informative References
[1] Nordmark, E., "Strong Identity Multihoming using 128 bit
Identifiers (SIM/CBID128) for use in RFCs to Indicate
Requirement Levels", draft-nordmark-multi6-sim-01.txt (work in
progress), October 2003.
[2] Nordmark, E., "Multihoming without IP Identifiers",
draft-nordmark-multi6-noid-01.txt (work in progress), October
2003.
[3] Nordmark, E., "Multihoming using 64-bit Crypto-based IDs",
draft-nordmark-multi6-cb64-00.txt (work in progress), October
2003.
[4] Teraoka, F., Ishiyama, M. and M. Kunishi, "LIN6: A Solution to
Multihoming and Mobility in IPv6",
draft-teraoka-multi6-lin6-00.txt (work in progress), December
2003.
[5] Ylitalo, J., Torvinen, V. and E. Nordmark, "Weak Identifier
Multihoming Protocol (WIMP)", draft-ylitalo-multi6-wimp-00
(work in progress), January 2004.
[6] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
solutions", draft-nordmark-multi6-threats-01.txt (work in
progress), June 2004.
[7] Huston, G., "Architectural Approaches to Multi-Homing for
IPv6", draft-huston-multi6-architectures-00.txt (work in
progress), May 2004.
[8] Crocker, D., "Choices for Multiaddressing",
draft-crocker-multiaddr-analysis-01.txt (work in progress),
October 2003.
[9] Moskowitz, R., Nikander, P., Jokela, P. and T. Henderson, "Host
Identity Protocol", draft-moskowitz-hip-09.txt (work in
progress), February 2004.
[10] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-moskowitz-hip-arch-05 (work in progress),
September 2003.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 31]
Internet-Draft Multi6 Protocol Comparison October 2004
[11] Eggert, L., "Host Identity Protocol (HIP) Rendezvous
Mechanisms", draft-eggert-hip-rendezvous-00.txt (work in
progress), February 2004.
[12] Nikander, P. and J. Arkko, "End-Host Mobility and Multi-Homing
with Host Identity Protocol", draft-nikander-hip-mm-01.txt
(work in progress), December 2003.
Authors' Addresses
Aarthi Nagarajan
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: aarthi.nagarajan@tuhh.de
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Nagarajan & Tschofenig Expires April 18, 2005 [Page 32]
Internet-Draft Multi6 Protocol Comparison October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nagarajan & Tschofenig Expires April 18, 2005 [Page 33]