[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
                                                              J. Ylitalo
Internet-Draft                                               V. Torvinen
Expires: July 28, 2004                      Ericsson Research Nomadiclab
                                                             E. Nordmark
                                                  Sun Microsystems, Inc.
                                                        January 28, 2004


              Weak Identifier Multihoming Protocol (WIMP)
                      draft-ylitalo-multi6-wimp-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 July 28, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This draft defines a Weak Identifier Multihoming Protocol (WIMP) for
   IPv6 hosts. WIMP 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. WIMP
   is based on opportunistic security principles, and it does not
   require any pre-configured security infrastructure. The protocol
   consists of context establishment and re-addressing exchanges.  The
   context establishment exchange creates a state for both hosts.  The
   re-addressing exchange is used to update locator information at the



Ylitalo, et al.          Expires July 28, 2004                  [Page 1]


Internet-Draft                    WIMP                      January 2004


   peer host. Used cryptographic operations are light and efficient.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Requirements language  . . . . . . . . . . . . . . . . . . .  4
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1   Cryptographic techniques . . . . . . . . . . . . . . . . . .  5
   2.1.1 Reverse hash chain . . . . . . . . . . . . . . . . . . . . .  5
   2.1.2 Reverse hash chain and message authentication  . . . . . . .  6
   2.1.3 Chained bootstrapping  . . . . . . . . . . . . . . . . . . .  7
   2.1.4 Secret splitting . . . . . . . . . . . . . . . . . . . . . .  7
   2.2   Notational Conventions . . . . . . . . . . . . . . . . . . .  8
   3.    Protocol overview  . . . . . . . . . . . . . . . . . . . . . 10
   3.1   WIMP layer . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.2   Host-Pair Context  . . . . . . . . . . . . . . . . . . . . . 11
   3.3   Generating reverse hash chains . . . . . . . . . . . . . . . 12
   3.4   Context establishment exchange . . . . . . . . . . . . . . . 13
   3.5   Re-addressing exchange . . . . . . . . . . . . . . . . . . . 14
   4.    Packet processing  . . . . . . . . . . . . . . . . . . . . . 17
   4.1   Processing outgoing application data . . . . . . . . . . . . 17
   4.2   Processing incoming application data . . . . . . . . . . . . 18
   5.    Packets  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   5.1   INIT - the context initiator packet  . . . . . . . . . . . . 19
   5.2   CC - the context check packet  . . . . . . . . . . . . . . . 20
   5.3   CCR - the context check reply packet . . . . . . . . . . . . 20
   5.4   CONF - the context confirm packet  . . . . . . . . . . . . . 21
   5.5   RESYNCH - the re-synchronization packet  . . . . . . . . . . 21
   5.6   REA - The re-addressing packet . . . . . . . . . . . . . . . 22
   5.7   AC - The address check packet  . . . . . . . . . . . . . . . 22
   5.8   ACR - The address check reply packet . . . . . . . . . . . . 23
   6.    Message formats  . . . . . . . . . . . . . . . . . . . . . . 24
   6.1   Payload format . . . . . . . . . . . . . . . . . . . . . . . 24
   6.1.1 WIMP Controls  . . . . . . . . . . . . . . . . . . . . . . . 25
   6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   6.2   Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 25
   6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . . 26
   6.3   HASH-INIT  . . . . . . . . . . . . . . . . . . . . . . . . . 28
   6.4   HASH-CC  . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   6.5   HASH-REA . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   6.6   ANCHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   6.7   HASHVAL  . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   6.8   HASHKEY  . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   6.9   FLOWID . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   6.10  CHALLENGE  . . . . . . . . . . . . . . . . . . . . . . . . . 32
   6.11  LSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   6.12  KEY  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
   7.    State Machine  . . . . . . . . . . . . . . . . . . . . . . . 36



Ylitalo, et al.          Expires July 28, 2004                  [Page 2]


Internet-Draft                    WIMP                      January 2004


   7.1   States . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
   7.2   State Processes  . . . . . . . . . . . . . . . . . . . . . . 36
   7.3   State Loss . . . . . . . . . . . . . . . . . . . . . . . . . 38
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 40
   8.1   Context establishment exchange . . . . . . . . . . . . . . . 40
   8.1.1 Man-in-the-Middle attacks  . . . . . . . . . . . . . . . . . 40
   8.1.2 Denial-of-Service attacks  . . . . . . . . . . . . . . . . . 40
   8.2   Re-addressing exchange . . . . . . . . . . . . . . . . . . . 41
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 42
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 43
         Normative references . . . . . . . . . . . . . . . . . . . . 44
         Informative references . . . . . . . . . . . . . . . . . . . 45
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
   A.    Example of secure reverse hash chain generation  . . . . . . 46
   B.    Goals for IPv6 Site-Multihoming Architectures  . . . . . . . 47
   B.1   Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 47
   B.2   Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 47
   B.3   Performance  . . . . . . . . . . . . . . . . . . . . . . . . 47
   B.4   Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
   B.5   Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 48
   B.6   Transport-Layer Survivability  . . . . . . . . . . . . . . . 48
   B.7   Impact on DNS  . . . . . . . . . . . . . . . . . . . . . . . 48
   B.8   Packet Filtering . . . . . . . . . . . . . . . . . . . . . . 48
   B.9   Scalability  . . . . . . . . . . . . . . . . . . . . . . . . 48
   B.10  Impact on Routers  . . . . . . . . . . . . . . . . . . . . . 48
   B.11  Impact on Hosts  . . . . . . . . . . . . . . . . . . . . . . 48
   B.12  Interaction between Hosts and the Routing System . . . . . . 48
   B.13  Operations and Management  . . . . . . . . . . . . . . . . . 49
   B.14  Cooperation between Transit Providers  . . . . . . . . . . . 49
   B.15  Security compared to IPv4 multihoming  . . . . . . . . . . . 49
   C.    Things MULTI6 Developers should think about  . . . . . . . . 50
   C.1   Routing  . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   C.2   Identifiers and locators . . . . . . . . . . . . . . . . . . 50
   C.3   On The Wire  . . . . . . . . . . . . . . . . . . . . . . . . 50
   C.4   Names, Hosts, Endpoints, or none of the above? . . . . . . . 51
         Intellectual Property and Copyright Statements . . . . . . . 53















Ylitalo, et al.          Expires July 28, 2004                  [Page 3]


Internet-Draft                    WIMP                      January 2004


1. Introduction

   The goal of the IPv6 multihoming work is to allow a site to take
   advantage of multiple attachments to the global Internet without
   having a specific entry for the site visible in the global routing
   table. Specifically, a solution should allow users to use multiple
   attachments in parallel, or to switch between these attachment points
   dynamically without an impact on the upper layer protocols.

   This draft defines a Weak Identifier Multihoming Protocol (WIMP) for
   IPv6 hosts. WIMP uses reverse hash chains and secret splitting to
   perform enough validation to prevent redirection attacks.

   The goals for WIMP are:

      o Have no impact on upper layer protocols in general and on
      transport protocols in particular.

      o Address the security threats in [6].

      o Allow routers rewriting the (source) locators as a means of
      quickly detecting which locator is likely to work for return
      traffic.

      o Minimal per-packet overhead.

      o No extra round trip for setup through optional piggy-backing.

      o Take advantage of multiple locators for load spreading.


1.1 Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [1].















Ylitalo, et al.          Expires July 28, 2004                  [Page 4]


Internet-Draft                    WIMP                      January 2004


2. Terminology

   Upper Layer Protocol (ULP)

      A protocol layer immediately above IP. Examples are transport
      protocols such as TCP and UDP, control protocols such as ICMP,
      routing protocols such as OSPF, and internet or lower-layer
      protocols being "tunneled" over (i.e., encapsulated in) IP such as
      IPX, AppleTalk, or IP itself.

   Interface

      A node's attachment to a link.

   Locator

      An IP layer topological name for an interface. The 128 bit
      locators are carried in the IP address fields as the packets
      traverse the network.

   Identifier

      An IP layer identifier for an IP layer endpoint (stack name in
      [7]). The transport endpoint is a function of the transport
      protocol and would typically include the IP identifier plus a port
      number.

   Address field

      The source and destination address fields in the IPv6 header.
      This draft separates identifiers from locators, and therefore
      these fields contain locators.

   FQDN

      Fully Qualified Domain Name


2.1 Cryptographic techniques

2.1.1 Reverse hash chain

   Reverse hash chain is cryptographically generated list of data
   entities with some interesting characteristics. It is practically
   impossible to calculate or otherwise figure out the next value in the
   chain even when you know the previous value.  However, it is very
   easy to verify whether some given value is the next value or not.




Ylitalo, et al.          Expires July 28, 2004                  [Page 5]


Internet-Draft                    WIMP                      January 2004


   The chain is created by recursively computing a hash function over a
   result of the same function. The initial argument for the first hash
   value computation is typically a large random number. The last
   generated value of the chain is called as the "anchor" or "root"
   value. The hash values are revealed in the reverse order starting
   from the anchor value.

   Hn = Hash(challenge)
   Hn-1 = Hash(Hn)
   ...
   H0 = anchor = Hash(H1)

   CHAIN:  H0,..,Hn

   This technique is usually applied based on an assumption that only an
   authentic end-point knows the correct successor values of the chain.
   In the bootstrapping process, the end-point computes a new hash chain
   and reveals the anchor value of the chain to its peer.

   Each hash chain can be used only once.

2.1.2 Reverse hash chain and message authentication

   Hashed message authentication codes (HMAC; RFC2104) are typically
   used to authenticate messages with a symmetric key. This requires,
   naturally, that all communicating peers share a secret.

   Example: HMAC(key, Message).

   Reverse hash chain values can be used as keys in the message
   authentication.  This is different from the shared secret scheme
   because anybody who is able to receive the subsequent messages is
   able to verify that the messages belong together.  The reverse hash
   chain value (key) used in message authentication is not revealed
   before the next message. In other words, the peer is able verify the
   message only after it has received the next message. This procedure
   can be used to verify that all subsequent messages come from the same
   entity than the first message. In other words, the hash chain binds
   the messages together.

   A Man-in-the-Middle (MitM) attacker is not able to (unnoticeably)
   modify the messages after the first message in the exchange. However,
   an attacker may spoof the first message and use own hash chain.  The
   protocol is based on opportunistic principle where the first message
   must be sent by an authentic node. The last message should contain
   only the last hash value, Hn.





Ylitalo, et al.          Expires July 28, 2004                  [Page 6]


Internet-Draft                    WIMP                      January 2004


   Message_1: Message, HMAC(H1, Message)
   Message_2: Message, H1, HMAC(H2, Message)
   Message_3: Message, H2, HMAC(H3, Message)
   ...
   Message_n: Message, Hn-1, HMAC(Hn, Message)
   Message_n+1: Hn


2.1.3 Chained bootstrapping

   In the basic model, each reverse hash chain is an independent entity.
   This is not a problem if the anchor of the chain can be
   authenticated, and if the hash chain is known to be long enough to
   have values to every message in the communication session. However,
   it is possible to use short hash chains to avoid extra computation.

   Basically, the bootstrapping message can be authenticated using
   public keys. In the opportunistic mode, the peers do not authenticate
   the bootstrapping message with signatures, but rely that all
   subsequent messages are coming from the same peer. Two independently
   created reverse hash chains can be linked together with a Hash
   computation. The last value of the first reverse hash chain is used
   to authenticate the first value of the second chain:

   ...
   Message_n: Message, H1_new, Hn-1, HMAC(Hn, Message)
   Message_n+1: Message, Hn, HMAC(H2_new, Message)
   Message_n+2: Message, H2_new, HMAC(H3_new, Message)
   ...


2.1.4 Secret splitting

   In secret splitting, the secret is divided into several pieces.  Any
   piece alone does not give enough information for an attacker to
   create the original secret. The only way to create the secret is to
   posses all the pieces of the key.

   The simplest scheme splits a secret into two pieces. The splitting is
   done by generating a random-bit string, the same length as the
   secret, that will represent one piece of the split. The secret is
   then XORed with the random string to generate the other piece.
   Essentially, the secret is encrypted with a one-time pad. The pieces
   are the encrypted message, and the pad.







Ylitalo, et al.          Expires July 28, 2004                  [Page 7]


Internet-Draft                    WIMP                      January 2004


   Example:

   secret XOR random_string = encrypted_message

   secret_piece_1 = random_string
   secret_piece_2 = encrypted_message


   The original secret can be reconstructed by XORing the pieces
   together. However, each piece alone can not be used to reconstruct
   the secret, not even with the highest possible computing power. One
   secret can very easily be divided into more than two pieces. What is
   needed is just more random-bit strings that are XORed into the
   secret.

   Secret splitting is useful technique for storing secrets in two
   physical places, or for sending a secret to the other end-point using
   two or more parallel communication paths.

2.2 Notational Conventions

      - I is an initiating host, i.e. an initiator.

      - R is a responding host, i.e. a responder.

      - ID(I) is an identifier for I.

      - 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),
      ... 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(I) is a tag for the host-pair context at the
      initiator.

      - F(R) is a flowid assigned by the responder and used by the
      initiator.

      - Hk(I) is k:th hash value in a initiator's reverse hash chain.
      The 'H0(I)' is the first revealed value, i.e. the "anchor" of the
      reverse hash chain. Note that the parameter k defines the
      revealing order, not the computation order.



Ylitalo, et al.          Expires July 28, 2004                  [Page 8]


Internet-Draft                    WIMP                      January 2004


      - Hk(R) is k:th hash value in a responder's reverse hash chain.


















































Ylitalo, et al.          Expires July 28, 2004                  [Page 9]


Internet-Draft                    WIMP                      January 2004


3. Protocol overview

   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 can be divided into two
   exchanges: context establishment and re-addressing exchange.  The
   former exchange establishes a state for both communication
   end-points.  The re-addressing exchange is used to update the
   locators belonging to the communicating parties.  WIMP layer hides
   multiple addresses from the upper layer protocols.

3.1 WIMP layer

   WIMP layer is located between IP and the ULPs, as shown in figure 1,
   in order to provide ULP independence. Conceptually the WIMP layer
   behaves as if it is an extension header, which would be ordered
   immediately after any hop-by-hop options in the packet.

   +-----------------------------------+
   |        Transport Protocols        |
   +-----------------------------------+
   | AH | ESP | Frag/reass | Dest opts |
   +-----------------------------------+
   |            WIMP layer             |
   +-----------------------------------+
   |               IP                  |
   ------------------------------------+

   Figure 1: Protocol stack

   All protocols above WIMP layer use 128 bit identifiers (IDs).  The
   IDs are non-routable by their nature and never used in the IPv6
   header in the network. An ID consists of an initial 2 bit prefix of
   01, followed by 126 bits suffix that is a hash.  The suffix in the
   initiator's identifier, ID(I), is a hash of a nonce. The suffix in
   the responder's identifier, ID(R), is constructed taking a hash of
   the responder's FQDN(R).

   Applications and upper layer protocols use IDs which the WIMP layer
   will map to/from locators (see figure 2).  The WIMP layer maintains
   state, called host-pair context, in order to perform this mapping.
   The mapping is performed consistently at the initiator and the
   responder, thus from the perspective of the upper layer protocols
   packets appear to be sent using IDs from end to end, even though the
   packets travel through the network containing locators in the IP
   address fields, and even though those locators might be rewritten in
   flight. The result of this consistent mapping is that there is no



Ylitalo, et al.          Expires July 28, 2004                 [Page 10]


Internet-Draft                    WIMP                      January 2004


   impact on the ULPs. In particular, there is no impact on
   pseudo-header checksums and connection identification.

         ----------------------           ----------------------
         | Initiator          |           | Responder          |
         |                    |           |                    |
         |      ULP           |           |      ULP           |
         |       | src ID(I)  |           |       ^            |
         |       | dst ID(R)  |           |       | src ID(I)  |
         |       v            |           |       | dst ID(R)  |
         |      WIMP          |           |      WIMP          |
         |       | src L1(I)  |           |       ^            |
         |       | dst L1(R)  |           |       | src L1(I)  |
         |       v            |           |       | dst L1(R)  |
         |       IP           |           |       IP           |
         ----------------------           ----------------------
                 |                                ^
                 -- cloud with some routers -------

   Figure 2: Mapping identifiers to locators.

   Layering AH and ESP above the WIMP means that IPsec can be made to be
   unaware of locator changes the same way that transport protocols can
   be unaware.  Thus the IPsec security associations remain stable even
   though the locators are changing.  Layering the fragmentation header
   above the WIMP makes reassembly robust in the case that there is
   broken multi-path routing which results in using different paths,
   hence potentially different source locators, for different fragments.

3.2 Host-Pair Context

   The initiator creates a host-pair context based on IDs and the
   locator set learned from the DNS. The responder establishes a state
   after receiving the second message from the initiator.

   The context state contains the following information:

      - Context identifiers (e.g. identities and flow id's)

      - Locator and locator status (e.g. if locator has been verified,
      and which locators are preferred for communication)

      - Hash chain information (e.g. parameters needed in the
      construction of hash chains, last used local chains values, and
      last known peer chain values)

   Every IP packet must contain information about the related host-pair
   context. Basically, every packet could contain an extra extension



Ylitalo, et al.          Expires July 28, 2004                 [Page 11]


Internet-Draft                    WIMP                      January 2004


   header including the IDs. However, that would add extra overhead to
   the packets. Instead, we use flowid field in the IPv6 header to
   represent the host-pair context.  Conceptually one could view the
   approach as if both IDs being present in every packet, but with a
   header compression mechanism applied that removes the need for the
   IDs once the state has been established.  The flowid serves as a
   convenient "compression tag" without increasing the packet size.

   Flowids are used in regular IPv6 packets to find the right context
   for received packets. Each host selects for itself the flowid it
   wants to see in packets received from its peer.  This allows it to
   select different flowids for different peers.

   The problem related to flowid selection is identical with the IPSEC
   SPI selection. A host cannot select a flowid for IP packets going to
   its peer. Otherwise, two different hosts might select the same flowid
   and the peer could not uniquely identify the correct host-pair
   context using the received flowid.

   Selected flowid is communicated to the peer in the third (CCR) and
   fourth (CONF) packets of the context creation exchange.

3.3 Generating reverse hash chains

   In general, the way by which the reverse hash chains are generated is
   a local matter. The hash chains are needed by the initiator and the
   responder during the context establishment exchange. Also, the
   initiator of the re-addressing exchange needs to construct a new hash
   chain.

   This document sets the following requirements for the hash chains
   generation:

      - Each reverse hash chain MUST be unique for each host-pair
      context establishment and re-addressing exchange.

      - The responder MUST be able to reconstruct the same reverse hash
      chain based on the parameters that are present in the context
      check reply message (CCR) in order to be stateless at the
      beginning of context establishment exchange.

      - The responder MUST be able to reconstruct the same reverse hash
      chain based on the parameters that are present in the context
      check reply message (CCR) even if the system boots.

      - The initial argument of the hash chain is never revealed to
      other parties.




Ylitalo, et al.          Expires July 28, 2004                 [Page 12]


Internet-Draft                    WIMP                      January 2004


      - The length of the hash chain is implementation specific but must
      be the same every time a chain is constructed.

   Theoretically speaking, the minimum length of the hash chain is three
   (3) hash values.  This will last for one context establishment
   exchange, and one re-addressing exchange for both direction (note
   that re-addressing exchange includes a bootstrapping procedure where
   a new hash chain is created for the initiator). However, each
   unsuccessful re-addressing exchange attempt will require one more
   hash chain value. Failures in re-addressing exchange may be due to
   connection loss in some of the locators, or an active attack.

   Appendix A gives one example of secure hash chain generation.

3.4 Context establishment exchange

   The context establishment exchange serves to manage the establishment
   of state between an initiator and a responder. The procedure uses
   delayed authentication principle where initial message exchange are
   verified with the parameters included in the latter messages. The
   procedure is designed to be stateless for the responder side. At the
   end of the exchange both parties have a uniquely identifiable
   host-pair context containing the peer's anchor value.

       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




Ylitalo, et al.          Expires July 28, 2004                 [Page 13]


Internet-Draft                    WIMP                      January 2004


   The initiator first sends a context initiator message, INIT, to the
   responder. The INIT message contains the IDs, a challenge and a keyed
   hash. The hash, having the anchor value as a key, is computed over
   the IDs, challenge and flowid.  The flowid is sent later in the
   context check reply message (CCR).

   Once the responder receives the INIT message, it must check that it
   does not already have a host-pair context with the ID pair. If the
   context is not found, the responder continues with the negotiation.
   However, it does not want to establish a state because it is not able
   to verify the origin of the message.  In order to remain stateless,
   the responder computes a temporary hash chain using the initiator's
   challenge in the INIT packet, and sends a context check message (CC)
   to the initiator. The CC message is protected with the anchor value
   of responder hash chain.

   The initiator replies to the CC message with a context check reply
   message (CCR) and proves that it was reachable at the specific
   location by disclosing the anchor value. The CCR message includes the
   flowid that uniquely identifies the host pair context to the
   initiator.

   Again, the responder does not accept CCR packets with an ID pair that
   already has a host pair-context. If the context is not found, the
   responder recomputes its own hash chain and verifies the keyed hashes
   (HMAC_INIT and HMAC_CC). The anchor value of the initiator hash chain
   binds the INIT and CCR messages together, and in this way the
   responder is able to verify that messages are coming from the same
   host. If the keyed hashes were valid, the responder names the host
   pair context by generating a flowid for it, and replies with a
   context confirmation message (CONF) revealing its anchor value.

   The initiator verifies the keyed hash in the CC message with the
   anchor value received in the CONF message, and finalizes its state.

   The context establishment exchange has been designed in the way that
   it can be reused for secure resynchronisation. If the initiator
   receives a RESYNC message, it SHOULD start a new handshake with the
   INIT message by including the latest disclosed responder's hash chain
   value. In this way, the initiator can be sure that the RESYNC message
   really originated from the responder, and not from an attacker. In
   this case, the responder discloses the successor hash chain value in
   the CONF message, instead of the anchor value.

3.5 Re-addressing exchange

   Once the state has been completed, both hosts have a host-pair
   context. At this point, the initiator has received the responder's



Ylitalo, et al.          Expires July 28, 2004                 [Page 14]


Internet-Draft                    WIMP                      January 2004


   locator set from the DNS. However, it is possible that the responder
   has published only one IP address in the DNS, but it is still able to
   multihome, and has several IP addresses. Basically, both hosts may
   send to their peers the locator sets. A host may verify the peer's
   addresses on demand basis or all at once.

        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
            ...   <-------------------------
            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

   The re-addressing exchange is a three way handshake. The
   re-addressing message (REA) has two purposes. First, it contains the
   initiator's locator set. Second, it bootstraps a new hash chain.

   Once the responder receives a REA message, it verifies that the hash
   chain value H1(I) belongs to the initiator (this example assumes that
   the previously revealed hash chain value was the anchor, H0).  In
   addition, the responder stores the initiator's new anchor value
   H0_new(I) and the new challenge value into the host-pair context.

   The responder divides its own next unused hash chain value into
   pieces using the secret splitting technique. The hash chain value is
   divided into as many parts as there were locators in the received
   locator set.  The responder defines a key mask for each of the key
   pieces (see Section 6.12).  The key mask will later allow the
   responder to check if all pieces found their way to the initiator. It
   is possible that the initiator is not reachable via all of the
   locators in the locator set.




Ylitalo, et al.          Expires July 28, 2004                 [Page 15]


Internet-Draft                    WIMP                      January 2004


   The responder sends one address check message (AC) per locator in the
   received locator set. Each AC message contains one piece of the hash
   chain value. The initiator must have a local policy on how long it
   waits for the upcoming AC messages.

   If the initiator receives all pieces of the hash chain value, it
   verifies that it is a successor value of the responder's hash chain.
   Otherwise, the initiator MAY stop the re-addressing exchange
   procedure. The initiator makes an OR operation with all of the
   received key masks and includes the result of the operation with the
   combined key to the address check reply message (ACR).

   The responder verifies the combined key using the key mask that
   indicates the key pieces that the initiator was able to receive. In
   addition, the responder uses the received initiator's hash chain
   value to authenticate the earlier received REA message. Finally, the
   responder marks the corresponding locators in the initiator's locator
   set as verified.

































Ylitalo, et al.          Expires July 28, 2004                 [Page 16]


Internet-Draft                    WIMP                      January 2004


4. Packet processing

   Each host is assumed to have a separate WIMP implementation that
   manages the host's host-pair context and handles requests for new
   ones. Each host-pair context is governed by a state machine, with
   states defined in Section 7.  WIMP implementation can simultaneously
   maintain host-pair contexts with more than one host. Furthermore,
   WIMP implementation may have more than one active host-pair context
   with another host; in this case, host-pair contexts are distinguished
   by their respective IDs and flowids.  It is not possible to have more
   than one host-pair contexts between any given pair of IDs.
   Consequently, the only way for two hosts to have more than one
   parallel associations is to use different IDs, at least in one end.

   The processing of packets depends on the state of the host-pair
   context(s) with respect to the originator of the packet.  A WIMP
   implementation determines whether it has an active association with
   the originator of the packet based on the IDs or the flowid of the
   packet.

4.1 Processing outgoing application data

   In an WIMP host, an application can send application level data using
   IDs as source and destination identifiers.  The IDs can be specified
   via a backwards compatible API. However, whenever there is such
   outgoing data, the stack has to send the resulting datagram using
   appropriate source and destination IP addresses.

   The following steps define the conceptual processing rules for
   outgoing datagrams destinated to a ID(R).

   1.  If the datagram has a specified source address, it MAY be a
       ID(I). If it is not, the implementation MAY replace the source
       address with a ID(I).  Otherwise it MUST send the packet using
       the given IP addresses and bypass the WIMP layer.

   2.  If the datagram has an unspecified source address, the
       implementation MUST choose a suitable source ID(I) for the
       datagram. In selecting a proper ID(I), the implementation MUST
       consult the table of currently active WIMP sessions, and
       preferably select a ID(I) that already has an active session with
       the target ID(R).

   3.  If there is no active WIMP session with the ID(R), one must be
       created by running the context establishment exchange.  The
       implementation MAY piggy-pack ULP payload to the exchange
       packets.




Ylitalo, et al.          Expires July 28, 2004                 [Page 17]


Internet-Draft                    WIMP                      January 2004


   4.  Once there is an active WIMP session for the given ID(R), the
       outgoing datagram does not contain WIMP headers.  Instead, the
       IDs are represented by flowids in the IP headers.

   5.  The IDs in the datagram are replaced with suitable IP addresses.
       The rules defined in [2] MAY be followed.


4.2 Processing incoming application data

   Incoming WIMP datagrams arrive as normal IP packets containing WIMP
   flowids. In the usual case the receiving host has a corresponding
   host-pair context, identified by the flowid in the packet.  However,
   if the host has crashed or otherwise lost its WIMP state, it may not
   have such a host-pair context.

   The following steps define the conceptual processing rules for
   incoming datagrams targeted to a WIMP host-pair context.

   1.  Detect the proper host-pair context, using the flowid.  If there
       are no host-pair context identified with the flowid, the host MAY
       reply with a RESYNC packet.  Sending such RESYNCs MUST be rate
       limited. However, if the receiver has an open socket
       corresponding the IP addresses in the IP header it MUST process
       the packet as standard IP datagram.

   2.  If a proper host-pair context is found, the packet is processed
       by WIMP. The IP addresses in the datagram are replaced with the
       IDs associated with the host-pair context.

   3.  The datagram is delivered to the upper layer.  Demultiplexing the
       datagram the right upper layer socket is based on the IDs.



















Ylitalo, et al.          Expires July 28, 2004                 [Page 18]


Internet-Draft                    WIMP                      January 2004


5. Packets

   There are eight basic WIMP packets.  Four are for the context
   establishment exchange, three are for re-addressing, and one is for
   state loss.

   Packets consist of the fixed header as described in Section 6.1,
   followed by the parameters.  The parameter part, in turn, consists of
   zero or more TLV coded parameters.

   Packet representation uses the following operations:

      ()      parameter
      []      optional parameter

   An upper layer payload MAY follow the WIMP header.  The payload proto
   field in the header indicates if there is additional data following
   the WIMP header.  The WIMP packet, however, MUST NOT be fragmented.
   This limits the size of the possible additional data in the packet.

5.1 INIT - the context initiator packet

   The WIMP header values for the INIT packet:

      Header:
        Packet Type = 1
        SRC ID = Initiator's ID
        DST ID = Responder's ID

      IP( WIMP ( CHALLENGE, HASH-INIT ))

   Valid control bits: P

   The INIT packet contains the fixed WIMP header, initiator's
   challenge, and HASH-INIT TLV (Section 6.3).

   If the INIT message is a response to a RESYNC packet the initiator
   SHOULD replace the challenge with the responder's old challenge. In
   this way, the initiator is able to verify later that the responder
   has really lost its state.

   The Initiator generates the Responder's identifier, ID(R), using the
   the Responder's FQDN.  If the Initiator does not know the Responder's
   FQDN, it MUST use IP addresses for the application identifiers in the
   socket API and by pass the WIMP protocol.






Ylitalo, et al.          Expires July 28, 2004                 [Page 19]


Internet-Draft                    WIMP                      January 2004


5.2 CC - the context check packet

   The WIMP header values for the CC packet:

      Header:
        Packet Type = 2
        SRC ID = Responder's ID
        DST ID = Initiator's ID

      IP ( WIMP ( HASH-INIT, HASH-CC ))

   Valid control bits: P

   The IDs MUST be the same received in INIT. (If the Responder has
   multiple IDs, the responder ID used MUST match Initiator's request.)

   The Responder copies the HASH-INIT TLV from INIT message to the CC
   message

   The Responder computes a temporary hash chain using the received
   initiator's challenge and IDs (see Section 3.3). The responder uses
   the generated anchor value of the temporary hash chain as a key for
   the HASH-CC computation Section 6.4). (Note: The responder does not
   store the temporary hash chain values.)

5.3 CCR - the context check reply packet

   The WIMP header values for the CCR packet:

      Header:
        Type = 3
        SRC ID = Initiator's ID
        DST ID = Responder's ID

      IP ( WIMP ( ANCHOR, FLOWID, CHALLENGE, [HASHVAL,] HASH-INIT, HASH-CC )

   Valid control bits: P

   The IDs used MUST match the ones used in the previous messages.

   If the initiator already has a host-pair context for the responder,
   but responder has lost its state, the initiator SHOULD sent the
   latest known responder's hash value, HASHVAL, and the old challenge,
   to the responder.

   The Initiator reveals the anchor value that was used in HASHKEY TLV
   in the HASH-INIT computation in the INIT message.




Ylitalo, et al.          Expires July 28, 2004                 [Page 20]


Internet-Draft                    WIMP                      January 2004


   Initiator copies the HASH-INIT, and HASH-CC TLVs from the CC message
   to the CCR message. In addition, CCR message includes the anchor,
   flowid, challenge, and responder's latest hash value.  .The Initiator
   selects a flowid that the responder uses to send packets to the
   Initiator (Section 3.2)

5.4 CONF - the context confirm packet

   The WIMP header values for the CONF packet:

      Header:
        Packet Type = 4
        SRC ID = Responder's ID
        DST ID = Initiator's ID

      IP ( WIMP ( ANCHOR, FLOWID ))


   Valid control bits: P

   The Responder reveals the anchor value that was used in HASHKEY TLV
   in the HASH-CC computation in the CC message.

   The Responder selects a flowid that the initiator uses to send
   packets to the Responder.

5.5 RESYNCH - the re-synchronization packet

   The WIMP header values for the RESYNC packet:

      Header:
        Packet Type = 5
        SRC ID = Responder's ID
        DST ID = (zero)

      IP ( WIMP ( FLOWID ))


   Valid control bits: -

   Once a responder receives an IP packet with an unknown flowid it
   replies with RESYNC packet and copies the received flowid into the
   message. However, if the responder has an open socket corresponding
   the IP addresses in the IP header it MUST process the packet as a
   standard IP datagram.






Ylitalo, et al.          Expires July 28, 2004                 [Page 21]


Internet-Draft                    WIMP                      January 2004


5.6 REA - The re-addressing packet

   The WIMP header values for the REA packet:

      Header:
        Packet Type = 10
        SRC ID = Initiator's ID
        DST ID = Responder's ID

      IP ( WIMP ( LSET, HASHVAL, ANCHOR, CHALLENGE, HASH-REA ))


   Valid control bits: P

   The REA message contains initiator's locator set. The node that was
   the responder during the context establishment exchange is the
   initiator when it initiates a re-addressing exchange. The initiating
   party of re-addressing exchange is called the initiator in the REA
   context.

   The Initiator revels a successor hash value (HASHVAL TLV) of its
   current hash chain. In addition, it bootstraps a new hash chain by
   revealing a new anchor value (ANCHOR TLV). The challenge used to
   generate a new hash chain is included into the message.  Hash chain
   generation for the initiator is discussed in Section Section 3.3.

   Section 6.5 describes how the HASH-REA is computed.

5.7 AC - The address check packet

   The WIMP header values for the AC packet:

      Header:
        Packet Type = 11
        SRC ID = Responder's ID
        DST ID = Initiator's ID

      IP ( WIMP ( KEY, CHALLENGE ))


   Valid control bits: P

   The responder divided a secret into as many pieces as there were
   addresses in locator set in the received REA message. The key count
   contains the total number of the key pieces. The key mask is an
   identifier for a key piece in the KEY TLV. The challenge TLV includes
   the challenge received in the REA message. The initiator is able to
   bind the received AC to the correct exchange using the challenge. The



Ylitalo, et al.          Expires July 28, 2004                 [Page 22]


Internet-Draft                    WIMP                      January 2004


   responder sends one AC packet per locator in the received locator
   set. (Note: Each AC contains one key piece.)

5.8 ACR - The address check reply packet

   The WIMP header values for the AC packet:

      Header:
        Packet Type = 12
        SRC ID = Initiator's ID
        DST ID = Responder's ID

      IP ( WIMP ( KEY, HASHVAL ))


   Valid control bits: P

   The KEY TLV is constructed of the received key pieces and their key
   masks. The HASHVAL TLV contains the hash value that was used as a key
   in the REA packet in HASH-REA TLV.































Ylitalo, et al.          Expires July 28, 2004                 [Page 23]


Internet-Draft                    WIMP                      January 2004


6. Message formats

6.1 Payload format

   All WIMP packets start with a fixed header.


    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   |  Payload Len  |     Type      |  VER. |  RES. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Controls             |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sender's Identifier (ID)                 |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Receiver's Identifier (ID)               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                        WIMP Parameters                        /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The WIMP header is logically an IPv6 extension header followed by a
   next header that is defined in Next Header field. If no next headers
   follow, the decimal 59, IPPROTO_NONE, the IPV6 no next header value,
   is used.

   The Header Length field contains the length of the WIMP header and
   the length of parameters in 8 bytes units, excluding the first 8
   bytes. Since all WIMP headers MUST contain the sender's and
   receiver's ID fields, the minimum value for this field is 4, and
   conversely, the maximum length of the WIMP Parameters field is
   (255*8)-32 = 2008 bytes.

   The Packet Type indicates the WIMP packet type.  The individual
   packet types are defined in the relevant sections.  If a WIMP host
   receives a packet that contains an unknown packet type, it MUST drop
   the packet.




Ylitalo, et al.          Expires July 28, 2004                 [Page 24]


Internet-Draft                    WIMP                      January 2004


   The Version is four bits. The current version is 1.  The version
   number is expected to be incremented only if there are incompatible
   changes to the protocol.  Most extensions can be handled by defining
   new packet types, new parameter types, or new controls.

   The following four bits are reserved for future use.  They MUST be
   zero when sent, and they SHOULD be ignored when handling a received
   packet.

   The ID fields are always 128 bits (16 bytes) long.

6.1.1 WIMP Controls

   The WIMP control section transfers information about the structure of
   the packet and capabilities of the host.

   The following fields have been defined:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | | | | | | | | | | | | |P| | | |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   P - Piggy backing The sending host is capable of sending and
      receiving additional data (e.g. ESP) in WIMP packets.

   The rest of the fields are reserved for future use and MUST be set to
   zero on sent packets and ignored on received packets.

6.1.2 Checksum

   The checksum field is located at the same location within the header
   as the checksum field in UDP packets, enabling hardware assisted
   checksum generation and verification. Note that since the checksum
   covers the source and destination addresses in the IP header, it must
   be recomputed on WIMP based middle-boxes.

   The pseudo-header [3] contains the source and destination IPv6
   addresses, WIMP packet length in the pseudo-header length field, a
   zero field, and the WIMP protocol number (TBD) in the Next Header
   field.  The length field is in bytes and can be calculated from the
   WIMP header length field: (WIMP Header Length + 1) * 8.

6.2 Parameters

   The parameters are used to carry the hash chain values associated
   with the sender's ID, together with other related security
   information. The parameters consists of ordered parameters, encoded
   in TLV format.



Ylitalo, et al.          Expires July 28, 2004                 [Page 25]


Internet-Draft                    WIMP                      January 2004


   The following parameter types are currently defined.

      TLV               Type  Length     Data

      (TBD)



6.2.1 TLV format

   The TLV encoded parameters are described in the following
   subsections. The type-field value also describes the order of these
   fields in the packet.  The parameters MUST be included into the
   packet so that the types form an increasing order.  If the order does
   not follow this rule, the packet is considered to be malformed and it
   MUST be discarded.

   All the TLV parameters have a length which is a multiple of 8 bytes.
   When needed, padding MUST be added to the end of the parameter so
   that the total length becomes a multiple of 8 bytes.  This rule
   ensures proper alignment of data.  If padding is added, the Length
   field MUST NOT include the padding.  Any added padding bytes MUST be
   set zero by the sender, but their content SHOULD NOT be checked on
   the receiving end.

   Consequently, the Length field indicates the length of the Contents
   field (in bytes).  The total length of the TLV parameter (including
   Type, Length, Contents, and Padding) is related to the Length field
   according to the following formula:

   Total Length = 11 + Length - (Length + 3) % 8;




















Ylitalo, et al.          Expires July 28, 2004                 [Page 26]


Internet-Draft                    WIMP                      January 2004


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type            |C|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                          Contents                             /
      /                                               +-+-+-+-+-+-+-+-+
      |                                               |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type         Type code for the parameter
        C          Critical.  One if this parameter is critical, and
                   MUST be recognized by the recipient, zero otherwise.
                   The C bit is considered to be a part of the Type field.
                   Consequently, critical parameters are always odd
                   and non-critical ones have an even value.
      Length       Length of the parameter, in bytes.
      Contents     Parameter specific, defined by Type
      Padding      Padding, 0-7 bytes, added if needed

   Critical parameters MUST be recognized by the recipient. If a
   recipient encounters a critical parameter that it does not recognize,
   it MUST NOT process the packet any further.

   Non-critical parameters MAY be safely ignored.  If a recipient
   encounters a non-critical parameter that it does not recognize, it
   SHOULD proceed as if the parameter was not present in the received
   packet.






















Ylitalo, et al.          Expires July 28, 2004                 [Page 27]


Internet-Draft                    WIMP                      January 2004


6.3 HASH-INIT

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                             HASH                              |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type           65500
      Length         20
      HASH

                     160 bit SHA1 is computed over:
                       - WIMP common header.
                       - HASHKEY TLV, Initiator's second hash value, H1(I)
                       - FLOWID TLV, initiator.
                       - CHALLENGE TLV, 128 challenge generated by the initiator.
                     excluding the HASH-INIT parameter. The checksum field MUST
                     be set to zero and the WIMP header length in the WIMP common
                     header MUST be calculated to cover all the included
                     parameters when the SHA1 is calculated.

   HASH-INIT calculation and verification process:

   INIT message sender:

   1.  Create the INIT message, containing HASHKEY, FLOWID, and
       CHALLENGE TLVs,  without the HASH-INIT TLV.

   2.  Calculate the length field in the WIMP header.

   3.  Compute the SHA1.

   4.  remove the HASHKEY, and FLOWID TLVs.

   5.  Add the HASH-INIT TLV to the packet.

   6.  Recalculate the length field in the WIMP header.

   CCR message receiver:

   1.  reconstruct the INIT message, containing HASHKEY, FLOWID, and



Ylitalo, et al.          Expires July 28, 2004                 [Page 28]


Internet-Draft                    WIMP                      January 2004


       CHALLENGE TLVs, without the HASH-INIT TLV.

   2.  Calculate the WIMP packet length in the WIMP header and clear the
       checksum field (set it to all zeros).

   3.  Compute the HASH-INIT and verify it against the received
       HASH-INIT.


6.4 HASH-CC

   The TLV structure is the same as in Section 6.3. The fields are:


      Type           65502
      Length         20
      HASH           160 bit SHA1 is computed over:
                       - WIMP common header.
                       - HASHKEY TLV, the responder's hash chain value.
                       - HASH-INIT TLV, received in the INIT message,
                     excluding the HASH-CC parameter. The checksum field MUST
                     be set to zero and the WIMP header length in the WIMP common
                     header MUST be calculated to cover all the included
                     parameters when the SHA1 is calculated.

   HASH-CC calculation and verification process:

   CC message sender:

   1.  Create the CC message, containing HASHKEY, and HASH-INIT TLVs,
       without HASH-CC TLV.

   2.  Calculate the length field in the WIMP header.

   3.  Compute the SHA1.

   4.  remove the HASHKEY TLV.

   5.  Add the HASH-CC TLV to the packet.

   6.  Recalculate the length field in the WIMP header.

   CCR and CONF message receiver:

   1.  reconstruct the CC message, containing HASHKEY, and HASH-INIT
       TLVs, without the HASH-CC TLV.

   2.  Calculate the WIMP packet length in the WIMP header and clear the



Ylitalo, et al.          Expires July 28, 2004                 [Page 29]


Internet-Draft                    WIMP                      January 2004


       checksum field (set it to all zeros).

   3.  Compute the HASH-CC and verify it against the received HASH-CC.


6.5 HASH-REA

   The TLV structure is the same as in Section 6.3. The fields are:


      Type           65504
      Length         20
      HASH           160 bit SHA1 is computed over:
                       - WIMP common header,
                       - LSET TLV, Initiator's locator set.
                       - HASHVAL TLV, a hash value, Hk, of the initiator's
                         hash chain
                       - HASHKEY TLV, a successor hash value, Hk+1, of the
                         initiator's hash chain
                       - ANCHOR TLV, the anchor value, H0, of the initiator's
                         new hash chain
                       - CHALLENGE TLV, the challenge used in the new hash chain
                         generation.
                     excluding the HASH-REA parameter. The checksum field MUST
                     be set to zero and the WIMP header length in the WIMP common
                     header MUST be calculated to cover all the included
                     parameters when the SHA1 is calculated.

   HASH-REA calculation and verification process.

   REA message sender:

   1.  Create the REA message, containing LSET, HASHVAL, ANCHOR, HASHKEY
       and CHALLENGE TLVs, without HASH-REA TLV.

   2.  Calculate the length field in the WIMP header.

   3.  Compute the SHA1.

   4.  remove the HASHKEY TLV.

   5.  Add the HASH-CC TLV to the packet.

   6.  Recalculate the length field in the WIMP header.

   REA message receiver:

   1.  Add  HASHKEY TLV



Ylitalo, et al.          Expires July 28, 2004                 [Page 30]


Internet-Draft                    WIMP                      January 2004


   2.  Remove and store HASH-REA TLV.

   3.  Calculate the WIMP packet length in the WIMP header and clear the
       checksum field (set it to all zeros).

   4.  Compute the HASH-REA and verify it against the received HASH-REA.


6.6 ANCHOR

   The TLV structure is the same as in Section 6.3. The fields are:

      Type           10
      Length         20
      HASH           160 bit SHA1. An anchor value of a hash chain.


6.7 HASHVAL

   The TLV structure is the same as in Section 6.3. The fields are:

      Type           12
      Length         20
      HASH           160 bit SHA1 hash value. It is generated by computing
                     a hash over a successor hash chain value.



6.8 HASHKEY

   The TLV structure is the same as in Section 6.3. The fields are:

      Type           14
      Length         20
      HASH           160 bit SHA1 hash value that is used as a key in
                     HASH-INIT, HASH-CC and HASH-REA TLV computation.
                     The key value is never revealed in the
                     same message as the corresponding authentication hash.


6.9 FLOWID

   The FLOWID parameter contains the flowid that the receiving host must
   use when sending data to the sending host.







Ylitalo, et al.          Expires July 28, 2004                 [Page 31]


Internet-Draft                    WIMP                      January 2004


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Flowid                    |       Reserved        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type         16
      Length       4
      Reserved     Zero when sent, ignored when received
      Flowid       20 bit flowid


6.10 CHALLENGE

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             challenge                         |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type         20
      Length       20
      Reserved     Zero when sent, ignored when received
      challenge    128 bit random number


















Ylitalo, et al.          Expires July 28, 2004                 [Page 32]


Internet-Draft                    WIMP                      January 2004


6.11 LSET

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Address #1                          |
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                              ...                              /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Address #n                          |
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type         22
      Length       variable
      Reserved     Zero when sent, ignored when received
      Address      IPv6 address



























Ylitalo, et al.          Expires July 28, 2004                 [Page 33]


Internet-Draft                    WIMP                      January 2004


6.12 KEY

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        AC ID                  |  Hash ID      |   Key Count   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Key mask                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Key piece 160 bit (AC message) /            |
      /                   Combined key 160 bit (ACR message)          /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type         26
      Length       variable
      AC ID        An increasing counter that identifies the exchange for
                   the responder.
      Hash ID      The order number of a hash chain value in the responder's
                   hash chain. The hash chain value that is divided into key
                   pieces.
      Key count    The total number of key pieces sent/received
      Key Mask
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   The responder defines a bit in the mask for a key piece.

      Key piece    A hash chain value is divided into (160 bit) key pieces
                   by the responder.
      Combined key The initiator constructs a combined key using the key
                   pieces.

   The AC ID is related to a divided secret, i.e. a hash chain value.
   Every key piece related to that value must have the same AC ID.

   Responder sending AC message:

   The key count field value in the AC packet is the total number of key
   pieces sent by the responder. I.e. the total number of sent AC
   packets.  Each KEY-MASK TLV in one AC packet contains a key piece and
   corresponding bit on in the key mask field

   (Note: The responder is able to make a return routability test
   maximum for 32 addresses per divided key.)




Ylitalo, et al.          Expires July 28, 2004                 [Page 34]


Internet-Draft                    WIMP                      January 2004


   Initiator sending ACR message:

   The initiator makes an OR operation for all received key masks in the
   AC packets. The result of the operation is included in the KEY-MASK
   TLV in ACR message.The key count field in KEY-MASK TLV in the ACR
   message indicates the number of key pieces the initiator received
   from the responder. The combined key is included into the KEY-MASK
   TLV.











































Ylitalo, et al.          Expires July 28, 2004                 [Page 35]


Internet-Draft                    WIMP                      January 2004


7. State Machine

   The initiator of the context establishment exchange is called the
   initiator. Once the host-pair contexts are established, this initial
   distinction is lost.  The sender of the REA message is called the
   initiator of the re-addressing exchange. In a case of state loss, the
   sender of the RESYNCH message becomes a responder. .

   The state machine is presented in a single system view, representing
   either an Initiator or a Responder.  There is not a complete overlap
   of processing logic here and in the packet definitions.  Both are
   needed to completely implement WIMP.

   Implementors must understand that the state machine, as described
   here, is informational.  Specific implementations are free to
   implement the actual functions differently.

7.1 States

   START , state machine start

   INIT-sent , INIT sent by initiator

   CCR-sent , CCR sent by initiator

   ESTABLISHED , host-pair context established

   ESTABLISHED-REA-sent , REA sent

   FAILED , host-pair context establishment failed


7.2 State Processes

   +---------+
   |  START  |
   +---------+

   Datagram to send, send INIT and go to INIT-send
   Receive INIT, send CC and stay at START
   Receive CCR, process
        if successful, send CONF and go to ESTABLISHED
        if fail, stay at START
   Receive IP packet with unknown flowid, send RESYNC and stay at START
   Receive ANYOTHER, drop and stay at START

   +-----------+
   | INIT-sent |



Ylitalo, et al.          Expires July 28, 2004                 [Page 36]


Internet-Draft                    WIMP                      January 2004


   +-----------+

   Receive INIT, send CC and stay at INIT-sent
   Receive CCR, process
        if successful, send CONF and go to ESTABLISHED
        if fail, stay at INIT-sent
   Receive CC, process
        if successful, send CCR and go to CCR-sent
        if fail, stay at INIT-sent
   Receive ANYOTHER, drop and stay at INIT-sent
   Timeout, increment timeout counter
        If counter is less than INIT_RETRIES_MAX, send INIT and stay at INIT-sent
        If counter is greater than INIT_RETRIES_MAX, go to FAILED

   +----------+
   | CCR-sent |
   +----------+

   Receive INIT, send CC and stay at CCR-sent
   Receive CCR, process
        if successful, send CONF and go to ESTABLISHED
        if fail, stay at CCR-SENT
   Receive CONF, process
        if successful, go to ESTABLISHED
        if fail, stay at CCR-SENT
   Receive ANYOTHER, drop and stay at CCR-sent
   Timeout, increment timeout counter
        If counter is less than CCR_RETRIES_MAX, send CCR and stay at CCR-sent
        If counter is greater than CCR_RETRIES_MAX, go to FAILED

   +-------------+
   | ESTABLISHED |
   +-------------+

   REA to send, go to ESTABLISHED-REA-sent
   Receive RESYNC, send INIT and cycle at ESTABLISHED
   Receive CC, process
        if successful, send CCR and stay at ESTABLISHED
        if fail, drop, and stay at ESTABLISHED
   Receive CONF, process
        if successful, update host-pair context and cycle at ESTABLISHED
        if fail, drop, and stay at ESTABLISHED
   Receive REA, process
        if successful, update host-pair context, send ACs,
           and cycle at ESTABLISHED
        if fail, drop, and stay at ESTABLISHED
   Receive ACR, process
        if successful, update host-pair context, and cycle at ESTABLISHED



Ylitalo, et al.          Expires July 28, 2004                 [Page 37]


Internet-Draft                    WIMP                      January 2004


        if fail, drop, and stay at ESTABLISHED
   Receive IP packet for host-pair context, process and stay at ESTABLISHED
   Receive ANYOTHER, drop and stay at ESTABLISHED

   +-----------------------+
   | ESTABLISHED-REA-sent  |
   +-----------------------+

   Receive RESYNC, send INIT and go to ESTABLISHED
   Receive REA, process
        if successful, update host-pair context, send ACs,
           and cycle at ESTABLISHED-REA-sent
        if fail, drop, and cycle at ESTABLISHED-REA-sent
   Receive AC, process
        if successful, send ACR, and go to ESTABLISHED
        if fail, sent REA, and cycle at ESTABLISHED-REA-sent
   Receive ACR, process
        if successful, update host-pair context,
           and cycle at ESTABLISHED-REA-sent
        if fail, drop, cycle at ESTABLISHED-REA-sent
   Receive IP packet for host-pair context, process,
         and stay at ESTABLISHED-AC-sent
   Receive ANYOTHER, drop and stay at ESTABLISHED-AC-sent
   Timeout, increment timeout counter
        If counter is less than REA_RETRIES_MAX, send REA,
            and stay at ESTABLISHED-REA-sent
        If counter is greater than REA_RETRIES_MAX, go to FAILED


7.3 State Loss

   WIMP protocol and state machine is designed to recover from one of
   the parties crashing and losing its state.  The following scenarios
   describe the main use cases covered by the design.

      No prior state between the two systems.

         The system with data to send is the Initiator.  The process
         follows standard 4 packet context establishment exchange,
         establishing the host-pair context.

      The initiator has no state with the responder, but the responder
      has an earlier host-pair context.

         Initiator acts as in no prior state, sending INIT. The
         Initiator selects a new random ID(I) and the responder finally
         establishes a new host-pair context with the initiator. The old
         context will expire due to timers (TBD).



Ylitalo, et al.          Expires July 28, 2004                 [Page 38]


Internet-Draft                    WIMP                      January 2004


      The initiator has a host-pair context, but the responder does not.

         The responder 'detects' the situation when it receives a packet
         that contains an unknown flowid.  The responder sends a RESYNC
         with received flowid and a NULL (zero) initiator ID.  The
         initiator gets the RESYNC and initiates a new context
         establishment exchange to re-establish the host-pair context
         with the existing IDs.  The initiator generates a new hash
         chain but sends the old challenge, to the responder.

   If a host reboots or times out, it has lost its host-pair context.
   If the system that lost state has a datagram to deliver to its peer,
   it simply restarts the context establishment exchange with INIT
   message containing a new ID(I). The responder replies with CC packet.

   If a system receives an IP packet for an unknown flowid, the
   assumption is that it has lost the state and its peer did not.  In
   this case, the system replies with a RESYNCH packet.  The ID(I) is
   typically NULL in the RESYNCH, since the system usually does not know
   the peer's ID any more.

   The system receiving the RESYNCH packet first checks to see if it has
   an established and recently used host-pair context with the party
   sending the RESYNCH.  If such a context exists, the initiator
   initiates a new context establishment exhange by sending INIT
   message.  Note that the process will result in a new host-pair
   context at the responder site, while the initiator is able to use the
   existing host-pair context.























Ylitalo, et al.          Expires July 28, 2004                 [Page 39]


Internet-Draft                    WIMP                      January 2004


8. Security Considerations

   The initial design choice was to use reverse hash chains instead of
   public key technology. The reason for this was that there exists
   already a group of authenticated Diffie-Hellman key exhange
   protocols. However, protocols using public key technology are
   vulnerable for different kind of CPU related denial-of-service
   attacks. 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. However, if we accept that the
   first round-trip of the context establishment exchange is open for
   such attacks we obtain several advantages. The hash chain computation
   is a lightweight operation compared to signature verification.

8.1 Context establishment exchange

8.1.1 Man-in-the-Middle attacks

   The context establishment exchange is based on opportunistic
   authentication. In other words, both hosts, the initiator and
   responder, have to trust the first message comes from the authentic
   peer. The responder trusts that the INIT message comes from an
   authentic initiator. In a similar way, the initiator trusts that the
   CC message comes from an authentic responder.  Therefore, the first
   round-trip is vulnerable for the MitM attacks.

   The second round-trip of the exchange bootstraps the hash chains and
   bounds the messages together. The anchor values revealed during the
   second round-trip are used to authenticate the first round-trip
   messages.  A MitM attacker cannot change any values in the CCR
   message, because the message is authenticated with the responder's
   HMAC. The responder's HMAC, in turn, is computed over the initiator's
   HMAC. In this way, the responder does not need to establish a state
   once it receives INIT message. In addition, a MitM attacker cannot
   reserve a host-pair context by sending CCR message with initiator's
   ID because the messages are bound together. Finally, the hash chains
   have two main purposes. They bind messages together, and they are
   used to authenticate the messages. The hash chain properties were
   discussed in more detail in Section 2.1.

8.1.2 Denial-of-Service attacks

   The initiator may use any identifier, ID(I), it wants with the
   responder. This property protects the initiator from a specific form
   of DoS attack. That is, the attacker is not able to establish a
   context with the responder using the initiator's identifier if the
   initiator chooses its identifier randomly.




Ylitalo, et al.          Expires July 28, 2004                 [Page 40]


Internet-Draft                    WIMP                      January 2004


   On the other hand, the beginning of the context establishment
   exchange is stateless for the responder in order to avoid attacks
   where the attacker is trying to create inconsistent states in the
   responder. The responder does a kind of return-routability test
   before establishing a state.  The initiator has to prove that is
   reachable in the location where it sent the initial packet. The
   responder may optionally restrict establishing a host-pair context
   for an initiator if the responder already has several host-pair
   contexts related to same IP addresses.

   Basically, the context establishment protocol is vulnerable for a
   flowid related attack. The only value that is not protected with HMAC
   is the responder's flowid in the last message. The reason for this is
   that the responder cannot reserve any values before it creates a
   state. The state is created after receiving the CCR message.  As a
   consequence, the responder cannot include the flowid into its HMAC in
   the CC message. a MitM attacker may change the responder's flowid on
   the fly in the last message and course a denial-of-service situation.
   In other words, the initiator will send IP packets with wrong flowid
   to the responder. However, the main objective of the protocol was to
   protect the hosts from the re-direction attacks and the presented
   attack does not open new vulnerabilities for that part.

8.2 Re-addressing exchange

   When a site renumbers, a host inside the site must inform its peers
   about the new IP address(es). The sender of the new locator set is
   called an initiator. Once the responder receives REA message it
   cannot trust that the initiator is reachable at the new locations. To
   avoid different kind of DoS and redirection attacks the responder
   must verify that the initiator indeed is reachable at the claimed
   locations.

   the proposed protocol takes advantage of parallel paths between the
   hosts.  The responder splits its hash chain value into pieces and
   protects each challenge (AC) message with one piece. Each of
   challenge messages is sent to different location. As a consequence,
   an attacker has to locate at different topological locations, at the
   same time, to be able to answer to the challenge. The initiator, in
   turn, is able to verify that all of the pieces came from the
   authentic responder. The secret splitting works only if there are
   more than one AC messages to be sent and the messages are routed via
   different paths to the initiator. (Note: To increase the security of
   the challenge message, the responder could protect the AC message
   with HMAC. The key in each message would then be a divided secret,
   i.e. a hash value.)





Ylitalo, et al.          Expires July 28, 2004                 [Page 41]


Internet-Draft                    WIMP                      January 2004


9. IANA Considerations

   IANA has assigned IP Protocol number TBD to WIMP.
















































Ylitalo, et al.          Expires July 28, 2004                 [Page 42]


Internet-Draft                    WIMP                      January 2004


10. Acknowledgments

   This draft is a result of the discussion between the authors, Pekka
   Nikander and Jari Arkko at the 58th IETF. The idea was to write a
   Multi6 draft using reverse hash chains and secret splitting. The main
   objective in this draft has been on identifying the hosts to their
   peers with reverse hash chains. Instead of inventing the wheel once
   again, we took several ideas from the existing protocol proposals.
   Therefore, there are certain similarities with SIM and HIP design
   factors. We would like to thank all contributers in those drafts that
   have affect the work.








































Ylitalo, et al.          Expires July 28, 2004                 [Page 43]


Internet-Draft                    WIMP                      January 2004


Normative references

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Draves, R., "Default Address Selection for Internet Protocol
        version 6 (IPv6)", RFC 3484, February 2003.

   [3]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [4]  Abley, J., Black, B. and V. Gill, "Goals for IPv6
        Site-Multihoming Architectures", RFC 3582, August 2003.

   [5]  Kent, S., "IP Encapsulating Security Payload (ESP)",
        draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003.

   [6]  Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
        solutions", draft-nordmark-multi6-threats-00.txt (work in
        progress), October 2003.

   [7]  Lear, E. and R. Droms, "What's In A Name: Thoughts from the
        NSRG", draft-irtf-nsrg-report-09.txt (work in progress), March
        2003.



























Ylitalo, et al.          Expires July 28, 2004                 [Page 44]


Internet-Draft                    WIMP                      January 2004


Informative references


Authors' Addresses

   Jukka Ylitalo
   Ericsson Research Nomadiclab

   Jorvas  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: jukka.ylitalo@ericsson.com


   Vesa Torvinen
   Ericsson Research Nomadiclab

   Turku  FIN-20520
   FINLAND

   Phone: +358 9 299 1
   EMail: vesa.torvinen@ericsson.com


   Erik Nordmark
   Sun Microsystems, Inc.
   17 Network Circle
   Mountain View, CA
   USA

   Phone: +1 650 786 2921
   EMail: erik.nordmark@sun.com


















Ylitalo, et al.          Expires July 28, 2004                 [Page 45]


Internet-Draft                    WIMP                      January 2004


Appendix A. Example of secure reverse hash chain generation

   This Appendix gives an example for secure hash chain generation.

   Initiator (context establishment and re-addressing exchanges):



     Hn(I) = SHA1(secret(I)|ID(I)|ID(R)|challenge(I))
     ...
     H1(I) = SHA1(H2(I))
     H0(I) = SHA1(H1(I))


   Responder (context establishment exchange):



     Hn(R) = SHA1(secret(R)|ID(R)|ID(I)|challenge(I))
       Note: challenge(I) is generated by the initiator
     ...
     H1(R) = SHA1(H2(R))
     H0(R) = SHA1(H1(R))


   The default length of both of the hash chains is n=10.



   secret(I)    = 256 bit secret random number generated by the initiator
   secret(R)    = 256 bit secret random number generated by the responder
   challenge(I) = 128 bit public random number generated by the initiator
   Hk(I/R)      = initiator's/responder's 160 bit hash chain value
   ID(I/R)      = initiator's/responder's 128 bit identifier


   The secret(I/R) is not revealed to the peers.  The long term
   secret(R) MUST survive when the system boots. The responder SHOULD
   use the same secret(R) for different hash chains generated during the
   lifetime of the secret(R).











Ylitalo, et al.          Expires July 28, 2004                 [Page 46]


Internet-Draft                    WIMP                      January 2004


Appendix B. Goals for IPv6 Site-Multihoming Architectures

   This section compares the proposed solution with the goals of IPv6
   site multihoming architecture [4].

B.1 Redundancy

   The proposed end-to-end protocol allows applications to use multiple
   IPv6 addresses. Furthermore, the WIMP layer is able to receive events
   from different sources: from upper and lower layers. L2 may inform
   WIMP, e.g, if the local link is down. L4, in turn, may launch a
   trigger due to TCP time-outs. Finally, the redundancy is a question
   of local triggers, implementation and address selection policy.  (The
   address selection policy should be separated from the core protocol
   draft)

B.2 Load Sharing

   The identifier and locator-set separation makes it possible to
   implement dynamic load sharing. The sender is able to select source
   and destination IP addresses on packet basis. The sender and receiver
   may have several parallel paths between then; both of the hosts being
   multi-homed at the same time. (Note: However, sending TPC packets via
   alternative paths may lead to poor performance.)

B.3 Performance

   The protocol defined in this draft does not directly interoperate
   with Internet routing protocols. However, the implementation should
   follow source address routing principles. In other words, the next
   hop router, and its prefix, defines the used source address. However,
   a host with one interface typically receives multiple prefixes from
   one access router. Congestion related to a path should be identified
   using RTT and bandwidth values as triggers for hand-offs between
   addresses.

B.4 Policy

   The proposed solution does not take a stand on the reason why
   multihoming is used. The solution provides support for
   site-multihoming for external policy reasons. If the responder has
   stored several IP addresses to the DNS, the initiator may assume that
   the responder supports multihoming. (Note: there are several other
   ways using DNS to inform the initiator that the peer supports
   multihoming.)






Ylitalo, et al.          Expires July 28, 2004                 [Page 47]


Internet-Draft                    WIMP                      January 2004


B.5 Simplicity

   Proposed solution is straightforward to deploy and maintain. It is
   not more complex to deploy and operate than current IPv4 multihoming
   practices. The protocol supports legacy IPv6 socket API.

B.6 Transport-Layer Survivability

   The proposed solution provides re-homing transparency for
   transport-layer sessions. The existing transport-layer sessions are
   able to use the new path because the upper layer identities are
   separated from the network topology.

B.7 Impact on DNS

   No impacts on DNS RR records.

B.8 Packet Filtering

   The solution does not preclude filtering.

B.9 Scalability

   The proposed protocol is responsible for changing the default path,
   source and destination IP addresses, to another if the peer is not
   reachable via some route. The routing desicion is made at the
   end-host.

B.10 Impact on Routers

   The proposed solution does not require changes to IPv6 router
   implementations.

B.11 Impact on Hosts

   A host that has not implemented the proposed solution can still work
   in a multihomed site. The solution requires changes to the end-host
   stack, however, these changes are logically separate functions that
   can be added to existing functions. The solution does not require
   changes to the socket API or the transport layer.

B.12 Interaction between Hosts and the Routing System

   The solution does not require interaction between a site's hosts and
   its routing system.






Ylitalo, et al.          Expires July 28, 2004                 [Page 48]


Internet-Draft                    WIMP                      January 2004


B.13 Operations and Management

   The staff responsible for the operation of a site is able to
   advertise any prefixes it wants for the hosts. The site multihoming
   system can be configured advertising different set of prefixes.

B.14 Cooperation between Transit Providers

   The solution does not require cooperation between transit providers.

B.15 Security compared to IPv4 multihoming

   The proposed solution is vulnerable for man-in-the-middle attack in
   the first message exchange because it relies on opportunistic
   security principles. The security properties are analyzed in Section
   8.



































Ylitalo, et al.          Expires July 28, 2004                 [Page 49]


Internet-Draft                    WIMP                      January 2004


Appendix C. Things MULTI6 Developers should think about

   This section answers to the questions presented in the
   draft-lear-multi6-things-to-think-about-00.

C.1 Routing

   "How will your solution solve the multihoming problem?"

   By definining a new logical layer between networking (L3) and
   transport (L4) layers. The logical layer separates identifiers from
   locators.  The dynamic one-to-many binding between an identifier and
   IP addresses makes multihoming possible. The identifiers are used by
   upper layers, while the IP addresses are used on the wire.

   "Does your solution address mobility?"

   The proposal does not define any rendevouz server, but allows dynamic
   address updates between hosts.

C.2 Identifiers and locators

   "Does your solution provide for a split between identifiers and
   locators?"

   Yes. The responder's identifier is a 128-bit hash of FQDN.  The
   initiator's identifier, in turn, is a hash of a nonce for security
   reasons.

   "What is the lifetime of a binding from an identifier to a locator?"

   The lifetime of a binding is the lifetime of open sockets. As long as
   there are open connections between end-points, the corresponding
   host-pair context should not be deleted. However, the binding can be
   dynamically updated.

   "How is the binding updated?"

   By re-addressing exchange.

   "Will transport connections remain up?"

   Yes.

C.3 On The Wire

   "At what layer is your solution applied, and how?"




Ylitalo, et al.          Expires July 28, 2004                 [Page 50]


Internet-Draft                    WIMP                      January 2004


   At logical layer between networking (L3) and tranport (L4) layers.

   "Is it applied in every packet?  If so, what fields are used?"

   It is applied in every packet by using flowid field in the IPv6
   header

   "Why is the layer you chose the correct one?"

   The implementation does not affect the upper layers nor applications.

   "Does your solution expand the size of an IP packet?"

   Only during the context establishment and re-addressing exchanges.
   The IP payload packets use flowid field to identify packets.

   "Do you change the way fragmenting is handled?"

   Not in the normal IPv6 packets. The packets carrying context
   establishment or re-addressing exchange messages must not be
   fragmented.

   "Are there any changes to ICMP error semantics?"

   No. However, the presented packet formats can be implemented as ICMP
   extension fields.

C.4 Names, Hosts, Endpoints, or none of the above?

   "Please explain the relationship of your solution to DNS"

   The proposal assumes that a host is multi-homed if it has several
   AAAA RR entries in the DNS.

   "Please explain interactions with "2-faced" DNS"

   No effect

   "Does your solution require centralized registration?"

   Every server (responder) must have a basic DNS entry, containing FQDN
   and locator set, as nowadays

   "Have you checked for DNS circular dependencies?"

   The solution is dependent of FDQN and locator set mapping

   "What if a DNS server itself is multihomed?"



Ylitalo, et al.          Expires July 28, 2004                 [Page 51]


Internet-Draft                    WIMP                      January 2004


   No effect.

   "What application/API changes are needed?"

   None.

   "Is this solution backward compatible with "old" IP version 6?"

   Yes. The new identifiers are identified with two highest bits in the
   128-bit identifier, like in the HIP.

   "Is your solution backward compatible with IPv4?"

   The 6to4 gateway must work as an authentication proxy. TBD.

   "How will your solution interact with other middle-boxes?"

   TBD.

   "Are there any implications for scoped addressing?"

   TBD.

   "Are there any layer 2 implications to your proposal?"

   None.

   "How will your solution handle referrals, such as those within FTP?"

   TBD.

   "Are you introducing a namespace that might involve mnemonics?"

   No.

















Ylitalo, et al.          Expires July 28, 2004                 [Page 52]


Internet-Draft                    WIMP                      January 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Ylitalo, et al.          Expires July 28, 2004                 [Page 53]


Internet-Draft                    WIMP                      January 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Ylitalo, et al.          Expires July 28, 2004                 [Page 54]