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]