RFC 6281
Understanding Apple's Back to My Mac (BTMM) Service
📄 RFC 6281: Understanding Apple's Back to My Mac (BTMM) Service 🦋
okay bestie, let's start with the title block 💅 This is RFC 6281, titled Understanding Apple's Back to My Mac (BTMM) Service. It's an Informational doc (so it's explaining how something works, not setting a standard 🙈), published in June 2011 with ISSN 2070-1721. The authors are S. Cheshire of Apple Inc., Z. Zhu of UCLA, R. Wakikawa of Toyota ITC, and L. Zhang of UCLA 👑. The title block doesn't list anything it obsoletes or updates, so it's not replacing or amending any earlier RFC ✨
Abstract ✨
okay so this doc is all about Apple's Back to My Mac (BTMM) service 🍎 BTMM lets your devices talk to each other so you can do file sharing and screen sharing between computers at home, at work, or out on the road 🧚 The implementation has to deal with a lot: single sign-on, secure data, service discovery, and end-to-end connectivity, even when you're behind a Network Address Translator (NAT) or your devices are moving around 💖 It's giving real-world chaos handled gracefully 😭
Status of This Memo 📜
ngl this part is kind of formal, but here's the tea 🫶 This is not an Internet Standards Track spec. It's just published for info 🌸
It's a product of the Internet Engineering Task Force (IETF), it reflects what the IETF community agreed on, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥 Not everything the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈
If you want the latest on this doc (status, errata, or how to leave feedback), check 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 🧐 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🌈
Table of Contents 🗂️
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 . . . . . . . . . . . . . . . . . . 151. Introduction 🚀
Apple Inc.'s Back to My Mac (BTMM) service first shipped with the MAC OS X 10.5 release in October 2007, and it's been seriously popular ever since 🍓 BTMM gives you an integrated solution for host mobility support, NAT traversal, and secure end-to-end data delivery. It gets there by combining several existing protocols and software tools instead of inventing new protocols, which is so smart 🧠 Quick heads-up: we generally call Network Address Port Translation (NAPT) just "NAT" in this doc ✨ This doc describes how BTMM works in MAC OS X version 10.5.x, and BTMM keeps evolving over time 🦋
BTMM sets up secure transport connections between a bunch of devices that might be sitting on a dynamic, heterogeneous network 🌸 Whether you're traveling and using airport WiFi or chilling at home behind a NAT, BTMM lets you connect to any Mac with a click 🖱️ Then you can share files with remote computers or control the remote host through screen sharing 😭 When a user changes locations and therefore changes the IP address of their computer (for example, roaming around with a laptop that gets a dynamically allocated IP address), BTMM gives the roaming host a way to update its reachability information, so the user's other Mac devices can still reach it 💖 BTMM keeps end-to-end transport connections alive even when a host's IP address changes, by using unique host identifiers 🔥 It also gives you a way to reach devices sitting behind a NAT 👑
BTMM does all this mostly by bringing together a set of existing protocols and tools 💅 It uses DNS-based Service Discovery [DNS-SD] to announce host reachability information, and dynamic DNS update [RFC2136] to refresh DNS resource records (RRs) when a host detects a network change 🧚 It also uses DNS Long-Lived Queries (LLQs) [DNS-LLQ] to notify hosts right away when the answers to their earlier DNS queries have changed 🙈 BTMM uses the IPv6 Unique Local Address (ULA) [RFC4193] as the host identifier, and it uses the NAT Port Mapping Protocol (PMP) [NAT-PMP] to help with NAT traversal 🌈 For end-to-end authentication it uses Kerberos [RFC4120], and it uses IPsec [RFC4301] to secure data communications between two end hosts 🔐
2. An Overview of Back to My Mac 🗺️
okay so here's the big idea ✨ To keep an established TCP connection running while either end host might change its IP address, the connection needs identifiers that are unique and stable, meaning they don't change along with the addresses 💖 There also has to be a mapping service between those stable identifiers and the IP addresses that keep changing 💜 BTMM uses DNS for that mapping service 🫶 Figure 1 sketches the basic parts of the BTMM implementation 🎀
DDNS update +--------+ DDNS update
+--------------->| |<-------+
| | DNS | |
| LLQ | | LLQ |
| +---------->| |<----+ |
| | | | | |
| | +--------+ | |
| | | | +----------+
| V +---+--+----+ | |
+-+-------+ | +-------| |
|Endhost N| Tunnel | NAT +------>|Endhost M |
| |<=====================================>| |
+---------+ | | | |
+-----------+ +----------+Figure 1
Here's how it works, bestie 🫧 Apple Inc. runs a DNS domain called members.me.com and provides DNS name resolution for every subdomain underneath it 🍎 Every BTMM user gets a DNS subdomain under members.me.com, like alice.members.me.com 🌷 Then the user gives each of their computers a DNS name, like myMacPro.alice.members.me.com 🦄 Each host's reachability information is encoded in DNS resource records and published in the DNS 📣 For example, if myMacPro.alice.members.me.com has a public IPv4 address P, then P is the reachability information for that host ✨ But if the host sits behind a NAT, its reachability information is made up of the public IP address of the NAT box plus the port number opened on the NAT to reach the internal host 😭 In that case, both the public IP address of the NAT box and the port number get encoded into DNS using DNS SRV records [RFC2782], which we'll get into in the next section 💅
When a user logs in from a host M, M starts telling the DNS server about its reachability information 💖 If the user has multiple hosts, M also sets up LLQs with the DNS server for the user's other hosts. That way the DNS server can push any reachability changes of those other hosts to M right away 🔥
To get a unique identifier for each host, BTMM automatically generates an IPv6 ULA for each host at machine boot time, and uses it as the identifier 🧚 This design choice lets BTMM reuse all the existing application and protocol code that already supports IPv6, which is honestly genius 🙈 For end-to-end data security, BTMM uses the existing IPsec to protect the communications, and Kerberos to do the end-to-end authentication 🔐
BTMM gives user applications an IPv6 socket interface 🦋 It then wraps the IPv6 packets with IPsec Encapsulating Security Payload (ESP) [RFC4303] and puts them inside a UDP/IP tunnel, as Figure 2 shows 🌈 And yes, this happens even when both ends have public IPv4 addresses 🫶
+-------------+------------+------------+---------------+
| IPv4 Header | UDP Header | IPsec ESP | IPv6 Packet |
+-------------+------------+------------+---------------+Figure 2
The following sections go through each of the basic components in BTMM 🧚 This doc is meant to be an informal description of the BTMM implementation, so it doesn't include every detail of each component (for example, packet format or error codes) 💜
3. Encoding Host Information in DNS Resource Records ✨
Okay bestie, so for every host, BTMM stuffs two things into DNS: the host identifier and where the host currently is 🗺️ The host identifier (an IPv6 ULA) goes in a DNS AAAA RR, and the location info goes in a DNS SRV RR [RFC2782]. For hosts hiding behind a NAT box, the SRV RR is the MVP because it can store both the public IP address of the NAT box AND the port that got opened for the host 🫶
The SRV RR has eight fields: _Service._Proto.Name, Time to Live (TTL), Class, Type, Priority, Weight, Port, and Target. Here's how BTMM uses them 💅
- Service is the symbolic name of the service. For BTMM it's called
"autotunnel", which means BTMM reads the info in the SRV RR to automatically set up a tunnel between two end hosts 🦋 - Proto is the symbolic name of the protocol. In this document it's
"_udp". BTMM uses_udpto tunnel packets between the two ends for NAT traversal 🌈 - Name is the domain this RR is about. When a user signs up for BTMM with the username
"alice", she gets the domainalice.members.me.com. Then she names each host (likemyMacPro), and that name gets stuck onto her domain. So the first part of the SRV record looks like this:
_autotunnel._udp.myMacPro.alice.members.me.com- Priority and Weight are both set to zero, since BTMM only has one instance providing autotunnel service for each name 🍓
- Port is the port opened on the target host for the service. In BTMM, it's most likely 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 goes here instead.
- Target is the canonical hostname of the host providing the service. In BTMM, it's made by sticking the user's domain onto an autotunnel label. That label identifies the host and isn't usually something the user sees 🙈 The label is built by concatenating
"AutoTunnel"with the IEEE EUI-64 identifier [EUI64] of the primary network interface. So a Target field would look like this:
AutoTunnel-00-22-69-FF-FE-8E-34-2A.alice.members.me.com.After grabbing 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 NAT Traversal 🧚
4. NAT Traversal 💅
So BTMM's NAT traversal needs NAT router devices to support either NAT-PMP or the Universal Plug and Play (UPnP) Internet Gateway Device (IGD) 🌸 NAT-PMP is the alternative Apple Inc. came up with, to the more common IGD Standardized Device Control Protocol [IGD] that's published by the UPnP Forum. Both of them need the NAT devices to be able to open a port for inbound traffic to some host behind it, and to tell that host its public IP address. You can read about the differences between IGD and NAT-PMP in [NAT-PMP]. This section is all about NAT-PMP, bestie 💖
4.1. Introduction to NAT-PMP
NAT-PMP is a protocol designed specifically to handle NAT traversal without any manual configuration ✨ When a host figures out that its primary IPv4 address is in one of the private IP address ranges defined in "Address Allocation for Private Internets" [RFC1918], it uses NAT-PMP to talk to the NAT gateway and request inbound mappings on demand. Once it has made a NAT mapping to allow inbound traffic, the client host 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. So by default, this protocol is built for small home networks where the host's default gateway is the NAT router 🏠 If the host finds that NAT-PMP or UPnP IGD isn't available on its network, it just assumes the network is a public one 🤷♀️
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, then waits 250 ms for a response [NAT-PMP]. If no response shows up after 250 ms, the host tries again using exponential back-off 🔁
While requesting the mapping, the host can ask for a specific external port (for example, the same port as the internal port opened on the host). But the NAT device doesn't have to give it to them 🙃 If that port isn't available, the NAT device responds with a different port. The main reason the host can ask for a specific port is to recover from a NAT device crash, by requesting the same port number it used before the crash 🩹 This simple trick lets the end hosts (instead of the NAT box) keep track of the mapping states. That turns hard state in the network into soft state and enables automatic recovery whenever possible. Iconic, honestly 👑
The default port-mapping lifetime is 3600 seconds. The host tries to renew the mapping every 1800 seconds. The renewal message the client sends, whether it's extending the lease or recreating mappings after the NAT device reboots, is the exact same message used to request a port mapping 🔄
A mapping can be removed in a few different 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. And a client host can always send an explicit packet to request deletion of a mapping it no longer needs 🗑️
4.3. Obtaining NAT Box's Public IP Address
To figure out the public IP address of the NAT, the client host sends a query packet to port 5351 of the configured gateway address too 🔍 The NAT device responds with a packet that contains the public IP address of the NAT.
If the NAT's public IP address changes, the NAT gateway sends a gratuitous response to the link-local multicast address 224.0.0.1, port 5350, to let the clients know about the new IP address. Then the host can update its DNS SRV record to show its new reachability, as we'll cover in the next section 📡
4.4. Unsupported Scenarios
There are a few situations where NAT-PMP (and therefore BTMM) just doesn't work 😭
4.4.1. NAT behind NAT
Some people's primary IP address, assigned by their ISPs, might itself be a NAT address 🫠 Also, some people have a public IP address but accidentally (or on purpose) end up with their hosts behind multiple nested NAT boxes. NAT traversal can't be achieved with NAT-PMP in these situations 💀
4.4.2. NATs and Routed Private Networks
Sometimes a site runs multiple subnets in the private network behind a NAT gateway. That subnetting breaks the NAT-PMP assumption, because a host's default router isn't necessarily the device doing the NAT 🧩
5. Handling IP Address or Port Changes 🦋
This section explains how BTMM handles changes to IP addresses or port numbers. The goal is that the hosts of the same user can still find each other and keep their ongoing TCP connections alive, even after changes happen at one or both ends 🥹
5.1. Updating Local Interfaces and Tunnels
After a BTMM client gets a notification about network changes, it updates its list of active interfaces. Then it sends requests to the NAT device (if it's behind one) to create a port mapping and obtain the new public IP address 📬
Next, the BTMM client makes changes to the local autotunnel interface. That means configuring the IPv6 interface for the inner address of the tunnel. If there are established tunnels, it scans them to find any whose local inner or outer addresses have changed since the tunnel was set up, and then puts in the current addresses 🔧
Once all of that is done, the BTMM client publishes the changes to DNS 🚀
5.2. Dynamically Updating Reachability Information
Mobile BTMM clients mean that dynamic DNS updates are required if the location information of hosts is going to be published via DNS 📱
Here's the tricky part: a mobile host might have dynamically updated an RR, but the updated value never made it to the authoritative DNS server. That leaves stale RRs sitting on the server 😬 So BTMM uses Dynamic DNS Update Leases (DDULs) [DDUL] to minimize the chances of stale RRs. Just 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 🧠
When the network changes, the RRs of a host get updated right away. This happens after the local interfaces are properly configured, and after the port mapping and the NAT's public IP address have been obtained 🏃♀️ Usually there are 4 types of RRs involved:
- an AAAA RR for updating the new host identifier of the host (which might be 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
- a TXT RR for describing the autotunnel device information
The name for the SRV RR is discussed in Section 3. The names for the A, AAAA, and TXT RRs are specified in the Target field of the SRV RR 🎯 After that, the host builds and sends an SRV query to find the dynamic DNS server it should send updates to. Following our alice example, it queries the SRV RR for _dns-update-tls._udp.alice.members.me.com. Then the updates get sent to the dynamic DNS server named in the Target field of the query response 💌
Periodic refreshes are also required by the DDUL even when there are no network changes 🔄 The update requests contain a signed 32-bit integer that indicates 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 info, a lease longer than 2 hours is not allowed in BTMM. The typical length is 90 minutes ⏰ The client host refreshes its RRs before the lease expires, so the server doesn't delete them 🫶
5.3. Getting Up-to-Date DNS Resource Records without Polling ✨
In dynamic environments, DNS info can change super often 😭. The thing is, a DNS query only grabs the RR value that exists at that exact moment, so you have to keep asking to see the newest changes. That leaves you with a dilemma: poll slowly and your client is stuck with stale info, or poll fast and you wreck the network and the server. Not ideal, bestie 💀.
So to help the hosts that care about specific DNS RRs find out about changes quickly and efficiently, BTMM uses DNS Long-Lived Queries (LLQs) [DNS-LLQ]. With LLQs, the DNS server can notify the client host as soon as any changes hit the DNS data it cares about 🔔.
To find the LLQ server, the client sends an SRV query. So alice's host queries _dns-llq-tls._udp.alice.members.me.com and gets back the server that offers LLQ service 🧚. LLQs are started by the client and finished with a four-way handshake: Initial Request, Challenge, Challenge Response, and ACK + Answers. During the Challenge phase, the DNS server hands out a unique identifier for the request, and the client is required to echo that identifier back in the Challenge Response phase. This handshake is resilient to packet loss, proves the client is actually reachable, and cuts down on denial-of-service attack opportunities 🛡️.
The LLQ lease gets negotiated during the handshake. In BTMM, the minimum lease is 15 minutes and the maximum lease is 2 hours ⏰. Leases get refreshed before they expire, so no gaps 💖.
When an "event" happens to a name server's domain, the server checks whether the new or deleted RRs answer any LLQs. If they do, the RRs get sent to the LLQ issuers as a gratuitous DNS response 📨. The client acknowledges receiving the notification. If it doesn't, the server resends the response. If a total of 3 transmissions (with exponential backoff) all fail, the client is considered unreachable and the LLQ gets deleted 🥀.
A BTMM client then updates its tunnels based on the query answers 🚇. The callback function for automatically updating tunnels is depicted in 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 36. IPv6 ULA as Host ID 🎀
6.1. The Need for a Host Identifier
BTMM needs to give each client host a topology-independent identifier, and there are two big reasons 👑. First, two end hosts may want their established TCP connections to survive network changes. Second, sometimes you need a constant identifier tied to a key so the Security Association can survive location changes 🔑.
These needs don't put a lot of constraints on what the identifier looks like 💅. Notably, the identifier doesn't have to be permanent. It just needs a lifetime that's no shorter than the lifetime of any TCP connection or Security Association running on the host ⭐.
6.2. What to Use as Host Identifiers
People have put a lot of effort into host identifiers 🧠. Possible candidates include DNS names and the Host Identity Tag (HIT) from the Host Identity Protocol (HIP) [RFC4423]. But here's the tea: the current protocol stack uses IP addresses as identifiers in TCP, other transport protocols, and some applications. If you don't want to rewrite all that transport and application code, DNS is ruled out, because DNS names have variable lengths 🙅♀️.
As for HIP, the public-key-based HIT is the same length as an IPv6 address, but we still don't have a secure way to retrieve the public keys. Under those conditions, using HIT wouldn't bring us much benefit 🤷♀️.
So BTMM picks IPv6 ULA as the host identifier, which means all the existing IPv6 code can be used directly 🦋. The identifier doesn't need to stay constant across machine shutdowns or crashes, so each host creates an IPv6 ULA at boot time. And since a host never leaks this ULA to the network, it won't cause any problems for the routing system 🌸.
6.3. IPv6 ULA Configuration
In BTMM, the IPv6 ULA is advertised for use in the host's autotunnel service. That means the IPv6 address has to be configured before BTMM starts its service 🧚♀️.
When the machine boots up, the IPv6 address for the autotunnel service is initialized as zeros, and the autotunnel interface is marked as inactive. Every time the network changes, BTMM updates its interfaces list. During that update, if the IPv6 address is still uninitialized, BTMM randomly generates an IPv6 ULA according to [RFC4193] 🎲. The first octet of the ULA is set to "0xFD", the following 7 octets are randomly selected from 0~255, and the EUI-64 identifier fills up the remaining 8 octets 🌈. That gives you 56 random bits plus a theoretically unique EUI-64 identifier, so an IPv6 ULA collision between any two hosts of the same subscriber is unlikely 🙈.
This locally generated ULA stays the same while the machine is on, even when its location changes. So the user gets to fully enjoy the perks of topology-independent host identifiers 💜. Once the machine is turned off, this particular ULA is no longer kept 🌙.
7. Securing Communication 🔐
BTMM users often have to fetch their personal data over networks they don't trust (or networks they don't know are trustworthy, which is honestly just as scary 😬). So it's really important for BTMM to have an effective way to secure communications 🫶.
7.1. Authentication for Connecting to Remote Host
Kerberos is a "single sign on" technology, and it has been supported in Apple's products since MAC OS X 10.5 🍎. Each Mac OS X client keeps a local Key Distribution Center (KDC) for Bonjour and peer-to-peer security 🔑.
When the user first signs in to MobileMe on a host, the host automatically receives a digital certificate and private key for "Back to My Mac Encryption Certificate" from the KDC 📜. When the user connects to another system using BTMM, authentication is done with the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) protocol [RFC4556], using that certificate. After that, the user gets a "ticket" that lets them keep using services on the remote host without re-authenticating until the ticket expires (a ticket usually has a 10-hour lifetime) ⏳✨.
7.2. Authentication for DNS Exchanges
BTMM uses Transaction SIGnature (TSIG) to authenticate the user when a dynamic DNS update is performed [RFC2845]. To protect the subscriber's privacy, LLQ is also required to contain TSIG 🕵️♀️. This authentication mechanism is based on a shared secret key, which in BTMM's case is derived from the subscriber's MobileMe account password 🗝️.
Every time a DNS request or response is about to be issued, a TSIG RR is dynamically computed with the HMAC-MD5 [RFC2104] message digest algorithm. The TSIG RR gets discarded once it's been used 🗑️. Inside the TSIG RR, the name of the shared secret key is included in domain name syntax, so the receiver knows which key to use (this is especially handy when the receiver is the DNS server 🙌). The TSIG RR is appended to the additional data section before the message is sent out. When the message arrives, the receiver verifies the TSIG RR and only proceeds if the TSIG is valid ✅.
On top of that, DNS messages are also protected by TLS [RFC5246] to stop eavesdropping 👀.
7.3. IPsec for Secure End-to-End Data Communication
7.3.1. Internet Key Exchange
Before a Security Association can be established between two end hosts, the Internet Key Exchange (IKE) process [RFC5996] has to be completed 🔄.
BTMM calls Racoon [Racoon], the IKE daemon, to do the key exchange. After that, the key goes into the Security Association Database (SAD) 🗄️. The exchange mode is set to aggressive so it doesn't take too long, and it uses a pre-shared key for user authentication 🏃♀️. The subscriber's Fully Qualified Domain Name (FQDN) is used as both the identifier and the pre-shared key during the IKE process 🪪.
7.3.2. Discussion: End-to-End Encryption
When it's time to set up Security Associations between two BTMM clients, there are two choices: put the other host's IPv4 address in the destination address field, or put it in the IPv6 address of the remote end 🤔.
If the IPv4 address (which is the public address of a NAT) is chosen for the Security Association, that means we're setting one up between one end host and the NAT of the other host. The IPv6 packet would then get wrapped in a UDP header and encrypted by ESP. Once the encrypted packet arrives at the NAT, the NAT device decrypts it and sends it on to the destination according to the port mapping 📦. This approach sounds viable, but it has 3 drawbacks 😤:
- First, the encryption isn't really end-to-end. Only the path between one end host and the other end's NAT device 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 isn't trustworthy, the communication is at high risk. Even if the NAT device is trustworthy (say, the user owns the NAT), it's not uncommon for the NAT to talk to the host over a broadcast channel, which gives an eavesdropper chances to sniff the sensitive data. Think about that unlocked "free" WiFi access near your neighborhood 📡💀.
- Second, quite a few BTMM clients are on the move all the time. Every time they change their attachment point to the Internet, they get a different IPv4 address. As a result, the previously established Security Associations become obsolete, and the two end hosts have to set them up all over again. That's a waste of time and resources 🥲.
- Third, this approach assumes the NAT device is able and willing to do the IPsec ESP for the host behind it, which isn't always the case 🙅♀️.
So BTMM decides to put the IPv6 ULA in the destination field of IPsec Security Associations 🎯. This way, the end-to-end path between the hosts is fully protected, and the Security Associations survive network changes, since the IPv6 ULA stays the same even when the BTMM client changes location 💖. Plus, the encryption is transparent to the NAT device, which means the NAT device isn't required to interfere with the IPsec protection 🫧.
8. Security Considerations 🔐
okay bestie, the BTMM implementation is giving security glow-up 💅 it doesn't invent its own crypto from scratch. It borrows existing security protocols to cover the end-to-end security stuff, and honestly that's the smart move ✨
For end-to-end authentication, it uses Kerberos [RFC4120] 🔑. To secure the data communications between two end hosts, it uses IPsec [RFC4301] 🛡️ no cap, this is the part where you actually have to get it right, so don't skip it 🙈
9. References 📚
9.1. Normative Reference
these are the must-read citations the spec leans on, so here they are in full 🫶
[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.9.2. Informative References
these ones are extra reading, good for the deep dive 🌸
[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>.Authors' Addresses 🎀
the people behind this spec, with their contact info 💜
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Phone: +1 408 974 3207
EMail: cheshire@apple.comZhenkai Zhu
UCLA
4805 Boelter Hall, UCLA
Los Angeles, CA 90095
USA
Phone: +1 310 993 7128
EMail: zhenkai@cs.ucla.eduRyuji Wakikawa
Toyota ITC
465 Bernardo Avenue
Mountain View, CA 94043
USA
EMail: ryuji.wakikawa@gmail.comLixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
USA
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu📦 where this page comes from
- ietf: rfc6281 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms