[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

MMUSIC                                                           D. Wing
Internet-Draft                                                  P. Patil
Intended status: Standards Track                                T. Reddy
Expires: January 10, 2013                                          Cisco
                                                            July 9, 2012


                        Mobility with ICE (MICE)
                   draft-wing-mmusic-ice-mobility-00

Abstract

   This specification describes how endpoint mobility can be achieved
   using ICE.  Two mechanisms are shown, one where both endpoints
   support ICE and another where only one endpoint supports ICE.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 10, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Wing, et al.            Expires January 10, 2013                [Page 1]


Internet-Draft                    MICE                         July 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Mobility using ICE  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Mobility using TURN . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Creating an Allocation  . . . . . . . . . . . . . . . . . . 5
       4.1.1.  Sending an Allocate Request . . . . . . . . . . . . . . 5
       4.1.2.  Receiving an Allocate Request . . . . . . . . . . . . . 5
       4.1.3.  Receiving an Allocate Success Response  . . . . . . . . 5
       4.1.4.  Receiving an Allocate Error Response  . . . . . . . . . 5
     4.2.  Refreshing an Allocation  . . . . . . . . . . . . . . . . . 6
       4.2.1.  Sending a Refresh Request . . . . . . . . . . . . . . . 6
       4.2.2.  Receiving a Refresh Request . . . . . . . . . . . . . . 6
       4.2.3.  Receiving a Refresh Response  . . . . . . . . . . . . . 7
     4.3.  New STUN Attributes . . . . . . . . . . . . . . . . . . . . 7
       4.3.1.  MOBILITY-REQUEST  . . . . . . . . . . . . . . . . . . . 7
       4.3.2.  MOBILITY-TICKET . . . . . . . . . . . . . . . . . . . . 7
     4.4.  New STUN Error Response Codes . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


























Wing, et al.            Expires January 10, 2013                [Page 2]


Internet-Draft                    MICE                         July 2012


1.  Introduction

   When moving between networks, an endpoint has to change its IP
   address.  This change breaks upper layer protocols such as TCP and
   RTP.  Various techniques exist to prevent this breakage, all tied to
   making the endpoint's IP address static by using tunnels (Mobile IP,
   Proxy Mobile IP, LISP).  Other techniques exist, which make the upper
   layer protocol ambivalent to IP address changes (e.g., SCTP).  The
   mechanisms described in this document are in that last category.

   To overcome NAT and Firewall traversal issues, hosts may choose to
   use the services of a TURN server that acts as a relay to exchange
   packets with other hosts [RFC5766].  Relaying is also used for IPv6
   privacy.  Clients allocate an IP address and port on the TURN server,
   called the relayed transport address, for a specific client IP
   address and port.  Both the client and the server remember the
   5-tuple used in the Allocate request and all subsequent transactions
   between the client and the server use the same 5-tuple.  When an IP
   address of a client changes because of movement to a new network, the
   existing allocation on the TURN server cannot be re-used and the
   client will have to allocate a second relayed transport address by
   creating a second allocation using a different 5-tuple.  This will
   break connection between the client and its peer.  Communication
   between the client and its peer can only continue when the new
   relayed transport address is signaled to the peer.

   This document proposes two mechanisms to achieve RTP mobility: a
   mechanism where both endpoints support ICE, and a mechanism where
   only one endpoint supports ICE.  When both endpoints support ICE, ICE
   itself can be used to provide mobility.  When only one endpoint
   supports ICE, a TURN server provides mobility.  Both mobility
   techniques work across and between network types (e.g., between 3G
   and wired Internet access), so long as the client can still access
   the remote ICE peer or TURN server.


2.  Notational Conventions

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

   This note uses terminology defined in [RFC5245].


3.  Mobility using ICE

   When both endpoints support ICE, ICE itself can provide mobility.



Wing, et al.            Expires January 10, 2013                [Page 3]


Internet-Draft                    MICE                         July 2012


   [[more text will be written here.]]


4.  Mobility using TURN

   To achieve mobility, a TURN client should be able to retain an
   allocation on the TURN server across changes in the client IP address
   as a consequence of movement to other networks.

   When the client sends the initial Allocate request to the TURN
   server, it will also include a new STUN attribute MOBILITY-REQUEST
   which indicates that the client is a mobile node.  The TURN server
   provisions a ticket that is sent inside a new STUN attribute
   MOBILITY-TICKET in the Allocate Success response to the client.  The
   ticket will be used by the client when it wants to refresh the
   allocation but with a new client IP address and port.  It also
   ensures that the allocation can only be refreshed this way by the
   same client.  When a client's IP address changes due to mobility, it
   presents the previously obtained ticket in a Refresh Request to the
   TURN server.  If the ticket is found to be valid, the TURN server
   will retain the same relayed address/port for the new IP address/port
   allowing the client to continue using previous channel bindings.  Any
   data from external peer will be delivered by the TURN server to this
   new IP address/port of the client.  The TURN client will continue to
   send application data to its peers using the previously allocated
   channelBind Requests.

     TURN                                 TURN           Peer
     client                               server          A
       |-- Allocate request --------------->|             |
       |   + MOBILITY-REQUEST               |             |
       |                                    |             |
       |<--------------- Allocate failure --|             |
       |                 (401 Unauthorized) |             |
       |                                    |             |
       |-- Allocate request --------------->|             |
       |   + MOBILITY-REQUEST               |             |
       |                                    |             |
       |<---------- Allocate success resp --|             |
       |            + MOBILITY-TICKET       |             |
      ...                                  ...           ...
   (changes IP address)
       |                                    |             |
       |-- Refresh request ---------------->|             |
       |   + MOBILITY-TICKET                |             |
       |                                    |             |
       |<----------- Refresh success resp --|             |
       |   + MOBILITY-TICKET                |             |



Wing, et al.            Expires January 10, 2013                [Page 4]


Internet-Draft                    MICE                         July 2012


       |                                    |             |

4.1.  Creating an Allocation

4.1.1.  Sending an Allocate Request

   In addition to the process described in Section 6.1 of [RFC5766], the
   client includes the MOBILITY-REQUEST attribute indicating that the
   client is a mobile node.

4.1.2.  Receiving an Allocate Request

   In addition to the process described in Section 6.2 of [RFC5766], the
   server does the following:

   If the MOBILITY-REQUEST attribute is included and the TURN session
   mobility is forbidden by local policy, the server MUST reject the
   request with a TBD (Mobility Forbidden) error.  Following the rules
   specified in [RFC5389], if the server does not understand the
   MOBILITY-REQUEST attribute, it generates an Allocate error response,
   which includes an ERROR-CODE attribute with 420 (Unknown Attribute)
   response code.  This response will contain an UNKNOWN-ATTRIBUTE
   attribute listing the unknown MOBILITY-REQUEST attribute.

   If the server can successfully process the request create an
   allocation, the server replies with a success response that includes
   a STUN MOBILITY-TICKET attribute.  TURN server stores it's session
   state, such as 5-tuple and NONCE, into a ticket that is encrypted by
   a key known only to the TURN server and sends the ticket in the STUN
   MOBILITY-TICKET attribute as part of Allocate success response.

   The ticket is opaque to the client, so the structure is not subject
   to interoperability concerns, and implementations may diverge from
   this format.  TURN Allocation state information is encrypted using
   128-bit key for Advance Encryption Standard (AES) and 256-bit key for
   HMAC-SHA-256 for integrity protection.

4.1.3.  Receiving an Allocate Success Response

   In addition to the process described in Section 6.3 of [RFC5766], the
   client will store the MOBILITY-TICKET attribute, if present, from the
   response.  This attribute will be presented by the client to the
   server during a subsequent Refresh request to aid mobility.

4.1.4.  Receiving an Allocate Error Response

   If the client receives an Allocate error response with error code TBD
   (Mobility Forbidden), the error is processed as follows:



Wing, et al.            Expires January 10, 2013                [Page 5]


Internet-Draft                    MICE                         July 2012


   o TBD (Mobility Forbidden): The request is valid, but the server is
   refusing to perform it, likely due to administrative restrictions.
   The client considers the current transaction as having failed.  The
   client MAY notify the user or operator and SHOULD NOT retry the same
   request with this server until it believes the problem has been
   fixed.

   All other error responses must be handled as described in [RFC5766].

4.2.  Refreshing an Allocation

4.2.1.  Sending a Refresh Request

   If a client wants to refresh an existing allocation and update its
   time-to-expiry or delete an existing allocation, it will send a
   Refresh Request as described in Section 7.1 of [RFC5766].  If the
   client wants to retain the existing allocation in case of IP change,
   it will include the MOBILITY-TICKET attribute received in the
   Allocate Success response.  If a Refresh transaction was previously
   made, the MOBILITY-TICKET attribute received in the Refresh Success
   response of the transaction must be used.

4.2.2.  Receiving a Refresh Request

   In addition to the process described in Section 7.2 of [RFC5766], the
   client does the following:

   If the STUN MOBILITY-TICKET attribute is included in the Refresh
   Request then the server will not retrieve the 5-tuple from the packet
   to identify an associated allocation.  Instead TURN server will
   decrypt the received ticket, verify the ticket's validity and
   retrieve the 5-tuple allocation from the contents of the ticket.  If
   this 5-tuple obtained from the ticket does not identify an existing
   allocation then the server MUST reject the request with an error.

   If the source IP address and port of the Refresh Request is different
   from the stored 5-tuple allocation, the TURN server proceeds with
   checks to see if NONCE in the Refresh request is the same as the one
   provided in the ticket.  The TURN server also uses MESSAGE-INTEGRITY
   validation to identify the that it is the same user which had
   previously created the TURN allocation.  If the above checks are not
   successful then server MUST reject the request with a 441 (Wrong
   Credentials) error.

   If all of the above checks pass, the TURN server understands that the
   client has moved to a new network and acquired a new IP address.  The
   source IP address of the request could either be the host transport
   address or server-reflexive transport address.  The server then



Wing, et al.            Expires January 10, 2013                [Page 6]


Internet-Draft                    MICE                         July 2012


   updates it's 5-tuple with the new client IP address and port.  TURN
   server calculates the ticket with the new 5-tuple and sends the new
   ticket in the STUN MOBILITY-TICKET attribute as part of Refresh
   Success response.

4.2.3.  Receiving a Refresh Response

   In addition to the process described in Section 7.3 of [RFC5766], the
   client will store the MOBILITY-TICKET attribute, if present, from the
   response.  This attribute will be presented by the client to the
   server during a subsequent Refresh Request to aid mobility.

4.3.  New STUN Attributes

4.3.1.  MOBILITY-REQUEST

   This attribute is used by the client to indicate to the TURN server
   that it is a mobile node.  This attribute has no value part and thus
   the attribute length field is 0.

4.3.2.  MOBILITY-TICKET

   This attribute is used to retain an Allocation on the TURN server.
   It is exchanged between the client and server to aid mobility.  The
   value is encrypted and identifies identifies session state such as
   5-tuple and NONCE.  The value of MOBILITY-TICKET is a variable-length
   value.

4.4.  New STUN Error Response Codes

   This document defines the following new error response codes:

   TBD (Mobility Forbidden): Mobility request was valid but cannot be
   performed due to administrative or similar restrictions.


5.  IANA Considerations

   This note requests of the IANA to add attributes MOBILITY-REQUEST and
   MOBILITY-TICKET to the TURN attribute registry.  The note also
   requires reservation of a new error code for error Mobility
   Forbidden.


6.  Security Considerations

   TURN server MUST use strong encryption and integrity protection for
   the ticket to prevent an attacker from using a brute force mechanism



Wing, et al.            Expires January 10, 2013                [Page 7]


Internet-Draft                    MICE                         July 2012


   to obtain the ticket's contents or refreshing allocations.

   Security considerations described in [RFC5766] are also applicable to
   this mechanism.


7.  References

7.1.  Normative References

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

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

7.2.  Informative References

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC5768]  Rosenberg, J., "Indicating Support for Interactive
              Connectivity Establishment (ICE) in the Session Initiation
              Protocol (SIP)", RFC 5768, April 2010.


Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com





Wing, et al.            Expires January 10, 2013                [Page 8]


Internet-Draft                    MICE                         July 2012


   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: praspati@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

































Wing, et al.            Expires January 10, 2013                [Page 9]


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