Internet Engineering Task Force (IETF) S. Cheshire Request for Comments: 6281 Apple Inc. Category: Informational Z. Zhu ISSN: 2070-1721 UCLA R. Wakikawa Toyota ITC L. Zhang UCLA June 2011 Understanding Apple's Back to My Mac (BTMM) Service
AbstractThis 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 the face of Network Address Translators (NATs) and mobility of devices. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6281.
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 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . 8 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. The Need for a Host Identifier . . . . . . . . . . . . . . 11 6.2. What to Use as Host Identifiers . . . . . . . . . . . . . 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. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
DNS-SD] to announce host reachability information, dynamic DNS update [RFC2136] to refresh the DNS resource records (RRs) when a host detects network changes, and DNS Long-Lived Queries (LLQs) [DNS-LLQ] to notify hosts immediately when the answers to their earlier DNS queries have changed. BTMM uses the IPv6 Unique Local Address (ULA) [RFC4193] as the host identifier and employs the NAT Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal. It uses Kerberos [RFC4120] for end-to-end authentication and uses IPsec [RFC4301] to secure data communications between two end hosts. Figure 1 provides a sketch of the basic components in the BTMM implementation.
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 hosts is encoded in DNS resource records and published in the DNS. For example, if the host myMacPro.alice.members.me.com has a public IPv4 address P, P represents the reachability information to the host. On the other hand, if the host is behind a 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 [RFC2782], as we explain in the next section. When a user logs in from a host M, M starts updating the DNS server about its reachability information. If the user has multiple hosts, M also sets up LLQs with the DNS server for her other hosts, so that the DNS server can push any reachability changes of these other hosts 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 Encapsulating Security Payload (ESP) [RFC4303] and encapsulates the packets in a UDP/IP tunnel, as illustrated in Figure 2. Note 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. RFC2782] 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 eight fields: _Service._Proto.Name, Time to Live (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 the 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 the desired protocol. In this document, the protocol is "_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 host that is appended to the assigned domain name. Hence, the first part of the SRV record would look like this: "_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, 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 host 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 host 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 this: 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. IGD] as published in the 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. 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.
NAT-PMP]. If no response is received after 250 ms, 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 a port is not available, the NAT device responds with another port. The primary reason for allowing the host to request a specific port is to help recovery from a NAT device crash by allowing 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 every 1800 seconds. The renewal message sent by the client host, whether for the purpose of extending the lease or recreating mappings after the NAT device reboots, is the same as the message requesting a port mapping. A mapping may be removed in a variety of ways. If a client host fails to renew a mapping, the mapping is automatically deleted when its lifetime expires. 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.
However, a mobile host may have dynamically updated an RR but the updated value has not been propagated to the authoritative DNS server, leaving stale RRs in the server. Hence, Dynamic DNS Update Leases (DDULs) [DDUL] are employed by BTMM to minimize the chances of stale RRs. Note that DDUL controls the lifetime of dynamically updated RRs at the authoritative DNS servers, while the RRs' TTL values control the cache lifetime at caching resolvers. In case of network changes, the RRs of a host are updated immediately after local interfaces are properly configured, and after the port mapping and the public IP address of the NAT are obtained. Usually there are 4 types of RRs involved: a 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 name for the SRV RR is discussed in Section 3, and the names for the A, AAAA, and TXT RRs are specified in the Target field of the SRV RR. 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-tls._udp.alice.members.me.com. Then, the updates are sent to the dynamic DNS server returned in the Target field of query response. In addition, periodic refreshes are also required by the DDUL even in the absence of any network changes. 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. The client host refreshes the RRs before the lease expires to prevent them from being deleted by the server. DNS-LLQ] to let the DNS server notify the client host once any changes are made to the concerned DNS data.
To obtain the LLQ server information, the client issues an SRV query. So alice's host issues a query for _dns-llq-tls._udp.alice.members.me.com and obtains the server that provides LLQ service. LLQs are initiated by a client and are completed via a 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 the 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 resends the response. If a total of 3 transmissions (with exponential backoff) 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. In Step 3: Client learns the port opened for UDP NAT traversal. In Step 5: Client learns the public IP address of the remote NAT, i.e., the outer IP address of the tunnel. Figure 3
RFC4423]. However, because the current protocol stack used IP as identifiers in TCP, other transport protocols, and some applications, if one does not wish to rewrite all the transport protocol and application code, then DNS is ruled out as infeasible because DNS names have variable lengths. For HIP, although publickey-based HIT has the same length as an IPv6 address, we still lack a secure way to retrieve the public keys. Under this condition, using HIT would not bring us much benefit. BTMM chooses to use IPv6 ULA as the host identifier so that all the existing IPv6 code can be used directly. Since the identifier does not need to stay constant over machine shutdown or crashes, each host creates an IPv6 ULA at boot time. Furthermore, since a host does not leak this ULA to the network, it would not cause any problem to the routing system.
(which is performed every time the network changes), BTMM would randomly generate an IPv6 ULA according to [RFC4193] 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 remaining 8 octets. Since there are 56 random bits plus a theoretically unique EUI-64 identifier, it is unlikely for an IPv6 ULA collision between any two hosts of the same subscriber to occur. This locally generated ULA remains 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. RFC4556] with that certificate. After that, the user is granted a "ticket" that permits it to continue to use the services on the remote host without re-authenticating until the ticket expires (a ticket usually has a 10-hour lifetime). RFC2845]. 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.
Every time a DNS request/response is going to be issued, a TSIG RR is dynamically computed with the HMAC-MD5 [RFC2104] message digest algorithm (and the TSIG RR will be discarded once its has been used). Inside the TSIG RR, the name of the shared secret key in the domain name syntax is included, so the receiver knows which key to use (this is especially useful if the receiver is the DNS server). This TSIG RR is appended to the additional data section before the message is sent 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 [RFC5246] to prevent eavesdropping. RFC5996] process needs to be accomplished. BTMM calls Racoon [Racoon], the IKE daemon, to do the key exchange, after which the key is put into the Security Association Database (SAD). The exchange mode is set to be aggressive so that it will not take too long, and it uses a pre-shared key to do the user authentication. The subscriber's Fully Qualified Domain Name (FQDN) is used as both identifier and pre-shared key during the IKE process.
device is not trustworthy, the communication is at high risk. Even if the NAT device is trustworthy (e.g., the user owns the NAT), it is not uncommon for the NAT to communicate with the host through a 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 few 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 is fully protected, and the Security Associations survive the network changes since the IPv6 ULA remains the same even if 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. RFC4120] for end-to-end authentication and uses IPsec [RFC4301] to secure data communications between two end hosts. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [DDUL] Sekar, K., "Dynamic DNS Update Leases", Work in Progress, August 2006. [DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", Work in Progess, August 2006. [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, February 2011. [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>. [NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [Racoon] "Racoon", <http://ipsec-tools.sourceforge.net>.