Network Working Group                                             Z. Zhu
Internet-Draft                                                      UCLA
Intended status: Informational                               R. Wakikawa
Expires: August 21, 2011                                      Toyota ITC
                                                                L. Zhang
                                                                    UCLA
                                                             S. Cheshire
                                                              Apple Inc.
                                                       February 17, 2011


              Understanding Apple's Back to My Mac Service
                     draft-zhu-mobileme-doc-03.txt

Abstract

   This document describes the implementation of Apple Inc.'s Back to My
   Mac (BTMM) service.  BTMM provides network connectivity between
   devices so that a user can perform file sharing and screen sharing
   among multiple computers at home, at work, or on the road.  The
   implementation of BTMM addresses the issues of single sign-on
   authentication, secure data communication, service discovery and end-
   to-end connectivity in face of Network Address Translators (NAT) and
   mobility of devices.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 August 21, 2011.

Copyright Notice

   Copyright (c) 2011 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



Zhu, et al.              Expires August 21, 2011                [Page 1]


Internet-Draft                    BTMM                     February 2011


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  An Overview of Back to My Mac  . . . . . . . . . . . . . . . .  3
   3.  Encoding Host Information in DNS Resource Records  . . . . . .  5
   4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Introduction to NAT-PMP  . . . . . . . . . . . . . . . . .  6
     4.2.  Requesting/Removing a Port Mapping . . . . . . . . . . . .  7
     4.3.  Obtaining NAT box's Public IP Address  . . . . . . . . . .  7
     4.4.  Unsupported Scenarios  . . . . . . . . . . . . . . . . . .  7
   5.  Handling IP Address or Port Changes  . . . . . . . . . . . . .  8
     5.1.  Updating Local Interfaces and Tunnels  . . . . . . . . . .  8
     5.2.  Dynamically Updating Reachability Information  . . . . . .  8
     5.3.  Getting Up-to-Date DNS Resource Records without Polling  .  9
   6.  IPv6 ULA as Host ID  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Reasons for Host Identifiers . . . . . . . . . . . . . . . 11
     6.2.  Discussion: What to Use As Host Identifier . . . . . . . . 11
     6.3.  IPv6 ULA Configuration . . . . . . . . . . . . . . . . . . 11
   7.  Securing Communication . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Authentication for Connecting to Remote Host . . . . . . . 12
     7.2.  Authentication for DNS Exchanges . . . . . . . . . . . . . 12
     7.3.  IPsec for Secure End-to-End Data Communication . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

















Zhu, et al.              Expires August 21, 2011                [Page 2]


Internet-Draft                    BTMM                     February 2011


1.  Introduction

   Apple Inc.'s Back to My Mac (BTMM) service was first shipped with MAC
   OS X 10.5 release in October 2007, since then it has been widely
   used.  BTMM provides an integrated solution to host mobility support,
   NAT traversal, and secure end-to-end data delivery through a
   combination of several existing protocols and software tools instead
   of designing new protocols.  This document describes the
   implementation of BTMM and we hope the reader find it informative.

   BTMM provides secure transport connections among a set of devices
   that may be located over a dynamic and heterogeneous network
   environment.  Independent from whether a user is traveling and
   accessing the Internet via airport WiFi, or staying at home behind a
   NAT, BTMM allows the user to connect to any of his Mac computers with
   a click, after which the user can share files with remote computers
   or control the remote Mac through screen sharing.  When a user moves
   around and changes locations and hence the IP address of his computer
   (e.g. roaming around with a laptop and receiving dynamically
   allocated IP address), BTMM provides a means for the roaming host to
   update its reachability information to keep it reachable by the
   user's other Mac devices.  BTMM maintains end-to-end transport
   connections in face of host IP address changes through the use of
   unique host identifiers.  It also provides means to reach devices
   behind a NAT.

   BTMM achieves the above functions mainly by integrating a set of
   existing protocols and software tools.  It uses DNS-based Service
   Discovery [DNS-SD] to announce host reachability information, dynamic
   DNS update [RFC 2136] to refresh the DNS resource records (RRs) when
   a host detects network changes, and DNS Long-lived Queries (LLQ)
   [DNS-LLQ] to notify hosts immediately when the answers to their
   earlier DNS queries have changed.  BTMM uses IPv6 Unique Local
   Address(ULA) [RFC 4193] as the host identifier, and employs the NAT
   Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal.  It
   uses Kerberos [RFC 4120] for end-to-end authentication, and uses
   IPsec [RFC 4301] to secure data communications between two end hosts.


2.  An Overview of Back to My Mac

   To keep an established TCP connection running while either of the two
   end hosts may change its IP address requires that the connection use
   unique and stable identifiers that do not change with the addresses,
   and that a mapping service exists between these stable identifiers
   and dynamically changing IP addresses.  BTMM uses DNS to provide this
   mapping service.  Figure 1 provides a sketch of the basic components
   in the BTMM implementation.



Zhu, et al.              Expires August 21, 2011                [Page 3]


Internet-Draft                    BTMM                     February 2011


           DDNS update    +--------+  DDNS update
         +--------------->|        |<-------+
         |                |  DNS   |        |
         |      LLQ       |        | LLQ    |
         |    +---------->|        |<----+  |
         |    |           |        |     |  |
         |    |           +--------+     |  |
         |    |                          |  |            +----------+
         |    V                      +---+--+----+       |          |
       +-+-------+                   |           +-------|          |
       |Endhost N|     Tunnel        |    NAT    +------>|Endhost M |
       |         |<=====================================>|          |
       +---------+                   |           |       |          |
                                     +-----------+       +----------+

                                 Figure 1

   Apple Inc. operates a DNS domain called members.me.com, and provides
   DNS name resolution services for all the subdomains underneath.
   Every BTMM user is assigned a DNS subdomain under members.me.com,
   e.g. alice.members.me.com.  The user then assigns a DNS name for each
   of her computers, e.g. myMacPro.alice.members.me.com.  The
   reachability information of each of the user's machines is encoded in
   DNS resources records and published in the DNS.  For example, If the
   machine myMacPro.alice.members.me.com has a public IPv4 address P, P
   represents the reachability information to the machine.  On the other
   hand, if the machine is behind an NAT, its reachability information
   is composed of the public IP address of the NAT box and the port
   number opened on the NAT to reach the internal host.  In this case
   both the public IP address of the NAT box and the port number are
   encoded into DNS using DNS SRV records [RFC 2782], as we explain in
   the next section.  When a user logs in from a machine M, M starts
   updating the DNS server about its reachability information.  If the
   user has multiple machines, M also sets up LLQs with the DNS server
   for her other machines, so that the DNS server can push any
   reachability changes of these other machines to M immediately.

   To obtain a unique identifier for each host, BTMM automatically
   generates an IPv6 ULA for each host as its identifier at machine boot
   time.  This design choice allows BTMM to reuse all the existing code
   of applications and protocols that already support IPv6.  To ensure
   end-to-end data security, BTMM leverages the existing IPsec to
   protect the communications, and Kerberos to perform end-to-end
   authentication.

   BTMM provides an IPv6 socket interface to user applications.  It then
   wraps the IPv6 packets with IPSec ESP [RFC 2406], and encapsulates
   the packets in a UDP/IP tunnel, as illustrated in Figure 2.  Note



Zhu, et al.              Expires August 21, 2011                [Page 4]


Internet-Draft                    BTMM                     February 2011


   that this is the case even when both ends have public IPv4 addresses.


    +-------------+------------+------------+---------------+
    | IPv4 Header | UDP Header | IPsec ESP  | IPv6 Packet   |
    +-------------+------------+------------+---------------+

                                 Figure 2

   The following sections describe each of the basic components in BTMM.
   Since this document is intended to be an informal description of the
   BTMM implementation, it does not include all the details (e.g. packet
   format, error code, etc) of each component.


3.  Encoding Host Information in DNS Resource Records

   For each host, BTMM encodes into DNS both the host identifier and its
   current location information.  BTMM stores the host identifier (IPv6
   ULA) in a DNS AAAA RR, and uses a DNS SRV RR [RFC 2782] to represent
   the host's current location information.  For hosts behind a NAT box,
   the use of a DNS SRV RR allows BTMM to store both the public IP
   address of the NAT box and also the port opened for the host.

   The SRV RR consists of seven fields: _Service._Proto.Name, TTL,
   Class, Type, Priority, Weight, Port, and Target.  BTMM uses SRV RRs
   in the following way.

   Service is the symbolic name of the desired service.  In BTMM case,
   the service is named "autotunnel", which means that the information
   contained in the SRV RR is used by BTMM to automatically set up a
   tunnel between two end hosts.

   Proto is the symbolic name of desired protocol.  Typically it is
   either "_tcp" or "_udp".  BTMM uses "_udp" to tunnel packets between
   the two ends to achieve NAT traversal.

   Name is the domain this RR refers to.  When a user subscribes to BTMM
   service with the username "alice", a domain name
   "alice.members.me.com" is assigned to her.  The user assigns a name,
   such as "myMacPro", to each machine which is appended to the assigned
   domain name.  Hence, the first part of SRV record would look like
   "_autotunnel._udp.myMacPro.alice.members.me.com".

   Priority and Weight are set to zero, since there is only one instance
   that provides "autotunnel" service for each name in BTMM.

   Port is the port opened on the target host of the service.  In BTMM,



Zhu, et al.              Expires August 21, 2011                [Page 5]


Internet-Draft                    BTMM                     February 2011


   most likely it is the external port a NAT opened for the host behind
   it.  Knowing the port number is the basic requirement for NAT
   traversal via UDP encapsulation.  If the host is not behind a NAT,
   the port opened on the host for autotunnel service is placed here.

   Target is the canonical hostname of the machine that provides the
   service.  In BTMM it refers to a name constructed by appending the
   user's domain name to an autotunnel label, which identifies the
   machine and is not generally user-visible.  The autotunnel label is
   created by concatenating "AutoTunnel" with the IEEE EUI-64 identifier
   [EUI64] of the primary network interface.  Hence, an example for the
   Target field would look like: AutoTunnel-00-22-69-FF-FE-8E-34-
   2A.alice.members.me.com.  After obtaining the SRV RR, the remote host
   can query the A RR for the Target and get the external tunnel address
   for the BTMM client during the NAT Traversal.


4.  NAT Traversal

   BTMM's NAT traversal function requires NAT router devices to support
   NAT-PMP or UPnP IGD.  NAT-PMP is the alternative introduced by Apple
   Inc. to the more common Internet Gateway Device (IGD) Standardized
   Device Control Protocol [IGD] as published in UPnP forum.  Both NAT-
   PMP and IGD require the NAT devices to be able to open a port for
   inbound traffic to some host behind it and to inform the host about
   its public IP address.  The differences between IGD and NAT-PMP can
   be found in [NAT-PMP].  This section focuses on NAT-PMP.

4.1.  Introduction to NAT-PMP

   NAT-PMP is a protocol that is designed specifically to handle the NAT
   traversal without manual configuration.  When a host determines that
   its primary IPv4 address is in one of the private IP address ranges
   defined in "Address Allocation for Private Internets" [RFC1918], it
   invokes NAT-PMP to communicate with the NAT gateway to request the
   creation of inbound mappings on demand.  Having created a NAT mapping
   to allow inbound traffic, the client host then publishes its NAT
   box's public IP address and external port number in a DNS server.

   A host sends its Port Mapping Protocol request to the default
   gateway, which means that by default, this protocol is designed for
   small home networks where the host's default gateway is the NAT
   router.  If the host finds that NAT-PMP or UPnP IGD is not available
   on its network, it would proceed under the assumption that the
   network is a public network.






Zhu, et al.              Expires August 21, 2011                [Page 6]


Internet-Draft                    BTMM                     February 2011


4.2.  Requesting/Removing a Port Mapping

   To request a port mapping, the client host sends its request packet
   to port 5351 of its configured gateway address, and waits 250ms for a
   response.  If no response is received after 250ms, the host repeats
   the process with exponential back-off.

   While requesting the port mapping, the host can specify the desired
   external port (e.g. the port that is identical to the internal port
   opened on the host), but the NAT device is not obliged to allocate
   the desired one.  If such port is not available, NAT device responds
   with another port.  The primary reason for allowing host to request a
   specific port is to help recovery from the NAT device crash, to allow
   the host to request the same port number used before the crash.  This
   simple mechanism allows the end hosts, instead of the NAT box, to
   keep the mapping states, which turns hard state in the network into
   soft state, and enables automatic recovery whenever possible.

   The default port mapping lifetime is 3600 seconds.  The host tries to
   renew the mapping at every 1800 seconds.  The renewal sent by client
   host, whether for the purpose of the extending the lease or
   recreating mappings after NAT device reboots, is the same as
   requesting a port mapping.

   A mapping may be removed in a variety of ways.  If a client host
   fails to renew a mapping, then when its lifetime expires the mapping
   is automatically deleted.  Or if the client host's DHCP address lease
   expires, the NAT device also automatically deletes the mapping.  A
   client host can also send an explicit packet to request the deletion
   of a mapping that is no longer needed.

4.3.  Obtaining NAT box's Public IP Address

   To determine the public IP address of the NAT, the client host also
   sends the query packet to port 5351 of the configured gateway
   address.  NAT device responses with a packet containing the public IP
   address of NAT.

   In case the public IP address of the NAT changes, the NAT gateway
   sends a gratuitous response to the link-local multicast address
   224.0.0.1, port 5350 to notify the clients about the new IP address,
   and the host can then update its DNS SRV record to reflect its new
   reachability as we describe in the next section.

4.4.  Unsupported Scenarios

   There are a number of situations where NAT-PMP (and consequently
   BTMM) does not work.



Zhu, et al.              Expires August 21, 2011                [Page 7]


Internet-Draft                    BTMM                     February 2011


4.4.1.  NAT Behind NAT

   Some people's primary IP address assigned by their ISPs may itself be
   a NAT address.  In addition, some people may have a public IP
   address, but may put their machines (perhaps unknowingly) behind
   multiple nested NAT boxes.  NAT traversal cannot be achieved with
   NAT-PMP in such situations.

4.4.2.  NATs and Routed Private Networks

   In some cases, a site may run subnet in the private network behind a
   NAT gateway.  Such subnetting breaks the assumption of NAT-PMP
   protocol because a host's default router is not necessarily the
   device performing NAT.


5.  Handling IP Address or Port Changes

   This section describes how BTMM handles IP address or port number
   changes, so that the hosts of the same user can find each other and
   keep ongoing TCP connections even after the changes happen at one or
   both ends.

5.1.  Updating Local Interfaces and Tunnels

   After BTMM client receives the notification about the network
   changes, it updates the list of active interfaces.  Then, BTMM sends
   requests to the NAT device (if it is behind a NAT) in order to create
   a port mapping and obtain the new public IP address.

   Next step, BTMM makes changes to the local autotunnel interface, i.e.
   configures the IPv6 interface for the inner address of tunnel.  If
   there are established tunnels, it scans to find those whose local
   inner/outer addresses have been changed since the tunnel was set up,
   and then puts in the current addresses.

   With all these done, now the BTMM client publishes the changes to
   DNS.

5.2.  Dynamically Updating Reachability Information

   The mobile nature of the BTMM clients implies that dynamic DNS update
   is required if the location information of hosts are going to be
   published via DNS.

   However, the dynamically updated RRs are often not properly removed,
   leaving stale RRs in DNS server.  Hence, Dynamic DNS Update Leases
   (DDUL) [DDUL] is employed by BTMM to reduce the impact of stale RRs.



Zhu, et al.              Expires August 21, 2011                [Page 8]


Internet-Draft                    BTMM                     February 2011


   Another possible choice is to overload the RRs' TTL as the removal
   timer.  However, there is a concern about unacceptable amount of
   network traffic due to refreshes if TTL were used to clear stale
   resource record, because TTL is usually set to be very short in order
   to minimize stale cached data in intermediate DNS.

   In case of network changes, the RRs of a host are updated immediately
   after local interfaces are properly configured and port mapping as
   well as the public IP address of the NAT are obtained.  Usually there
   are 4 types of RRs involved.  An AAAA RR for updating the new host
   identifier of the host (possibly the same as the old one); an SRV RR
   for updating the autotunnel service information, which includes the
   new external port; an A RR for updating the new public IP address;
   and a TXT RR for describing the autotunnel device information.  The
   host then constructs and sends an SRV query for the dynamic DNS
   server to which it should send updates.  Following our example for
   alice, it queries the SRV RR for _dns-
   update._udp.alice.members.me.com.  Then the updates are sent to the
   dynamic DNS server returned in the target field of query response.

   Besides that, periodic refreshes are also required by the DDUL even
   though the network has not experienced any change.  The update
   requests contain a signed 32-bit integer indicating the lease life in
   seconds.  To reduce network and server load, a minimum lease of 30
   minutes is required.  On the other hand, to avoid stale information,
   a lease longer than 2 hours is not allowed in BTMM.  The typical
   length is 90 minutes.  RRs not to be deleted by the server are
   refreshed by the client host before the lease expires.

5.3.  Getting Up-to-Date DNS Resource Records without Polling

   In dynamic environments, changes to DNS information are often
   frequent.  How to let the hosts that are concerned about particular
   DNS RRs know the changes efficiently is a challenging question.  In
   traditional DNS, queries are "one-shot" -- a name server will answer
   a query once, returning the results available at that instant in
   time.  Thus, polling is necessary to learn the changes.  This
   solution is not scalable, however, as low polling rate could leave
   the client with stale information and a high polling rate would have
   an adverse impact on the network and server.

   BTMM relies on DNS Long-Lived Queries (LLQ) [DNS-LLQ] to allow the
   DNS server to notify the client host about the changes to DNS data.

   To obtain the LLQ server information, the client also issues an SRV
   query.  So alice's machine issues a query for _dns-
   llq._udp.alice.members.me.com and obtains the server that provides
   LLQ service.  LLQs are initiated by a client and are completed via a



Zhu, et al.              Expires August 21, 2011                [Page 9]


Internet-Draft                    BTMM                     February 2011


   four-way handshake: Initial Request, Challenge, Challenge Response,
   and ACK + Answers.  During the Challenge phase, the DNS server
   provides a unique identifier for the request and the client is
   required to echo this identifier in Challenge Response phase.  This
   handshake provides resilience to packet loss, demonstrates client
   reachability and reduces denial-of-service attack opportunities.

   LLQ lease is negotiated during the handshake.  In BTMM, the minimum
   lease is 15 minutes and the maximum lease is 2 hours.  Leases are
   refreshed before they expire.

   When a change ("event") occurs to a name server's domain, the server
   checks if the new or deleted RRs answer any LLQs.  If so, the RRs are
   sent to the LLQ issuers in the form of a gratuitous DNS response.
   The client acknowledges the reception of the notification; otherwise
   the server re-sends the response.  If a total of 3 transmissions
   fail, the client is considered unreachable and the LLQ is deleted.

   A BTMM client then updates its tunnels according to the query
   answers.  The callback function for automatically updating tunnels is
   depicted Figure 3.


                          1:  Push Updated AAAA RR       +------------+
                   <-----------------------------------  |            |
                       2: Query for autotunnel SRV RR    |            |
       +--------+  ----------------------------------->  |            |
       |        |        3: Reply Updated SRV RR         | DNS server |
       | client |  <-----------------------------------  |            |
       |        |      4: Query for Target in SRV RR     |            |
       +--------+  ----------------------------------->  |            |
                       5: Reply Updated A RR of Target   |            |
                   <-----------------------------------  |            |
                                                         +------------+

            In Step
            1: client learns the inner IP address of the tunnel
            3: client learns the port opened for UDP NAT traversal
            5: client learns the public IP address of the remote NAT,
              i.e. the outer IP address of the tunnel


                                 Figure 3








Zhu, et al.              Expires August 21, 2011               [Page 10]


Internet-Draft                    BTMM                     February 2011


6.  IPv6 ULA as Host ID

6.1.  Reasons for Host Identifiers

   There are a number of reasons why BTMM needs a topology-independent
   identifier for each client host.
   o  A host may be on the move, thus any identifier that is related to
      the topology would be constantly changing, which causes great
      troubles for mobility support and other services.
   o  The two ends may wish to have the established TCP connections
      survive network changes.
   o  Sometimes a constant identifier needs to be associated with a key
      so that the security association can survive the location changes.

6.2.  Discussion: What to Use As Host Identifier

   There are several candidates for host identifiers, such as DNS name,
   Host Identity Tag (HIT) in HIP [RFC 4423], and IPv6 address.  To be
   accurate, the last one should be IPv6 ULA, because the globally
   routable IPv6 addresses are dependent on the topology.  BTMM chooses
   the IPv6 ULA to be the host identifier.

   A very pragmatic concern about introducing a host identifier is: do
   we need to re-write all the protocol and application code?  It would
   be a tedious and error-prone work to migrate all the existing
   implementations.  This gives us a hint: the host identifier should be
   compatible with existing protocol and application implementations,
   e.g. something in the same form and length as IP address.  This rules
   out DNS name, which has variable length.

   For HIP, although publickey-based HIT has the same length as IPv6
   address, we still lack a secure way to retrieve the public keys.
   Under this condition, using HIT would not bring us much benefit.

   On the other hand, with IPv6 ULA as host identifier, all the existing
   code can be used directly.  And since in BTMM all the IPv6 ULAs are
   not leaked to the public network, it would not cause any problem to
   the global routing system.

6.3.  IPv6 ULA Configuration

   In BTMM, IPv6 ULA is advertised to be used in the autotunnel service
   of the host.  Thus, the IPv6 address needs to be configured before
   BTMM starts its service.

   When the machine boots up, the IPv6 address for autotunnel service is
   initialized as zeros and the autotunnel interface is marked as
   inactive.  During the process when BTMM updates the interfaces list



Zhu, et al.              Expires August 21, 2011               [Page 11]


Internet-Draft                    BTMM                     February 2011


   (which is performed every time the network changes), BTMM would
   randomly generate an IPv6 ULA according to [RFC 4193], if the IPv6
   address is found uninitialized.  The first octet of the ULA is set to
   be "0xFD", and the following 7 octets are randomly selected from
   0~255.  Finally, the EUI-64 identifier fills up the rest 8 octets.
   Since there are 56 random bits plus a theoretically unique EUI-64
   identifier, it is unlikely to have the IPv6 ULA collision between any
   two machines of the same subscriber.

   This locally generated ULA keeps unchanged when the machine is on,
   despite its location changes.  Hence the user can fully enjoy the
   benefits brought by topology-independent host identifiers.  After the
   machine is turned off, this particular ULA is no longer kept.


7.  Securing Communication

   BTMM users often have to fetch their personal data via a network they
   don't trust (or have no idea whether it's trustworthy).  Hence, it is
   important for BTMM to have effective means to secure the
   communications.

7.1.  Authentication for Connecting to Remote Host

   Kerberos is a "single sign on" technology and is supported in Apple's
   products since Mac OS X 10.5.  Each Mac OS X client maintains a local
   Key Distribution Center (KDC) for the use of Bonjour and peer-to-peer
   security.

   When the user first signs in to MobileMe on a host, it automatically
   receives from KDC a digital certificate and private key for "Back to
   My Mac Encryption Certificate".  When the user connects to another
   system using BTMM, authentication is performed using the standard
   Public Key Cryptography for Initial Authentication in Kerberos
   (PKINIT) protocol [RFC 4556] with that certificate.  After that, the
   user is granted a "ticket" that permits it to continue to use the
   services on the remote machine, without re-authenticating, until the
   ticket expires, which usually has 10 hours lifetime.

7.2.  Authentication for DNS Exchanges

   BTMM uses Transaction SIGnature (TSIG) to authenticate user when
   dynamic DNS update is performed [RFC 2845].  Also, to protect the
   subscriber's privacy, LLQ is required to contain TSIG.  This
   authentication mechanism is based on the shared secret key, which in
   BTMM's case is derived from the subscriber's MobileMe account
   password.




Zhu, et al.              Expires August 21, 2011               [Page 12]


Internet-Draft                    BTMM                     February 2011


   Every time a DNS request/response is going to be issued, a TSIG RR is
   dynamically computed with HMAC-MD5 message digest algorithm [RFC
   2104] (and the TSIG RR will be discarded once its has been used).
   Inside the TSIG RR, a name of the shared secret key in domain name
   syntax is included, so the receiver knows which key to used
   (especially useful if the receiver is the DNS server).  This TSIG RR
   is appended to the additional data section before the message is send
   out.  The receiver of the message verifies the TSIG RR and proceeds
   only if the TSIG is valid.

   Besides, the DNS messages are also protected by TLS [RFC 2246] to
   prevent eavesdropping.

7.3.  IPsec for Secure End-to-End Data Communication

7.3.1.  Internet Key Exchange

   Before the Security Association can be established between two end
   hosts, Internet Key Exchange (IKE) [RFC 2409] process needs to be
   accomplished.

   BTMM calls Racoon [Racoon], the IKE daemon, to do the key exchange,
   after which the key is put into Security Association Database (SAD).
   The exchange mode is set to be aggressive so that it would not take
   too long.  And it uses pre-shared key to do the user authentication.
   The subscriber's FQDN is used as both identifier and pre-shared key
   during the IKE process.

7.3.2.  Discussion: End-to-End Encryption

   When it comes the time to set up Security Associations between two
   BTMM clients, we have two choices: either to put the other host's
   IPv4 address in the destination address field, or otherwise put in
   the IPv6 address of the remote end.

   If the IPv4 address (which is the public address of a NAT) is chosen
   to associate with a Security Association, that means we set up a
   Security Association between one end host and the NAT of the other
   host.  The IPv6 packet would then be wrapped by UDP header and then
   get encrypted by ESP.  After the encrypted packet arrives at the NAT,
   the NAT device decrypts the packet and sends it to the destination
   according to the port mapping.  Although this approach seems viable,
   there are 3 drawbacks:
   o  First, the encryption is not really end-to-end, i.e. only the path
      between one end host and the NAT device of the other end is
      protected.  The rest of the path, from the NAT device to the other
      BTMM client, is unprotected and vulnerable to attacks.  If the NAT
      device is not trustworthy, the communication is at high risk.



Zhu, et al.              Expires August 21, 2011               [Page 13]


Internet-Draft                    BTMM                     February 2011


      Even if the NAT device is trustworthy (e.g. the user owns the
      NAT), it is not uncommon that the NAT communicates with the host
      through broadcast channel, which provides opportunities for an
      eavesdropper to sniff the sensitive data (consider the unlocked
      "free" WiFi access near your neighborhood).
   o  Second, quite a lot BTMM clients are on the move very often.
      Every time they change their attachment points to the Internet
      they will get different IPv4 addresses.  As a result, the
      previously established Security Associations become obsoleted and
      the two end hosts need to re-establish them again.  This is a
      waste of time and resources.
   o  Third, this approach assumes that the NAT device is able and
      willing to do the IPsec ESP for the host behind it, which is not
      always the case.

   Consequently, BTMM decides to put the IPv6 ULA into the destination
   field of IPsec Security Associations.  In this way, the end-to-end
   path between the hosts are fully protected, and the Security
   Associations survive the network changes since the IPv6 ULA remains
   the same even the BTMM client changes its location.  Furthermore, the
   encryption is transparent to the NAT device, which means the NAT
   device is not required to interfere with the IPsec protection.


8.  References

   [DDUL]     "Dynamic DNS Update Leases", draft -sekar-dns-ul-01.txt.

   [DNS-LLQ]  "DNS Long-Lived Queries",
              draft draft-cheshire-dns-llq-01.txt.

   [DNS-SD]   "DNS-Based Service Discovery",
              draft draft-cheshire-dnsext-dns-sd-08.txt.

   [EUI64]    "Guidelines for 64-bit Global Identifier (EUI-64)", http :
              //standards.ieee.org/regauth/oui/tutorials/EUI64.html.

   [IGD]      "Internet Gateway Device(IGD) Standard Device Control
              Protocol", http ://www.upnp.org/standardizeddcps/igd.asp.

   [NAT-PMP]  "NAT Port Mapping Protocol",
              draft draft-cheshire-nat-pmp-03.txt.

   [RFC 2104]
              "HMAC: Keyed-Hashing for Message Authentication",
              RFC 2104.

   [RFC 2136]



Zhu, et al.              Expires August 21, 2011               [Page 14]


Internet-Draft                    BTMM                     February 2011


              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136.

   [RFC 2246]
              "The TLS Protocol", RFC 2246.

   [RFC 2406]
              "IP Encapsulating Security Payload (ESP)".

   [RFC 2409]
              "The Internet Key Exchange", RFC 2409.

   [RFC 2782]
              "A DNS RR for specifying the location of services (DNS
              SRV)", RFC 2782.

   [RFC 2845]
              "Secret Key Transaction Authentication for DNS (TSIG)",
              RFC 2845.

   [RFC 3948]
              "UDP Encapsulation of IPsec ESP Packets".

   [RFC 4120]
              "The Kerberos Network Authentication Services (V5)",
              RFC 4120.

   [RFC 4193]
              "Unique Local IPv6 Unicast Address", RFC 4193.

   [RFC 4301]
              "Security Architecture for the Internet Protocol",
              RFC 4301.

   [RFC 4423]
              "Host Identify Protocol (HIP) Architecture", RFC 4423.

   [RFC 4556]
              "Public Key Cryptography for Initial Authentication in
              Kerberos (PKINIT)", RFC 4556.

   [RFC1035]  "Domain Names - implementation and specification",
              RFC 1035.

   [RFC1918]  "Address Allocation for Private Internets", RFC 1918.

   [Racoon]   "Racoon", http ://netbsd.gw.com/cgi-bin/
              man-cgi?racoon++NetBSD-current.



Zhu, et al.              Expires August 21, 2011               [Page 15]


Internet-Draft                    BTMM                     February 2011


Authors' Addresses

   Zhenkai Zhu
   UCLA
   4805 Boelter Hall, UCLA
   Los Angeles, CA  90095
   US

   Phone: +1 310 993 7128
   Email: zhenkai@cs.ucla.edu


   Ryuji Wakikawa
   Toyota ITC
   465 Bernardo Avenue
   Mountain View, CA  94043
   US

   Email: ryuji@jp.toyota-itc.com


   Lixia Zhang
   UCLA
   3713 Boelter Hall, UCLA
   Los Angeles, CA  90095
   US

   Phone: +1 310 825 2695
   Email: lixia@cs.ucla.edu


   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   US

   Phone: +1 408 974 3207
   Email: cheshire@apple.com












Zhu, et al.              Expires August 21, 2011               [Page 16]