idnits 2.17.1 draft-zhu-mobileme-doc-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2011) is 4789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-06) exists of draft-sekar-dns-llq-01 == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Informational Z. Zhu 5 Expires: September 11, 2011 UCLA 6 R. Wakikawa 7 Toyota ITC 8 L. Zhang 9 UCLA 10 March 10, 2011 12 Understanding Apple's Back to My Mac (BTMM) Service 13 draft-zhu-mobileme-doc-05.txt 15 Abstract 17 This document describes the implementation of Apple Inc.'s Back to My 18 Mac (BTMM) service. BTMM provides network connectivity between 19 devices so that a user can perform file sharing and screen sharing 20 among multiple computers at home, at work, or on the road. The 21 implementation of BTMM addresses the issues of single sign-on 22 authentication, secure data communication, service discovery and end- 23 to-end connectivity in face of Network Address Translators (NAT) and 24 mobility of devices. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 11, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. An Overview of Back to My Mac . . . . . . . . . . . . . . . . 3 62 3. Encoding Host Information in DNS Resource Records . . . . . . 5 63 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Introduction to NAT-PMP . . . . . . . . . . . . . . . . . 6 65 4.2. Requesting/Removing a Port Mapping . . . . . . . . . . . . 7 66 4.3. Obtaining NAT box's Public IP Address . . . . . . . . . . 7 67 4.4. Unsupported Scenarios . . . . . . . . . . . . . . . . . . 8 68 5. Handling IP Address or Port Changes . . . . . . . . . . . . . 8 69 5.1. Updating Local Interfaces and Tunnels . . . . . . . . . . 8 70 5.2. Dynamically Updating Reachability Information . . . . . . 8 71 5.3. Getting Up-to-Date DNS Resource Records without Polling . 9 72 6. IPv6 ULA as Host ID . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. The Need for A Host Identifier . . . . . . . . . . . . . . 11 74 6.2. What to Use As Host Identifiers . . . . . . . . . . . . . 11 75 6.3. IPv6 ULA Configuration . . . . . . . . . . . . . . . . . . 11 76 7. Securing Communication . . . . . . . . . . . . . . . . . . . . 12 77 7.1. Authentication for Connecting to Remote Host . . . . . . . 12 78 7.2. Authentication for DNS Exchanges . . . . . . . . . . . . . 12 79 7.3. IPsec for Secure End-to-End Data Communication . . . . . . 13 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 Apple Inc.'s Back to My Mac (BTMM) service was first shipped with MAC 90 OS X 10.5 release in October 2007, since then it has been widely 91 used. BTMM provides an integrated solution to host mobility support, 92 NAT traversal, and secure end-to-end data delivery through a 93 combination of several existing protocols and software tools instead 94 of designing new protocols. Note that we generally refer to Network 95 Address Port Translation (NAPT) as NAT in this document. This 96 document describes the implementation of BTMM and we hope the reader 97 find it informative. 99 BTMM provides secure transport connections among a set of devices 100 that may be located over a dynamic and heterogeneous network 101 environment. Independent from whether a user is traveling and 102 accessing the Internet via airport WiFi, or staying at home behind a 103 NAT, BTMM allows the user to connect to any of Mac hosts with a 104 click, after which the user can share files with remote computers or 105 control the remote host through screen sharing. When a user moves 106 around and changes locations and hence the IP address of his computer 107 (e.g. roaming around with a laptop and receiving dynamically 108 allocated IP address), BTMM provides a means for the roaming host to 109 update its reachability information to keep it reachable by the 110 user's other Mac devices. BTMM maintains end-to-end transport 111 connections in the face of host IP address changes through the use of 112 unique host identifiers. It also provides a means to reach devices 113 behind a NAT. 115 BTMM achieves the above functions mainly by integrating a set of 116 existing protocols and software tools. It uses DNS-based Service 117 Discovery [DNS-SD] to announce host reachability information, dynamic 118 DNS update [RFC 2136] to refresh the DNS resource records (RRs) when 119 a host detects network changes, and DNS Long-lived Queries (LLQ) 120 [DNS-LLQ] to notify hosts immediately when the answers to their 121 earlier DNS queries have changed. BTMM uses IPv6 Unique Local 122 Address(ULA) [RFC 4193] as the host identifier, and employs the NAT 123 Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal. It 124 uses Kerberos [RFC 4120] for end-to-end authentication, and uses 125 IPsec [RFC 4301] to secure data communications between two end hosts. 127 2. An Overview of Back to My Mac 129 To keep an established TCP connection running while either of the two 130 end hosts may change its IP address requires that the connection use 131 unique and stable identifiers that do not change with the addresses, 132 and that a mapping service exists between these stable identifiers 133 and dynamically changing IP addresses. BTMM uses DNS to provide this 134 mapping service. Figure 1 provides a sketch of the basic components 135 in the BTMM implementation. 137 DDNS update +--------+ DDNS update 138 +--------------->| |<-------+ 139 | | DNS | | 140 | LLQ | | LLQ | 141 | +---------->| |<----+ | 142 | | | | | | 143 | | +--------+ | | 144 | | | | +----------+ 145 | V +---+--+----+ | | 146 +-+-------+ | +-------| | 147 |Endhost N| Tunnel | NAT +------>|Endhost M | 148 | |<=====================================>| | 149 +---------+ | | | | 150 +-----------+ +----------+ 152 Figure 1 154 Apple Inc. operates a DNS domain called members.me.com, and provides 155 DNS name resolution services for all the subdomains underneath. 156 Every BTMM user is assigned a DNS subdomain under members.me.com, 157 e.g. alice.members.me.com. The user then assigns a DNS name for each 158 of her computers, e.g. myMacPro.alice.members.me.com. The 159 reachability information of each of the user's hosts is encoded in 160 DNS resources records and published in the DNS. For example, If the 161 host myMacPro.alice.members.me.com has a public IPv4 address P, P 162 represents the reachability information to the host. On the other 163 hand, if the host is behind an NAT, its reachability information is 164 composed of the public IP address of the NAT box and the port number 165 opened on the NAT to reach the internal host. In this case both the 166 public IP address of the NAT box and the port number are encoded into 167 DNS using DNS SRV records [RFC 2782], as we explain in the next 168 section. When a user logs in from a host M, M starts updating the 169 DNS server about its reachability information. If the user has 170 multiple hosts, M also sets up LLQs with the DNS server for her other 171 hosts, so that the DNS server can push any reachability changes of 172 these other hosts to M immediately. 174 To obtain a unique identifier for each host, BTMM automatically 175 generates an IPv6 ULA for each host as its identifier at machine boot 176 time. This design choice allows BTMM to reuse all the existing code 177 of applications and protocols that already support IPv6. To ensure 178 end-to-end data security, BTMM leverages the existing IPsec to 179 protect the communications, and Kerberos to perform end-to-end 180 authentication. 182 BTMM provides an IPv6 socket interface to user applications. It then 183 wraps the IPv6 packets with IPSec ESP [RFC 4303], and encapsulates 184 the packets in a UDP/IP tunnel, as illustrated in Figure 2. Note 185 that this is the case even when both ends have public IPv4 addresses. 187 +-------------+------------+------------+---------------+ 188 | IPv4 Header | UDP Header | IPsec ESP | IPv6 Packet | 189 +-------------+------------+------------+---------------+ 191 Figure 2 193 The following sections describe each of the basic components in BTMM. 194 Since this document is intended to be an informal description of the 195 BTMM implementation, it does not include all the details (e.g. packet 196 format, error code, etc) of each component. 198 3. Encoding Host Information in DNS Resource Records 200 For each host, BTMM encodes into DNS both the host identifier and its 201 current location information. BTMM stores the host identifier (IPv6 202 ULA) in a DNS AAAA RR, and uses a DNS SRV RR [RFC 2782] to represent 203 the host's current location information. For hosts behind a NAT box, 204 the use of a DNS SRV RR allows BTMM to store both the public IP 205 address of the NAT box and also the port opened for the host. 207 The SRV RR consists of seven fields: _Service._Proto.Name, TTL, 208 Class, Type, Priority, Weight, Port, and Target. BTMM uses SRV RRs 209 in the following way. 211 Service is the symbolic name of the desired service. In the BTMM 212 case, the service is named "autotunnel", which means that the 213 information contained in the SRV RR is used by BTMM to automatically 214 set up a tunnel between two end hosts. 216 Proto is the symbolic name of desired protocol. In this document the 217 protocol is "_udp". BTMM uses "_udp" to tunnel packets between the 218 two ends to achieve NAT traversal. 220 Name is the domain this RR refers to. When a user subscribes to BTMM 221 service with the username "alice", a domain name 222 "alice.members.me.com" is assigned to her. The user assigns a name, 223 such as "myMacPro", to each host which is appended to the assigned 224 domain name. Hence, the first part of SRV record would look like 225 "_autotunnel._udp.myMacPro.alice.members.me.com". 227 Priority and Weight are set to zero, since there is only one instance 228 that provides "autotunnel" service for each name in BTMM. 230 Port is the port opened on the target host of the service. In BTMM, 231 most likely it is the external port a NAT opened for the host behind 232 it. Knowing the port number is the basic requirement for NAT 233 traversal via UDP encapsulation. If the host is not behind a NAT, 234 the port opened on the host for autotunnel service is placed here. 236 Target is the canonical hostname of the host that provides the 237 service. In BTMM it refers to a name constructed by appending the 238 user's domain name to an autotunnel label, which identifies the host 239 and is not generally user-visible. The autotunnel label is created 240 by concatenating "AutoTunnel" with the IEEE EUI-64 identifier [EUI64] 241 of the primary network interface. Hence, an example for the Target 242 field would look like: AutoTunnel-00-22-69-FF-FE-8E-34- 243 2A.alice.members.me.com. After obtaining the SRV RR, the remote host 244 can query the A RR for the Target and get the external tunnel address 245 for the BTMM client during the NAT Traversal. 247 4. NAT Traversal 249 BTMM's NAT traversal function requires NAT router devices to support 250 NAT-PMP or UPnP IGD. NAT-PMP is the alternative introduced by Apple 251 Inc. to the more common Internet Gateway Device (IGD) Standardized 252 Device Control Protocol [IGD] as published in UPnP forum. Both NAT- 253 PMP and IGD require the NAT devices to be able to open a port for 254 inbound traffic to some host behind it and to inform the host about 255 its public IP address. The differences between IGD and NAT-PMP can 256 be found in [NAT-PMP]. This section focuses on NAT-PMP. 258 4.1. Introduction to NAT-PMP 260 NAT-PMP is a protocol that is designed specifically to handle the NAT 261 traversal without manual configuration. When a host determines that 262 its primary IPv4 address is in one of the private IP address ranges 263 defined in "Address Allocation for Private Internets" [RFC 1918], it 264 invokes NAT-PMP to communicate with the NAT gateway to request the 265 creation of inbound mappings on demand. Having created a NAT mapping 266 to allow inbound traffic, the client host then publishes its NAT 267 box's public IP address and external port number in a DNS server. 269 A host sends its Port Mapping Protocol request to the default 270 gateway, which means that by default, this protocol is designed for 271 small home networks where the host's default gateway is the NAT 272 router. If the host finds that NAT-PMP or UPnP IGD is not available 273 on its network, it would proceed under the assumption that the 274 network is a public network. 276 4.2. Requesting/Removing a Port Mapping 278 To request a port mapping, the client host sends its request packet 279 via UDP to port 5351 of its configured gateway address, and waits 280 250ms for a response [NAT-PMP]. If no response is received after 281 250ms, the host repeats the process with exponential back-off. 283 While requesting the port mapping, the host can specify the desired 284 external port (e.g. the port that is identical to the internal port 285 opened on the host), but the NAT device is not obliged to allocate 286 the desired one. If such a port is not available, NAT device 287 responds with another port. The primary reason for allowing host to 288 request a specific port is to help recovery from a NAT device crash, 289 to allow the host to request the same port number used before the 290 crash. This simple mechanism allows the end hosts, instead of the 291 NAT box, to keep the mapping states, which turns hard state in the 292 network into soft state, and enables automatic recovery whenever 293 possible. 295 The default port mapping lifetime is 3600 seconds. The host tries to 296 renew the mapping at every 1800 seconds. The renewal message sent by 297 the client host, whether for the purpose of the extending the lease 298 or recreating mappings after NAT device reboots, is the same as 299 requesting a port mapping. 301 A mapping may be removed in a variety of ways. If a client host 302 fails to renew a mapping, then when its lifetime expires the mapping 303 is automatically deleted. Or if the client host's DHCP address lease 304 expires, the NAT device also automatically deletes the mapping. A 305 client host can also send an explicit packet to request the deletion 306 of a mapping that is no longer needed. 308 4.3. Obtaining NAT box's Public IP Address 310 To determine the public IP address of the NAT, the client host also 311 sends the query packet to port 5351 of the configured gateway 312 address. NAT device responses with a packet containing the public IP 313 address of NAT. 315 In case the public IP address of the NAT changes, the NAT gateway 316 sends a gratuitous response to the link-local multicast address 317 224.0.0.1, port 5350 to notify the clients about the new IP address, 318 and the host can then update its DNS SRV record to reflect its new 319 reachability as we describe in the next section. 321 4.4. Unsupported Scenarios 323 There are a number of situations where NAT-PMP (and consequently 324 BTMM) does not work. 326 4.4.1. NAT Behind NAT 328 Some people's primary IP address assigned by their ISPs may itself be 329 a NAT address. In addition, some people may have a public IP 330 address, but may put their hosts (perhaps unknowingly) behind 331 multiple nested NAT boxes. NAT traversal cannot be achieved with 332 NAT-PMP in such situations. 334 4.4.2. NATs and Routed Private Networks 336 In some cases, a site may run multiple subnets in the private network 337 behind a NAT gateway. Such subnetting breaks the assumption of NAT- 338 PMP protocol because a host's default router is not necessarily the 339 device performing NAT. 341 5. Handling IP Address or Port Changes 343 This section describes how BTMM handles IP address or port number 344 changes, so that the hosts of the same user can find each other and 345 keep ongoing TCP connections even after the changes happen at one or 346 both ends. 348 5.1. Updating Local Interfaces and Tunnels 350 After a BTMM client receives the notification about the network 351 changes, it updates the list of active interfaces. Then, the client 352 sends requests to the NAT device (if it is behind a NAT) in order to 353 create a port mapping and obtain the new public IP address. 355 Next step, the BTMM client makes changes to the local autotunnel 356 interface, i.e. configures the IPv6 interface for the inner address 357 of tunnel. If there are established tunnels, it scans to find those 358 whose local inner/outer addresses have been changed since the tunnel 359 was set up, and then puts in the current addresses. 361 With all these done, now the BTMM client publishes the changes to 362 DNS. 364 5.2. Dynamically Updating Reachability Information 366 The mobile nature of the BTMM clients implies that dynamic DNS 367 updates are required if the location information of hosts are to be 368 published via DNS. 370 However, a mobile host may have dynamically updated an RR but the 371 updated value has not been propagated to the authoritative DNS 372 server, leaving stale RRs in the server. Hence, Dynamic DNS Update 373 Leases [DDUL] is employed by BTMM to minimize the chances of stale 374 RRs. Note that DDUL controls the life time of dynamically updated 375 RRs at the authoritative DNS servers, while the RRs' TTL values 376 control the cache life time at caching resolvers. 378 In case of network changes, the RRs of a host are updated immediately 379 after local interfaces are properly configured and port mapping as 380 well as the public IP address of the NAT are obtained. Usually there 381 are 4 types of RRs involved. An AAAA RR for updating the new host 382 identifier of the host (possibly the same as the old one); an SRV RR 383 for updating the autotunnel service information, which includes the 384 new external port; an A RR for updating the new public IP address; 385 and a TXT RR for describing the autotunnel device information. The 386 name for SRV RR is as discussed in Section 3 and the name for A, 387 AAAA, and TXT RRs is specified in the Target field of the SRV RR. 388 The host then constructs and sends an SRV query for the dynamic DNS 389 server to which it should send updates. Following our example for 390 alice, it queries the SRV RR for _dns-update- 391 tls._udp.alice.members.me.com. Then the updates are sent to the 392 dynamic DNS server returned in the target field of query response. 394 In addition, periodic refreshes are also required by the DDUL even in 395 the absence of any network changes. The update requests contain a 396 signed 32-bit integer indicating the lease life in seconds. To 397 reduce network and server load, a minimum lease of 30 minutes is 398 required. On the other hand, to avoid stale information, a lease 399 longer than 2 hours is not allowed in BTMM. The typical length is 90 400 minutes. The client host refreshes the RRs before the lease expires 401 to prevent them from being deleted by the server. 403 5.3. Getting Up-to-Date DNS Resource Records without Polling 405 In dynamic environments, changes to DNS information can often be 406 frequent. However since a DNS query only retrieves the RR value 407 available at that instance in time, one must continue to query DNS to 408 learn the latest changes. This solution faces the dilemma between 409 choose a low polling rate and leaving the client with stale 410 information, or a high polling rate which would have an adverse 411 impact on the network and server. 413 To let the hosts that care about particular DNS RRs learn the changes 414 quickly and efficiently, BTMM uses DNS Long-Lived Queries (LLQ) 415 [DNS-LLQ] to let the DNS server to notify the client host once any 416 changes are made to the concerned DNS data. 418 To obtain the LLQ server information, the client issues an SRV query. 419 So alice's host issues a query for _dns-llq- 420 tls._udp.alice.members.me.com and obtains the server that provides 421 LLQ service. LLQs are initiated by a client and are completed via a 422 four-way handshake: Initial Request, Challenge, Challenge Response, 423 and ACK + Answers. During the Challenge phase, the DNS server 424 provides a unique identifier for the request and the client is 425 required to echo this identifier in Challenge Response phase. This 426 handshake provides resilience to packet loss, demonstrates client 427 reachability and reduces denial-of-service attack opportunities. 429 LLQ lease is negotiated during the handshake. In BTMM, the minimum 430 lease is 15 minutes and the maximum lease is 2 hours. Leases are 431 refreshed before they expire. 433 When a change ("event") occurs to a name server's domain, the server 434 checks if the new or deleted RRs answer any LLQs. If so, the RRs are 435 sent to the LLQ issuers in the form of a gratuitous DNS response. 436 The client acknowledges the reception of the notification; otherwise 437 the server re-sends the response. If a total of 3 transmissions 438 (with exponential backoff) fail, the client is considered unreachable 439 and the LLQ is deleted. 441 A BTMM client then updates its tunnels according to the query 442 answers. The callback function for automatically updating tunnels is 443 depicted Figure 3. 445 1: Push Updated AAAA RR +------------+ 446 <----------------------------------- | | 447 2: Query for autotunnel SRV RR | | 448 +--------+ -----------------------------------> | | 449 | | 3: Reply Updated SRV RR | DNS server | 450 | client | <----------------------------------- | | 451 | | 4: Query for Target in SRV RR | | 452 +--------+ -----------------------------------> | | 453 5: Reply Updated A RR of Target | | 454 <----------------------------------- | | 455 +------------+ 457 In Step 458 1: client learns the inner IP address of the tunnel 459 3: client learns the port opened for UDP NAT traversal 460 5: client learns the public IP address of the remote NAT, 461 i.e. the outer IP address of the tunnel 462 Figure 3 464 6. IPv6 ULA as Host ID 466 6.1. The Need for A Host Identifier 468 BTMM needs to assign a topology-independent identifier to each client 469 host for the following reasons. First, two end hosts may wish to 470 have the established TCP connections survive network changes. 471 Second, sometimes one needs a constant identifier to be associated 472 with a key so that the security association can survive the location 473 changes. 475 The above needs for a host identifier impose very little constraint 476 on the properties of the identifier. In particular one notes that 477 this identifier does not need to be a permanent one, as long as its 478 life time is no shorter than the life time of any TCP connection or 479 any security association that runs on the host. 481 6.2. What to Use As Host Identifiers 483 Much effort has been put into the development of host identifiers. 484 Possible candidates for host identifiers include DNS name and Host 485 Identity Tag (HIT) in HIP [RFC 4423]. However because the current 486 protocol stack used IP as identifiers in TCP and other transport 487 protocols, and in some applications, if one does not wish to re-write 488 all the transport protocol and application code, then DNS is ruled 489 out as infeasible because DNS name have variable lengths. 491 For HIP, although publickey-based HIT has the same length as IPv6 492 address, we still lack a secure way to retrieve the public keys. 493 Under this condition, using HIT would not bring us much benefit. 495 BTMM chooses to use IPv6 ULA as host identifiers, so that all the 496 existing IPv6 code can be used directly. Since the identifier does 497 not need to stay constant over machine shutdown or crashes, each host 498 creates an IPv6 ULA at boot time. And since a host does not leak 499 this ULA to the network, it would not cause any problem to the 500 routing system. 502 6.3. IPv6 ULA Configuration 504 In BTMM, IPv6 ULA is advertised to be used in the autotunnel service 505 of the host. Thus, the IPv6 address needs to be configured before 506 BTMM starts its service. 508 When the machine boots up, the IPv6 address for autotunnel service is 509 initialized as zeros and the autotunnel interface is marked as 510 inactive. During the process when BTMM updates the interfaces list 511 (which is performed every time the network changes), BTMM would 512 randomly generate an IPv6 ULA according to [RFC 4193], if the IPv6 513 address is found uninitialized. The first octet of the ULA is set to 514 be "0xFD", and the following 7 octets are randomly selected from 515 0~255. Finally, the EUI-64 identifier fills up the rest 8 octets. 516 Since there are 56 random bits plus a theoretically unique EUI-64 517 identifier, it is unlikely to have the IPv6 ULA collision between any 518 two hosts of the same subscriber. 520 This locally generated ULA keeps unchanged when the machine is on, 521 despite its location changes. Hence the user can fully enjoy the 522 benefits brought by topology-independent host identifiers. After the 523 machine is turned off, this particular ULA is no longer kept. 525 7. Securing Communication 527 BTMM users often have to fetch their personal data via a network they 528 don't trust (or have no idea whether it's trustworthy). Hence, it is 529 important for BTMM to have effective means to secure the 530 communications. 532 7.1. Authentication for Connecting to Remote Host 534 Kerberos is a "single sign on" technology and is supported in Apple's 535 products since Mac OS X 10.5. Each Mac OS X client maintains a local 536 Key Distribution Center (KDC) for the use of Bonjour and peer-to-peer 537 security. 539 When the user first signs in to MobileMe on a host, it automatically 540 receives from KDC a digital certificate and private key for "Back to 541 My Mac Encryption Certificate". When the user connects to another 542 system using BTMM, authentication is performed using the standard 543 Public Key Cryptography for Initial Authentication in Kerberos 544 (PKINIT) protocol [RFC 4556] with that certificate. After that, the 545 user is granted a "ticket" that permits it to continue to use the 546 services on the remote host, without re-authenticating, until the 547 ticket expires, which usually has 10 hours lifetime. 549 7.2. Authentication for DNS Exchanges 551 BTMM uses Transaction SIGnature (TSIG) to authenticate user when 552 dynamic DNS update is performed [RFC 2845]. Also, to protect the 553 subscriber's privacy, LLQ is required to contain TSIG. This 554 authentication mechanism is based on the shared secret key, which in 555 BTMM's case is derived from the subscriber's MobileMe account 556 password. 558 Every time a DNS request/response is going to be issued, a TSIG RR is 559 dynamically computed with HMAC-MD5 [RFC 2104] message digest 560 algorithm (and the TSIG RR will be discarded once its has been used). 561 Inside the TSIG RR, a name of the shared secret key in domain name 562 syntax is included, so the receiver knows which key to used 563 (especially useful if the receiver is the DNS server). This TSIG RR 564 is appended to the additional data section before the message is send 565 out. The receiver of the message verifies the TSIG RR and proceeds 566 only if the TSIG is valid. 568 Besides, the DNS messages are also protected by TLS [RFC 5246] to 569 prevent eavesdropping. 571 7.3. IPsec for Secure End-to-End Data Communication 573 7.3.1. Internet Key Exchange 575 Before the Security Association can be established between two end 576 hosts, Internet Key Exchange (IKE) [RFC 5996] process needs to be 577 accomplished. 579 BTMM calls Racoon [Racoon], the IKE daemon, to do the key exchange, 580 after which the key is put into Security Association Database (SAD). 581 The exchange mode is set to be aggressive so that it would not take 582 too long. And it uses pre-shared key to do the user authentication. 583 The subscriber's FQDN is used as both identifier and pre-shared key 584 during the IKE process. 586 7.3.2. Discussion: End-to-End Encryption 588 When it comes the time to set up Security Associations between two 589 BTMM clients, we have two choices: either to put the other host's 590 IPv4 address in the destination address field, or otherwise put in 591 the IPv6 address of the remote end. 593 If the IPv4 address (which is the public address of a NAT) is chosen 594 to associate with a Security Association, that means we set up a 595 Security Association between one end host and the NAT of the other 596 host. The IPv6 packet would then be wrapped by UDP header and then 597 get encrypted by ESP. After the encrypted packet arrives at the NAT, 598 the NAT device decrypts the packet and sends it to the destination 599 according to the port mapping. Although this approach seems viable, 600 there are 3 drawbacks: 601 o First, the encryption is not really end-to-end, i.e. only the path 602 between one end host and the NAT device of the other end is 603 protected. The rest of the path, from the NAT device to the other 604 BTMM client, is unprotected and vulnerable to attacks. If the NAT 605 device is not trustworthy, the communication is at high risk. 606 Even if the NAT device is trustworthy (e.g. the user owns the 607 NAT), it is not uncommon that the NAT communicates with the host 608 through broadcast channel, which provides opportunities for an 609 eavesdropper to sniff the sensitive data (consider the unlocked 610 "free" WiFi access near your neighborhood). 611 o Second, quite a lot BTMM clients are on the move very often. 612 Every time they change their attachment points to the Internet 613 they will get different IPv4 addresses. As a result, the 614 previously established Security Associations become obsoleted and 615 the two end hosts need to re-establish them again. This is a 616 waste of time and resources. 617 o Third, this approach assumes that the NAT device is able and 618 willing to do the IPsec ESP for the host behind it, which is not 619 always the case. 621 Consequently, BTMM decides to put the IPv6 ULA into the destination 622 field of IPsec Security Associations. In this way, the end-to-end 623 path between the hosts are fully protected, and the Security 624 Associations survive the network changes since the IPv6 ULA remains 625 the same even the BTMM client changes its location. Furthermore, the 626 encryption is transparent to the NAT device, which means the NAT 627 device is not required to interfere with the IPsec protection. 629 8. Security Considerations 631 The BTMM implementation utilizes existing security protocols to 632 address the end-to-end security consideration. It uses Kerberos [RFC 633 4120] for end-to-end authentication, and uses IPsec [RFC 4301] to 634 secure data communications between two end hosts. 636 9. IANA Considerations 638 No IANA services are required by this document. 640 10. References 642 10.1. Normative Reference 644 [RFC 2104] 645 "HMAC: Keyed-Hashing for Message Authentication", 646 RFC 2104. 648 [RFC 2136] 649 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 650 RFC 2136. 652 [RFC 2782] 653 "A DNS RR for specifying the location of services (DNS 654 SRV)", RFC 2782. 656 [RFC 2845] 657 "Secret Key Transaction Authentication for DNS (TSIG)", 658 RFC 2845. 660 [RFC 4120] 661 "The Kerberos Network Authentication Services (V5)", 662 RFC 4120. 664 [RFC 4193] 665 "Unique Local IPv6 Unicast Address", RFC 4193. 667 [RFC 4301] 668 "Security Architecture for the Internet Protocol", 669 RFC 4301. 671 [RFC 4303] 672 "IP Encapsulating Security Payload (ESP)". 674 [RFC 4556] 675 "Public Key Cryptography for Initial Authentication in 676 Kerberos (PKINIT)", RFC 4556. 678 [RFC 5246] 679 "The Transport Layer Security (TLS) Protocol Version 1.2", 680 RFC 5246. 682 [RFC 5996] 683 "The Internet Key Exchange (IKEv2) Protocol", RFC 5996. 685 10.2. Informative References 687 [DDUL] "Dynamic DNS Update Leases", draft -sekar-dns-ul-01.txt. 689 [DNS-LLQ] "DNS Long-Lived Queries", 690 draft draft-sekar-dns-llq-01.txt. 692 [DNS-SD] "DNS-Based Service Discovery", 693 draft draft-cheshire-dnsext-dns-sd-10.txt. 695 [EUI64] "Guidelines for 64-bit Global Identifier (EUI-64)", http : 696 //standards.ieee.org/regauth/oui/tutorials/EUI64.html. 698 [IGD] "Internet Gateway Device(IGD) Standard Device Control 699 Protocol", http ://www.upnp.org/standardizeddcps/igd.asp. 701 [NAT-PMP] "NAT Port Mapping Protocol", 702 draft draft-cheshire-nat-pmp-03.txt. 704 [RFC 1918] 705 "Address Allocation for Private Internets", RFC 1918. 707 [RFC 4423] 708 "Host Identify Protocol (HIP) Architecture", RFC 4423. 710 [Racoon] "Racoon", http ://netbsd.gw.com/cgi-bin/ 711 man-cgi?racoon++NetBSD-current. 713 Authors' Addresses 715 Stuart Cheshire 716 Apple Inc. 717 1 Infinite Loop 718 Cupertino, CA 95014 719 US 721 Phone: +1 408 974 3207 722 Email: cheshire@apple.com 724 Zhenkai Zhu 725 UCLA 726 4805 Boelter Hall, UCLA 727 Los Angeles, CA 90095 728 US 730 Phone: +1 310 993 7128 731 Email: zhenkai@ucla.edu 733 Ryuji Wakikawa 734 Toyota ITC 735 465 Bernardo Avenue 736 Mountain View, CA 94043 737 US 739 Email: ryuji@jp.toyota-itc.com 740 Lixia Zhang 741 UCLA 742 3713 Boelter Hall, UCLA 743 Los Angeles, CA 90095 744 US 746 Phone: +1 310 825 2695 747 Email: lixia@cs.ucla.edu