[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                           J. Abley
Internet-Draft                                            Afilias Canada
Intended status: Informational                                M. Bagnulo
Expires: January 9, 2008                             Huawei Labs at UC3M
                                                            July 8, 2007


   Applicability Statement for the Level 3 Multihoming Shim Protocol
                                (Shim6)
                   draft-ietf-shim6-applicability-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document discusses the applicability of the shim6 IPv6 protocol
   element and associated support protocols to provide site multihoming
   capabilities in IPv6.






Abley & Bagnulo          Expires January 9, 2008                [Page 1]

Internet-Draft        Shim6 Applicability Statement            July 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Application Scenarios  . . . . . . . . . . . . . . . . . . . .  3
   3.  Address Configuration  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . .  5
     3.2.  Prefix Lengths . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Address Generation . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . .  6
   4.  shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Fault Tolerance  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  Establishing Communications After an Outage  . . . . .  7
       4.1.2.  Short-Lived Communications . . . . . . . . . . . . . .  7
       4.1.3.  Long-Lived Communications  . . . . . . . . . . . . . .  8
     4.2.  Load Balancing . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Traffic Engineering  . . . . . . . . . . . . . . . . . . .  9
   5.  Interaction with Other Protocols . . . . . . . . . . . . . . .  9
     5.1.  shim6 and Mobile IPv6  . . . . . . . . . . . . . . . . . .  9
       5.1.1.  Multi-homed Home Network . . . . . . . . . . . . . . .  9
       5.1.2.  shim6 Between the HA and the MN  . . . . . . . . . . . 12
     5.2.  shim6 and SeND . . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 13
     5.4.  shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 13
     5.5.  shim6 and HIP  . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
     6.1.  Privacy Considerations . . . . . . . . . . . . . . . . . . 16
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20


















Abley & Bagnulo          Expires January 9, 2008                [Page 2]

Internet-Draft        Shim6 Applicability Statement            July 2007


1.  Introduction

   Site multi-homing is an arrangement by which a site may use multiple
   paths to the rest of the Internet, to provide better reliability for
   traffic passing in and out of the site than would be possible with a
   single path.  Some of the motivations for operators to multi-home
   their network are described in [RFC3582].

   In IPv4, site multi-homing is achieved by introducing the additional
   state required to allow session resilience over re-homing events to
   the global Internet routing system (sometimes referred to as the
   Default-Free Zone, or DFZ) [RFC4116].  There is concern that this
   approach will not scale [RFC3221].

   In IPv6, site multi-homing in the style of IPv4 is not generally
   available to end sites due to a strict policy of route aggregation in
   the DFZ.  Site multi-homing for sites without PI addresses is
   achieved by assigning multiple addresses to each host, one or more
   from each provider.  This multi-homing approach provides no
   transport-layer stability across re-homing events.

   shim6 introduces transport-layer mobility across re-homing events
   using a layer-3 shim approach.  State information relating to the
   multi-homing of two endpoints exchanging unicast traffic is retained
   on the endpoints themselves, rather than in the network.
   Communications between shim6-capable hosts and shim6-incapable hosts
   proceed as normal, but without the benefit of transport-layer
   stability.  The shim6 approach is thought to have better scaling
   properties with respect to the state held in the DFZ than the IPv4
   approach.

   This note describes the applicability of the Level 3 multihoming
   (hereafter shim6) protocol defined in [I-D.ietf-shim6-proto] and the
   failure detection mechanisms defined in
   [I-D.ietf-shim6-failure-detection].

   The terminology used in this document, including terms like locator,
   and ULID, is defined in [I-D.ietf-shim6-proto].


2.  Application Scenarios

   The goal of the shim6 protocol is to support locator agility in
   established communications: different layer-3 endpoint addresses may
   be used to exchange packets as part of the same transport-layer
   session, all the time presenting a consistent identifier pair to
   upper-layer protocols.




Abley & Bagnulo          Expires January 9, 2008                [Page 3]

Internet-Draft        Shim6 Applicability Statement            July 2007


   In order to be useful, the shim6 protocol requires that at least one
   of the peers has more than one address (locator).  In the event of
   communications failure between an active pair of addresses, the shim6
   protocol will attempt to reestablish communication by trying
   different combinations of locators.

   While other multi-addressing scenarios are not precluded, the
   scenario in which the shim6 protocol is expected to operate is that
   of a multi-homed site which is connected to multiple transit
   providers, and which receives an IPv6 prefix from each of them.  This
   configuration is intended to provide protection for the end-site in
   the event of a failure in some subset of the available transit
   providers without requiring the end-site to acquire provider-
   independent (PI) address space or requiring any particular
   cooperation between the transit providers.

      ,------------------------------------.       ,----------------.
      |        Rest of the Internet        +-------+ Remote Host R  |
      `--+-----------+------------------+--'       `----------------'
         |           |                  |            LR[1] ... LR[m]
     ,---+----.  ,---+----.        ,----+---.
     | ISP[1] |  | ISP[2] | ...... | ISP[n] |
     `---+----'  `---+----'        `----+---'
         |           |                  |
     ,---+-----------+------------------+---.
     |   Multi-Homed Site S assigned        |
     |   prefixes P[1], P[2], ..., P[n]     |
     |                                      |
     |  ,--------. L[1] = P[1]:iid[1],      |
     |  | Host H | L[2] = P[2]:iid[2], ...  |
     |  `--------' L[n] = P[n]:iid[n]       |
     `--------------------------------------'

                                 Figure 1

   In the scenario illustrated in Figure 1 host H communicates with some
   remote host R. Each of the addresses L[i] configured on host H in the
   multi-homed site S can be reached through provider ISP[i] only, since
   ISP[i] is solely responsible for originating a covering prefix for
   P[i] to the rest of the Internet.

   The use of locator L[i] on H hence causes inbound traffic towards H
   to be routed through ISP[i].  Changing the locator used from L[i] to
   L[j] will have the effect of re-routing inbound traffic to H from
   ISP[i] to ISP[j].  This is the central mechanism by which the shim6
   protocol aims to provide multi-homing functionality: by changing
   locators, the H can change the upstream ISP used to route inbound
   packets towards itself.  Corresponding control of the outbound path



Abley & Bagnulo          Expires January 9, 2008                [Page 4]

Internet-Draft        Shim6 Applicability Statement            July 2007


   for packets from H towards R is shared between the locator LR[j]
   chosen by R, and the administrative exit selection policy of site S.

   The shim6 protocol has other potential applications beyond site
   multi-homing.  For example, since shim6 is a host-based protocol, it
   can also be used to support hpost multihoming.  In this case, a
   failure in communication between a multi-homed host and some other,
   remote host might be repaired by selection of a locator associated
   with a different interface.


3.  Address Configuration

3.1.  Protocol Version (IPv4 vs. IPv6)

   The shim6 protocol is defined only for IPv6.  However, there is no
   fundamental reason why a shim6-like approach could not support IPv4
   addresses as locators, either to provide multi-homing support to
   IPv4-numbered sites, or as part of an IPv4/IPv6 transition strategy.
   Some extensions to the shim6 protocol for supporting IPv4 locators
   have been proposed in [I-D.nordmark-shim6-esd].

   The shim6 protocol, as specified for IPv6, incorporates cryptographic
   elements in the construction of locators (see [RFC3972],
   [I-D.ietf-shim6-hba]).  Since IPv4 addresses are insufficiently large
   to contain addresses constructed in this fashion, direct
   implementation of shim6 as specified for IPv6 for use with IPv4
   addresses might require protocol modifications.

   In addition, there are other considerations to take into account when
   considering the support of IPv4 addresses, in particular IPv4
   locators.  In partiuclar, using multiple IPv4 addresses in a single
   host in order to support shim6 style of multihoming would result in
   an increased IPv4 address consuption, which with the current rate of
   IPv4 addresses would be problematic.  In addition, in order to be
   useful, shim6 IPv4 support would require NAT traversal mechanisms
   which are not defined yet and that would imply additional conpelxity
   (As any other NAT traversal mechanism).

3.2.  Prefix Lengths

   The shim6 protocol does not assume that all the addresses assigned to
   the multihomed site have the same prefix length.

   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
   encoding information in the lower 64 bits of locators.  This imposes
   the requirement on address assignment to shim6-capable hosts that all
   interface addresses should be able to accommodate 64-bit interface



Abley & Bagnulo          Expires January 9, 2008                [Page 5]

Internet-Draft        Shim6 Applicability Statement            July 2007


   identifiers.  This requirement is also imposed by CGA [RFC3972].
   However it should be noted that this is imposed by RFC3513 [RFC3513]

3.3.  Address Generation

   The security of the shim6 protocol is based on the use of CGA and HBA
   addresses.

   CGA and HBA can be generated through the stateless auto-configuration
   mechanism defined in [RFC2462] with the additional considerations
   presented in [RFC3972] and [I-D.ietf-shim6-hba].

   Stateful address auto-configuration using DHCP [RFC3315] is not
   currently supported, because there is no defined mechanism to convey
   the CGA Parameter Data Structure and other relevant information from
   the DHCP server to the host.  The definition of such mechanisms seems
   to be quite straightforward in the case of the HBA, since only the
   CGA Parameter Data Structure needs to be delivered from the DHCP
   server to the shim6 host, and that data structure does not contain
   any secret information.  In the case of CGAs, however, private key
   information must be exchanged as well as the CGA Parameter Data
   Structure.

3.4.  Use of CGA vs. HBA

   The choice between CGA and HBA is a trade-off between flexibility and
   performance.

   The use of HBA is more efficient in the sense that addresses require
   less computation than CBA, involving only hash operations for both
   the generation and the verification of locator sets.  However, with
   HBA the locator set is determined during the generation process, and
   cannot be subsequently changed; addition of new locators to that
   initial set is not supported, except by re-generation of the entire
   set which will cause all addresses to change.

   Use of CGA is more computationally expensive, involving public key
   cryptography in the verification of locator sets.  However, CGAs are
   more flexible in the sense that they support the dynamic modification
   of locator sets.

   CGAs are well suited to support dynamic environments such as mobile
   hosts, where the locator set must be changed frequently.  HBAs are
   better suited for static sites where the prefix set remains
   relatively stable.

   It should be noted that, since HBAs are defined as a CGA extension,
   it is possible to generate hybrid HBA/CGA structures that incorporate



Abley & Bagnulo          Expires January 9, 2008                [Page 6]

Internet-Draft        Shim6 Applicability Statement            July 2007


   the strengths of both: i.e. that a single address can be used as an
   HBA, enabling computationally-cheap validation amongst a fixed set of
   addresses, and also as a CGA, enabling dynamic manipulation of the
   locator set.  For additional details, see [I-D.ietf-shim6-hba].


4.  shim6 Capabilities

4.1.  Fault Tolerance

4.1.1.  Establishing Communications After an Outage

   If a host within a multihomed site attempts to establish
   communication with a remote host outside the site while one of the
   site's transit paths has failed, and selects an local locator from
   which to source packets which corresponds to the failed transit path,
   bidirectional communication between the two hosts will not succeed.
   The failure of the transit path will not, in general, be known in
   advance to the host.

   In order to establish communication, the initiating host must try
   different combinations of (source, destination) locator until it
   finds a pair that works.  The mechanism for this default address
   selection is described in [RFC3484]; commentary on this mechanism in
   the context of multi-homed environments can be found in
   [I-D.bagnulo-ipv6-rfc3484-update].

   Since shim6 context is normally only established between two hosts
   after initial communication has been established, there is no
   opportunity for shim6 to participate in the discovery of a suitable,
   initial (source, destination) locator pair.

4.1.2.  Short-Lived Communications

   The shim6 context establishment operation requires a 4-way packet
   exchange, and involves some overhead on the participating hosts in
   memory and CPU.

   For short-lived exchanges between two hosts, the benefit of
   establishing a shim6 context might not exceed the cost, perhaps
   because the protocols concerned are tolerant of failure and can
   arrange their own recovery (e.g.  DNS) or because the frequency of
   re-homing events is sufficiently low that the probability of such a
   failure occuring during a short-lived exchange is not considered
   significant.

   It is anticipated that the exchange of shim6 context will provide
   most benefit for exchanges between hosts which are long-lived.  For



Abley & Bagnulo          Expires January 9, 2008                [Page 7]

Internet-Draft        Shim6 Applicability Statement            July 2007


   this reason the default behaviour of shim6-capable hosts is expected
   to employ deferred context setup.  This default behaviour will be
   able to be overridden by applications which prefer immediate context
   establishment regardless of transaction longeivity.

   It must be noted that all the above considerations refer to lifetime
   of the contact between the peers and not about the lifetime of the
   particular connection (e.g.  TCP connection).  In other words, the
   shim6 context is established between ULID pairs and it affects all
   the communication between these ULIDs.  So, two nodes that perform
   multiple short lived communications with the same ULID pair would
   benefit as much from the shim features as two nodes having a single
   long-lived communication.  One example of such scenario would be a
   web client software downloading web contents from a server with over
   multiple TCP connections.  Each TCP connection is short-lived, but
   the communication/contact between the two ULID could be long-lived.

4.1.3.  Long-Lived Communications

   As discussed in Section 4.1.2, hosts engaged in long-lived
   communications will suffer lower proportional overhead, and greater
   probability of benefit than those performing brief transactions.

   Deferred context setup ensures that session establishment time will
   not be increased by the use of shim6.

4.2.  Load Balancing

   The shim6 protocol does not support load balancing within a single
   context: all packets associated with a particular context are
   exchanged using a single locator pair per direction, with the
   exception of forked contexts which involve the upper-layer protocol.

   It may be possible to extend the shim6 protocol to use multiple
   locator pairs in a single context, but the impact of such an
   extension on upper-layer protocols (e.g. on TCP congestion control)
   should be considered carefully.

   When many contexts are considered together in aggregate, e.g. on a
   single host which participates in many simultaneous contexts or in a
   site full of hosts, some degree of load sharing should occur
   naturally due to the selection of different locator pairs in each
   context.  There is no mechanism defined to ensure that this natral
   load sharing is arranged to provide a statistical balance between
   transit providers, however.






Abley & Bagnulo          Expires January 9, 2008                [Page 8]

Internet-Draft        Shim6 Applicability Statement            July 2007


4.3.  Traffic Engineering

   The shim6 protocol provides some lightweight traffic engineering
   capabilities in the form of the Locator Preferences option, which
   allows a host to inform a remote host of local preferences for
   locator selection.

   This mechanism is only available after a shim6 context has been
   established, and is a host-based capability rather than a site-based
   capability.  There is no defined mechanism which would allow use of
   the Locator Preferences option amongst a site full of hosts to be
   managed centrally.


5.  Interaction with Other Protocols

5.1.  shim6 and Mobile IPv6

   Multiple scenarios where the shim6 protocol and the MIPv6 protocol
   MIPv6 protocol [RFC3775] might be used simultaneously have been
   considered.

5.1.1.  Multi-homed Home Network

   In this case, the Home Network of the Mobile Node (MN) is multi-
   homed.  This implies the availability of multiple Home Network
   prefixes, resulting on multiple HoAs for each MN.  Since the MN is a
   node within a multihomed site, it seems reasonable to expect that the
   MN should able to benefit from the multihoming capabilities provided
   by the shim6 protocol.  Moreover, the MN needs to be able to obtain
   the multihoming benefits even when it is roaming away from the Home
   Network: if the MN is away from the Home Network while the Home
   Network suffers a failure in a transit path, the MN should be able to
   continue communicating using alternate paths to reach the Home
   Network.
















Abley & Bagnulo          Expires January 9, 2008                [Page 9]

Internet-Draft        Shim6 Applicability Statement            July 2007


   The resulting scenario is the following:


          +------------------------------------+
          |               Internet             |
          +------------------------------------+
             |                   |
           +----+              +----+
           |ISP1|              |ISP2|
           +----+              +----+
             |                   |
          +------------------------------------+
          |   Multihomed Home Network          |
          |   Prefixes: P1 and P2              |
          |                                    |
          |                   Home Agent       |
          |                   //               |
          +------------------//----------------+
                            //
                           //
                         +-----+
                         | MN  | HoA1, HoA2
                         +-----+

                                 Figure 2

   So, in this configuration, the shim6 protocol is used to provide
   multihoming supports to all the nodes within the multihomed sites
   (including the mobile nodes) and the MIPv6 protocol is used to
   support mobility of the mobile nodes of the multihomed site.





















Abley & Bagnulo          Expires January 9, 2008               [Page 10]

Internet-Draft        Shim6 Applicability Statement            July 2007


   The proposed protocol architecture would be the following:


       +--------------+
       |  Application |
       +--------------+
       |  Transport   |
       +--------------+
       |      IP      |
       | +----------+ |
       | |  IPSec   | |
       | +----------+<--ULIDs
       | | shim6    | |
       | +----------+<--HoAs
       | | MIPv6    | |
       | +----------+<--CoAs
       |              |
       +--------------+


                                 Figure 3

   In this architecture, the upper layer protocols and IPSec would use
   ULIDs of the shim6 protocol.  Only the HoAs will be presented to the
   shim6 layer as potential ULIDs.  The shim6 protocol will then be used
   to provide failover between different HoAs.  This is useful to
   preserve established communications when an outage affects the path
   through the ISP that has delegated the HoA used for initiating the
   communication (similarly to the case of a host within a multihomed
   site).  The CoAs are not presented to the shim6 layer and are not
   included in the local locator set in this case.  The CoAs are managed
   by the MIPv6 layer, that binds each HoA to a CoA.

   So, in this case, the ULP select a ULID pair for the communication.
   The shim6 protocol translates the ULID pair to an alternative locator
   is case that is needed.  Both the ULIDs and the alternative locators
   are HoAs.  Next, the MIPv6 layer maps the selected HoA to the
   corresponding CoA, and this is the actual address included in the
   wire.

   The shim6 context is established between the MN and the CN, and it
   would allow the communication to use all the available HoAs to
   provide fault tolerance.  The MIPv6 protocol is used between the MN
   and the HA in the case of the bidirectional tunnel mode and between
   the MN and the CN in case of the RO mode.






Abley & Bagnulo          Expires January 9, 2008               [Page 11]

Internet-Draft        Shim6 Applicability Statement            July 2007


5.1.2.  shim6 Between the HA and the MN

   Another scenario where a shim6-MIPv6 interaction may be useful is the
   case where a shim6 context is established between the MN and the Home
   Agent (HA) in order to provide fault tolerance capabilities to the
   bidirectional tunnel between them.

   Consider the case where the HA has multiple addresses (whether
   because the Home Network is multihomed or because the HA has multiple
   interfaces) and/or the MN has multiple addresses (whether because the
   visited network is multihomed or because the MN has multiple
   interfaces).  In this case, if a failure affects the address pair
   that is being used to run the tunnel between the MN and HA,
   additional mechanisms need to be used to preserve the communication.

   One possibility would be to use MIPv6 capabilities, by simply
   changing the CoA used as the tunnel endpoint.  However, MIPv6 lacks
   of failure detection mechanisms that would allow the MN and/or the HA
   to detect the failure and trigger the usage of an alternative
   address. shim6 provides such failure detection protocol, so one
   possibility would be re-use the failure detection function from the
   shim6 failure detection protocol in MIPv6.  In this case, the shim6
   protocol wouldn't be used to create shim6 context and provide fault
   tolerance, but just the failure detection functionality would be re-
   used.

   The other possibility would be to use the shim6 protocol to create a
   shim6 context between the HA and the MN so that the shim6 detects any
   failure and re-homes the communication in a transparent fashion to
   MIPv6.  In this case, the shim6 protocol would be associated to the
   tunnel interface.

5.2.  shim6 and SeND

   Secure Neighbour Discovery (SeND) [RFC3971] uses CGAs to prove
   address ownership for Neighbour Discovery [RFC2461].  The shim6
   protocol can use either CGAs or HBAs to protect locator sets included
   in shim6 contexts.  It is expected that some hosts will need to
   participate in both SeND and shim6 simultaneously.

   In the case that both the SeND and shim6 protocols are using the CGA
   technique to generate addresses, then there is no conflict: the host
   will generate addresses for both purposes as CGAs, and since it will
   be in control of the associated private key, the same CGA can be used
   for the different protocols.

   In the case that a shim6-capable host is using HBAs to protect its
   locator sets, the host will need to generate hybrid HBA/CGA addresses



Abley & Bagnulo          Expires January 9, 2008               [Page 12]

Internet-Draft        Shim6 Applicability Statement            July 2007


   as defined in [I-D.ietf-shim6-hba] and discussed briefly in
   Section 3.4.  In this case, the CGA Parameter Data Structure
   containing a valid public key and the Multi-Prefix extension is
   included as inputs to the hash function.

5.3.  shim6 and SCTP

   The SCTP [RFC2960] protocol provides a reliable, stream-based
   communications channel between two hosts which provides a superset of
   the capabilities of TCP.  One of the notable features of SCTP is that
   it allows the exchange of endpoint addresses between hosts, and is
   able to recover from the failure of a particular endpoint pair in a
   manner which is conceptually similar to locator selection in shim6.

   SCTP is a transport-layer protocol, higher in the protocol stack than
   shim6, and hence there is no fundamental incompatibility which would
   prevent a shim6-capable host from communicating using SCTP.

   However, since SCTP and shim6 both aim to exchange addressing
   information between hosts in order to meet the same general goal, it
   is possible that their simultaneous use might result in unexpected
   behaviour, e.g. due to race conditions.

   The capabilities of SCTP with respect to path maintenance of a
   reliable, connection-oriented stream protocol are more extensive than
   the more general layer-3 locator agility provided by shim6.  It is
   recommended that shim6 is not used for SCTP sessions, and that path
   maintenance is provided solely by SCTP.  There are at least two ways
   to implement this behaviour.  One option would be the stack, and in
   particular the shim6 sublayer knows when a socket is SCTP and then
   does not creates a shim6 context in this case.  The other option is
   that the upper layer, SCTP in this case, informs using a shim6
   capable API like the one proposed in
   [I-D.sugimoto-multihome-shim-api] that no shim6 context must be
   created for this particular communication.

5.4.  shim6 and NEMO

   The NEMO [RFC3963] protocol extensions to MIPv6 allow a Mobile
   Network to communicate through a bidirectional tunnel via a Mobile
   Router (MR) to a NEMO-compliant Home Agent (HA) located in a Home
   Network.

   If either or both of the MR or HA are multi-homed, then a shim6
   context established between them preserves the integrity of the
   bidirectional tunnel between them in the event that a transit failure
   occurs between them.  The MR in this case can be considered to be
   immobile either side of the failure event, and the shim6 protocol



Abley & Bagnulo          Expires January 9, 2008               [Page 13]

Internet-Draft        Shim6 Applicability Statement            July 2007


   provides a stable pair of ULIDs for the tunnel endopints.

   Once the tunnel between MR and HA is established, hosts within the
   Mobile Network which are shim6-capable can establish contexts with
   remote hosts in order to receive the same multi-homing benefits as
   any host located within the Home Network.

5.5.  shim6 and HIP

   shim6 and the Host Identity Protocol (HIP) HIP [RFC4423] are
   architecturally similar in that both solutions allow a host,
   communicating with another like-enabled host, to use possibly
   multiple or different locators to support communications between
   stable ULIDs.  The signalling exchange to establish demultiplexing
   context on both hosts is very similar between the two protocols.
   However, there are a few key differences.  First, shim6 avoids
   defining a new namespace for ULIDs, preferring instead to use a
   routable locator as a ULID, while HIP uses public keys and hashes
   thereof as ULIDs.  The use of a routable locator as ULID better
   supports deferred context establishment, application callbacks, and
   application referrals, and avoids management and resolution costs of
   a new namespace, but requires additional security mechanisms to
   securely bind the ULID with the locators.  In HIP, the use of a
   public key or hash as a ULID allows the context establishment
   protocol to use the key to sign messages that bind the key to the
   locators.  Second, shim6 uses an explicit context header on data
   packets for which the ULIDs differ from the locators in use (this
   header is only needed after a failure/rehoming event occurs), while
   HIP compresses this context tag into the ESP SPI field of a BEET-mode
   security association BEET [I-D.nikander-esp-beet-mode].  Third, HIP
   as presently defined requires the use of public-key operations in its
   signalling exchange and ESP encryption in the data plane, while the
   use of shim6 requires neither (if only HBA addresses are used).  HIP
   by default provides data protection, while this is non-goal for
   shim6.

   The shim6 working group was chartered to provide a solution to a
   specific problem while minimizing deployment disruption, while HIP is
   considered more of an experimental approach intended to solve several
   more general problems (mobility, multihoming, loss of end-to-end
   addressing transparency) through an explicit identifier/locator
   split.  Communicating hosts that are willing and interested to run
   HIP (perhaps extended with shim6's failure detection protocol) likely
   have no reason to also run shim6.  In this sense, HIP may be viewed
   as a possible long-term evolution or extension of the shim6
   architecture, or one possible implementation of the extended shim6
   design ESD [I-D.nordmark-shim6-esd].




Abley & Bagnulo          Expires January 9, 2008               [Page 14]

Internet-Draft        Shim6 Applicability Statement            July 2007


6.  Security Considerations

   This section considers the applicability of the shim6 protocol from a
   security perspective.  This means, what security features can expect
   applications and users of the shim6 protocol.

   First of all, it should be noted that the shim6 protocol is not a
   security protocol, like for instance HIP.  This means that as opposed
   to HIP, it is an explicit non goal of the shim6 protocol to provide
   enhanced security for the communications that use the shim6 protocol.
   The goal of the shim6 protocol design, in temrs of security is not to
   introduce new vulnerabilities that were not present in the current
   non-shim6 enabled communications.  In particular, it is an explicit
   non goal of the shim6 protocol security not to provide protection
   from on path attackers.  On path attackers are able to sniff and
   spoof packets in the current Internet, and they are able to do the
   same in shim6 communications (as long as the communication flows
   through the path they are located on).  So, summarizing, the shim6
   protocol does not provide data packet protection from on-path
   attackers.

   However, the shim6 protocol does provide several security techniques.
   The goals of these security measures is to protect the shim6
   signalling protocol in order to prevent enabling new attacks through
   the adoption of the shim6 protocol.  In particular, the usage of the
   HBA/CGA technique, prevents on-path and off-path attackers to
   introduce new locators in the locator set of a shim6 context,
   preventing redirection attacks.  Moreover, the usage of probes before
   using a locator as a destination address prevents flooding attacks
   from off-path attackers.

   In addition, the usage of a 4-way handshake for establishing the
   shim6 context protects against DoS attacks, so hosts implementing the
   shim6 protocol should not be more vulnerable to DoS attacks than
   regular IPv6 hosts.

   Finally, other shim6 signalling messages contain the context tag,
   meaning that only attackers that know the context tag can forge them.
   This means that only on-path attackers can generate false shim6
   signalling packets for an established context.  The impact of this
   attacks would be limited since they wouldn't be able to add
   additional locators to the locator set (because of the HBA/CGA
   protection).  In general the possible attacks have similar effects to
   the ones that an on-path attacker can launch on any regular IPv6
   communication.  The residual threats are described in the Security
   Considerations of the shim6 protocol specification
   [I-D.ietf-shim6-proto].




Abley & Bagnulo          Expires January 9, 2008               [Page 15]

Internet-Draft        Shim6 Applicability Statement            July 2007


6.1.  Privacy Considerations

   The shim6 protocol is designed to provide some basic privacy
   features.  In particular, HBAs are generated in such a way, that the
   different addresses assigned to a host cannot be trivially linked
   together as belonging to the same host, since there is nothing in
   common in the addresses themselves.  Similar features are provided
   when the CGA protection is used.  This means that it is not trivial
   to determine that a set of addresses is assigned to a single shim6
   host.

   However, the shim6 protocol does exchange the locator set in clear
   text and it also uses a fixed context tag when using different
   locators in a given context.  This implies that an attacker that can
   observe the shim6 context establishment exchange or that can see
   different payload packets exchanged through different locators, but
   with the same context tag can determine the set of addresses assigned
   to a host.  However this requires that the attacker is located along
   the path and that he can capture the shim6 signalling packets.  A
   more in depth analysis of the privacy of the shim6 protocol can be
   found in [I-D.bagnulo-shim6-privacy].


7.  Contributors

   The anlysis on the interaction between the shim6 protocol and the
   other protocols presented in this note benefited from the advice of
   various people including Tom Henderson, Erik Nordmark, Hesham
   Soliman, Vijay Devarpalli, John Loughney and Dave Thaler.


8.  Acknowledgements

   Joe Abley's work was supported in part by the US National Science
   Foundation (research grant SCI-0427144) and DNS-OARC.

   Marcelo Bagnulo worked on this document while visiting Ericsson
   Research Laboratory Nomadiclab.

   Shinta Sugimoto reviewed this document and provided comments and
   text.

   Iljitsch van Beijnum, Brian Carpenter, Sam Xia reviewed this document
   and provided comments.


9.  References




Abley & Bagnulo          Expires January 9, 2008               [Page 16]

Internet-Draft        Shim6 Applicability Statement            July 2007


9.1.  Normative References

   [I-D.ietf-shim6-failure-detection]
              Arkko, J. and I. Beijnum, "Failure Detection and Locator
              Pair Exploration Protocol for IPv6  Multihoming",
              draft-ietf-shim6-failure-detection-08 (work in progress),
              June 2007.

   [I-D.ietf-shim6-hba]
              Bagnulo, M., "Hash Based Addresses (HBA)",
              draft-ietf-shim6-hba-03 (work in progress), May 2007.

   [I-D.ietf-shim6-proto]
              Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work
              in progress), April 2007.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

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

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.



Abley & Bagnulo          Expires January 9, 2008               [Page 17]

Internet-Draft        Shim6 Applicability Statement            July 2007


   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

9.2.  Informative References

   [I-D.bagnulo-ipv6-rfc3484-update]
              Bagnulo, M., "Updating RFC 3484 for multihoming support",
              draft-bagnulo-ipv6-rfc3484-update-00 (work in progress),
              December 2005.

   [I-D.bagnulo-shim6-privacy]
              Bagnulo, M., "Privacy Analysis for the SHIM6 protocol",
              draft-bagnulo-shim6-privacy-01 (work in progress),
              October 2006.

   [I-D.nikander-esp-beet-mode]
              Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", draft-nikander-esp-beet-mode-06
              (work in progress), August 2006.

   [I-D.nordmark-shim6-esd]
              Nordmark, E., "Extended Shim6 Design for ID/loc split and
              Traffic Engineering", draft-nordmark-shim6-esd-00 (work in
              progress), February 2006.

   [I-D.sugimoto-multihome-shim-api]
              Komu, M., "Socket Application Program Interface (API) for
              Multihoming Shim", draft-sugimoto-multihome-shim-api-00
              (work in progress), June 2006.

   [RFC3221]  Huston, G., "Commentary on Inter-Domain Routing in the
              Internet", RFC 3221, December 2001.

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

   [RFC4116]  Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
              Gill, "IPv4 Multihoming Practices and Limitations",
              RFC 4116, July 2005.









Abley & Bagnulo          Expires January 9, 2008               [Page 18]

Internet-Draft        Shim6 Applicability Statement            July 2007


Authors' Addresses

   Joe Abley
   Afilias Canada, Inc.
   Suite 204
   4141 Yonge Street
   Toronto, Ontario  M2P 2A8
   Canada

   Phone: +1 416 673 4176
   Email: jabley@ca.afilias.info
   URI:   http://afilias.info/


   Marcelo Bagnulo
   Huawei Labs at UC3M
   Av. Universidad 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91 6248814
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es/




























Abley & Bagnulo          Expires January 9, 2008               [Page 19]

Internet-Draft        Shim6 Applicability Statement            July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Abley & Bagnulo          Expires January 9, 2008               [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/