Network Working Group S. Cheshire
Internet-Draft Apple Inc.
Intended status: Informational Z. Zhu
Expires: September 11, 2011 UCLA
R. Wakikawa
Toyota ITC
L. Zhang
UCLA
March 10, 2011
Understanding Apple's Back to My Mac (BTMM) Service
draft-zhu-mobileme-doc-05.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 September 11, 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
Cheshire, et al. Expires September 11, 2011 [Page 1]
Internet-Draft BTMM March 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 . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Cheshire, et al. Expires September 11, 2011 [Page 2]
Internet-Draft BTMM March 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. Note that we generally refer to Network
Address Port Translation (NAPT) as NAT in this document. 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 Mac hosts with a
click, after which the user can share files with remote computers or
control the remote host 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 the face of host IP address changes through the use of
unique host identifiers. It also provides a 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
Cheshire, et al. Expires September 11, 2011 [Page 3]
Internet-Draft BTMM March 2011
mapping service. 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 resources 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 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 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.
Cheshire, et al. Expires September 11, 2011 [Page 4]
Internet-Draft BTMM March 2011
BTMM provides an IPv6 socket interface to user applications. It then
wraps the IPv6 packets with IPSec ESP [RFC 4303], 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.
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 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 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 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
Cheshire, et al. Expires September 11, 2011 [Page 5]
Internet-Draft BTMM March 2011
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: 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" [RFC 1918], 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.
Cheshire, et al. Expires September 11, 2011 [Page 6]
Internet-Draft BTMM March 2011
4.2. Requesting/Removing a Port Mapping
To request a port mapping, the client host sends its request packet
via UDP to port 5351 of its configured gateway address, and waits
250ms for a response [NAT-PMP]. 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 a 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 a 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 message sent by
the 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.
Cheshire, et al. Expires September 11, 2011 [Page 7]
Internet-Draft BTMM March 2011
4.4. Unsupported Scenarios
There are a number of situations where NAT-PMP (and consequently
BTMM) does not work.
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 hosts (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 multiple subnets 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 a BTMM client receives the notification about the network
changes, it updates the list of active interfaces. Then, the client
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, the BTMM client 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
updates are required if the location information of hosts are to be
Cheshire, et al. Expires September 11, 2011 [Page 8]
Internet-Draft BTMM March 2011
published via DNS.
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 [DDUL] is employed by BTMM to minimize the chances of stale
RRs. Note that DDUL controls the life time of dynamically updated
RRs at the authoritative DNS servers, while the RRs' TTL values
control the cache life time at caching resolvers.
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
name for SRV RR is as discussed in Section 3 and the name for A,
AAAA, and TXT RRs is 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.
5.3. Getting Up-to-Date DNS Resource Records without Polling
In dynamic environments, changes to DNS information can often be
frequent. However since a DNS query only retrieves the RR value
available at that instance in time, one must continue to query DNS to
learn the latest changes. This solution faces the dilemma between
choose a low polling rate and leaving the client with stale
information, or a high polling rate which would have an adverse
impact on the network and server.
To let the hosts that care about particular DNS RRs learn the changes
quickly and efficiently, BTMM uses DNS Long-Lived Queries (LLQ)
[DNS-LLQ] to let the DNS server to notify the client host once any
Cheshire, et al. Expires September 11, 2011 [Page 9]
Internet-Draft BTMM March 2011
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 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
(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
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
Cheshire, et al. Expires September 11, 2011 [Page 10]
Internet-Draft BTMM March 2011
Figure 3
6. IPv6 ULA as Host ID
6.1. The Need for A Host Identifier
BTMM needs to assign a topology-independent identifier to each client
host for the following reasons. First, two end hosts may wish to
have the established TCP connections survive network changes.
Second, sometimes one needs a constant identifier to be associated
with a key so that the security association can survive the location
changes.
The above needs for a host identifier impose very little constraint
on the properties of the identifier. In particular one notes that
this identifier does not need to be a permanent one, as long as its
life time is no shorter than the life time of any TCP connection or
any security association that runs on the host.
6.2. What to Use As Host Identifiers
Much effort has been put into the development of host identifiers.
Possible candidates for host identifiers include DNS name and Host
Identity Tag (HIT) in HIP [RFC 4423]. However because the current
protocol stack used IP as identifiers in TCP and other transport
protocols, and in some applications, if one does not wish to re-write
all the transport protocol and application code, then DNS is ruled
out as infeasible because DNS name have variable lengths.
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.
BTMM chooses to use IPv6 ULA as host identifiers, 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. And since a host does not leak
this ULA to the network, it would not cause any problem to the
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
Cheshire, et al. Expires September 11, 2011 [Page 11]
Internet-Draft BTMM March 2011
initialized as zeros and the autotunnel interface is marked as
inactive. During the process when BTMM updates the interfaces list
(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 hosts 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 host, 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
Cheshire, et al. Expires September 11, 2011 [Page 12]
Internet-Draft BTMM March 2011
password.
Every time a DNS request/response is going to be issued, a TSIG RR is
dynamically computed with HMAC-MD5 [RFC 2104] message digest
algorithm (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 5246] 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 5996] 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
Cheshire, et al. Expires September 11, 2011 [Page 13]
Internet-Draft BTMM March 2011
BTMM client, is unprotected and vulnerable to attacks. If the NAT
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 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. Security Considerations
The BTMM implementation utilizes existing security protocols to
address the end-to-end security consideration. It uses Kerberos [RFC
4120] for end-to-end authentication, and uses IPsec [RFC 4301] to
secure data communications between two end hosts.
9. IANA Considerations
No IANA services are required by this document.
10. References
10.1. Normative Reference
[RFC 2104]
"HMAC: Keyed-Hashing for Message Authentication",
RFC 2104.
[RFC 2136]
Cheshire, et al. Expires September 11, 2011 [Page 14]
Internet-Draft BTMM March 2011
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136.
[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 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 4303]
"IP Encapsulating Security Payload (ESP)".
[RFC 4556]
"Public Key Cryptography for Initial Authentication in
Kerberos (PKINIT)", RFC 4556.
[RFC 5246]
"The Transport Layer Security (TLS) Protocol Version 1.2",
RFC 5246.
[RFC 5996]
"The Internet Key Exchange (IKEv2) Protocol", RFC 5996.
10.2. Informative References
[DDUL] "Dynamic DNS Update Leases", draft -sekar-dns-ul-01.txt.
[DNS-LLQ] "DNS Long-Lived Queries",
draft draft-sekar-dns-llq-01.txt.
[DNS-SD] "DNS-Based Service Discovery",
draft draft-cheshire-dnsext-dns-sd-10.txt.
[EUI64] "Guidelines for 64-bit Global Identifier (EUI-64)", http :
//standards.ieee.org/regauth/oui/tutorials/EUI64.html.
Cheshire, et al. Expires September 11, 2011 [Page 15]
Internet-Draft BTMM March 2011
[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 1918]
"Address Allocation for Private Internets", RFC 1918.
[RFC 4423]
"Host Identify Protocol (HIP) Architecture", RFC 4423.
[Racoon] "Racoon", http ://netbsd.gw.com/cgi-bin/
man-cgi?racoon++NetBSD-current.
Authors' Addresses
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
US
Phone: +1 408 974 3207
Email: cheshire@apple.com
Zhenkai Zhu
UCLA
4805 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Phone: +1 310 993 7128
Email: zhenkai@ucla.edu
Ryuji Wakikawa
Toyota ITC
465 Bernardo Avenue
Mountain View, CA 94043
US
Email: ryuji@jp.toyota-itc.com
Cheshire, et al. Expires September 11, 2011 [Page 16]
Internet-Draft BTMM March 2011
Lixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Phone: +1 310 825 2695
Email: lixia@cs.ucla.edu
Cheshire, et al. Expires September 11, 2011 [Page 17]