idnits 2.17.1 draft-montenegro-firewall-sup-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 354: '...". Furthermore, incoming packets MUST...' RFC 2119 keyword, line 536: '... Internet, it MUST encapsulates the ...' RFC 2119 keyword, line 537: '...to the firewall. The mobile node MUST...' RFC 2119 keyword, line 557: '...ly, the firewall SHOULD be configured ...' RFC 2119 keyword, line 622: '...the principals' names MUST be securely...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 31, 1997) is 9758 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1827 (ref. '6') (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 1826 (ref. '7') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Montenegro 2 INTERNET DRAFT V. Gupta 3 Sun Microsystems, Inc. 4 July 31, 1997 6 Firewall Support for Mobile IP 7 draft-montenegro-firewall-sup-01.txt 9 Status of This Memo 11 This document is a submission to the Mobile IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 either to the authors, or to the mobile-ip@SmallWorks.COM mailing 14 list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as 26 reference material or to cite them other than as ``work in 27 progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 The Mobile IP specification establishes the mechanisms that enable a 38 mobile host to maintain and use the same IP address as it changes 39 its point of attachment to the network. Mobility implies higher 40 security risks than static operation, because the traffic may at 41 times take unforeseen network paths with unknown or unpredictable 42 security characteristics. The Mobile IP specification makes no 43 provisions for securing data traffic. The mechanisms described in 44 this document allow a mobile node out on a public sector of the 45 internet to negotiate access past a SKIP firewall, and construct a 46 secure channel into its home network. 48 In addition to securing traffic, our mechanisms allow a mobile node 49 to roam into regions that (1) impose ingress filtering, and (2) use 50 a different address space. 52 Table of Contents 54 1. Introduction ................................................... 4 55 2. Mobility without a Firewall .................................... 6 56 3. Restrictions imposed by a Firewall ............................. 6 57 4. Two Firewall Options: Application relay and IP Security ........ 7 58 4.1 SOCKS version 5 [4] ........................................... 7 59 4.2 SKIP [3] ...................................................... 8 60 5. Agents and Mobile Node Configurations .......................... 10 61 6. Supporting Mobile IP: Secure Channel Configurations ............ 11 62 6.1 I: Encryption only Outside of Private Network ................. 12 63 6.2 II: End-to-End Encryption ..................................... 12 64 6.3 III: End-to-End Encryption, Intermediate Authentication ....... 12 65 6.4 IV: Encryption Inside and Outside ............................. 13 66 6.5 Choosing a Secure Channel Configuration ....................... 13 67 7. Mobile IP Registration Procedure with a SKIP Firewall .......... 14 68 7.1. Registration Request through the Firewall .................... 15 69 7.1.1. On the Outside (Public) Network ............................ 16 70 7.1.2. On the Inside (Private) Network ............................ 17 71 7.2. Registration Reply through the Firewall ...................... 17 72 7.2.1. On the Inside (Private) Network ............................ 18 73 7.2.2. On the Outside (Public) Network ............................ 18 74 7.3. Traversal Extension .......................................... 19 75 8. Data Transfer .................................................. 21 76 8.1. Data Packet From the Mobile Node to a Correspondent Node ..... 21 77 8.2. Data Packet From a Correspondent Node to the Mobile Node ..... 22 78 8.2.1 Within the Inside (Private) Network ......................... 23 79 8.2.2. On the Outside (Public) Network ............................ 24 80 9. Security Considerations ........................................ 24 81 Acknowledgements .................................................. 25 82 References ........................................................ 25 83 1. Introduction 85 This document specifies what support is required at the firewall, 86 the Mobile IP [1] home agent and the Mobile IP mobile node to enable 87 the latter to access a private network from the Internet. For 88 example, a company employee could attach his/her laptop to some 89 Internet access point by: 91 a) Dialing into a PPP/SLIP account on an Internet service 92 provider's network. 94 b) Connecting into a 10Base-T or similar LAN network available 95 at, for example, an IETF terminal room, a local university, 96 or another company's premises. 98 Notice that in these examples, the mobile node's relevant interface 99 (PPP or 10Base-T) is configured with an IP address different from 100 that which it uses "normally" (i.e. at the office). Furthermore, the 101 IP address used is not necessarily a fixed assignment. It may be 102 assigned temporarily and dynamically at the beginning of the session 103 (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case). 105 The following discussion assumes a network configuration consisting 106 of a private network separated by a firewall from the general 107 Internet or public network. The systems involved are: 109 Private Network 111 A protected network separated from the Internet by hosts 112 enforcing access restrictions (firewalls). A private network 113 may use a private address space, and its addresses may not 114 even be routable by the general internet. 116 Public Network 118 The Internet at large. Hosts are able to communicate with each 119 other throughout the public network without firewall-imposed 120 restrictions. 122 Mobile Node (MN) 123 Its permanent address falls within the range of the private 124 network. The user removes the system from its home network, 125 and connects it to the Internet at another point. The 126 mechanisms outlined in this discussion render this mobility 127 transparent: the mobile node continues accessing its home 128 network and its resources exactly as if it were still within 129 it. Notice that when the mobile node leaves its home 130 network, it may migrate both within and outside of the 131 private network's boundaries. As defined by Mobile IP [1], a 132 mobile node uses a care-of address while roaming. 134 Home Agent (HA) for the mobile node 136 Serves as a location registry and router as described in the 137 Mobile IP IETF draft. 139 Foreign Agent (FA) 141 Serves as a registration relayer and care of address for the 142 mobile node as described in the Mobile IP IETF draft. 144 Correspondent Node (CH) 146 A system that is exchanging data packets with the mobile 147 node. 149 Firewall (FW) 151 The system (or collection of systems) that enforces access 152 control between the private network and the general Internet. 153 It may do so by a combination of functions such as application 154 gatewaying, packet filtering and cryptographic techniques. 156 The mechanisms described in this document allow a mobile node out on 157 a public sector of the network to negotiate access past a SKIP 158 firewall, and construct a secure channel into its home network. 159 This enables it to communicate with correspondent nodes that belong 160 to the private network, and, if bi-directional tunnels are used, 161 with external hosts that are reachable when the mobile node is at 162 home. The mobile node enjoys the same level of connectivity and 163 privacy as it does when it is in its home network. 165 This document does not address the scenario in which the mobile 166 node attempts to access its private network, while within another 167 private network. 169 Sections 2 and 3 provide an overview of the environment being 170 considered and the restrictions it imposes. Sections 4 examines 171 firewall technologies. Section 5 discusses the best mode of 172 operation of the participating entities from the point of view of 173 Mobile IP. Section 6 discusses possible configuration for the 174 secure channel. Finally, packet formats are the topic of of 175 sections 7 and 8. 177 2. Mobility without a Firewall 179 Suppose the mobile node is roaming throughout the general Internet, 180 but its home network is not protected by a firewall. This is 181 typically found in academic environment as opposed to corporate 182 networks. 184 This works as prescribed by Mobile IP [1]. The only proviso is that 185 the mobile node would most probably operate with a co-located 186 address instead of using a separate foreign agent's care-of 187 address. This is because, at least in the near term, it is far more 188 likely to be able to secure a temporary care-of-address than it is 189 to find a foreign agent already deployed at the site you are 190 visiting. For example: 192 - Internet Service Provider (ISP): pre-assigns customers IP 193 addresses, or hands them out dynamically via PPP's address 194 negotiation. 196 - IETF terminal room: typically pre-assigns addresses for your use 198 - other places would probably offer DHCP services 200 3. Restrictions imposed by a Firewall 202 The firewall imposes restrictions on packets entering or leaving the 203 private network. Packets are not allowed through unless they conform 204 to a filtering specification, or unless there is a negotiation 205 involving some sort of authentication. 207 Another restriction is imposed by the separation between private 208 addresses and general Internet addresses. Strictly speaking, this is 209 not imposed by a firewall, but by the characteristics of the private 210 network. For example, if a packet destined to an internal address 211 originates in the general Internet, it will probably not be 212 delivered. It is not that the firewall drops it. Rather, the 213 Internet's routing fabric is unable to process it. This elicits an 214 ICMP host unreachable packet sent back to the originating node. 216 Because of this, the firewall must be explicitly targeted as the 217 destination node by outside packets seeking to enter the private 218 network. The routing fabric in the general Internet will only see 219 the public address of the firewall and route accordingly. Once the 220 packet arrives at the firewall, the real packet destined to a 221 private address must be recovered. 223 4. Two Firewall Options: Application relay and IP Security 225 Before delving into any details, lets examine two technologies which 226 may provide firewall support for mobile nodes: 228 - application relaying or proxying, or 229 - IP Security 231 To understand the implications, let's examine two specific schemes 232 to accomplish the above: SOCKS version 5 and SKIP. 234 4.1 SOCKS version 5 [4] 236 There is an effort within the authenticated firewall traversal WG 237 (aft) of the IETF to provide a common interface for application 238 relays. 240 The solution being proposed is a revised specification of the SOCKS 241 protocol. Version 5 has been extended to include UDP services as 242 well. The SOCKS solution requires that the mobile node -- or 243 another node on its behalf -- establish a TCP session to exchange 244 UDP traffic with the FW. It also has to use the SOCKS library to 245 encapsulate the traffic meant for the FW. The steps required by a 246 SOCKS solution are: 248 - TCP connection established to port 1080 (1.5 round trips) 250 - version identifier/method selection negotiation (1 round trip) 251 - method-dependent negotiation. For example, the 252 Username/Password Authentication [5] requires 1 round trip: 254 1. client sends a Username/Password request 255 2. FW (server) responds 257 The GSS-API negotiation requires at least 3 round trips: 259 1. client context establishment (at least 1 round trip) 260 2. client initial token/server reply (1 round trip) 261 3. message protection subnegotiation (at least 1 round trip) 263 - (finally) SOCKS request/reply (1 round trip) 265 This is a minimum of 4 (6 with GSS-API) round-trips before the 266 client is able to pass data through the FW using the following 267 header: 269 +----+------+------+----------+----------+----------+ 270 |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | 271 +----+------+------+----------+----------+----------+ 272 | 2 | 1 | 1 | Variable | 2 | Variable | 273 +----+------+------+----------+----------+----------+ 275 Bear in mind that the above must be done each time the mobile 276 registers a new care-of address. In addition to this inefficiency, 277 this scheme requires that we use UDP to encapsulate IP datagrams. 278 There is at least one commercial network that does this, but it is 279 not the best solution. 281 Furthermore, SOCKS defines how to establish authenticated 282 connections, but currently it does not provide a clear solution to 283 the problem of encrypting the traffic. 285 This header contains the relay information needed by all parties 286 involved to reach those not directly reachable. 288 4.2 SKIP [3] 290 Alternatively, traffic from the mobile node to the firewall could be 291 encrypted and authenticated using a session-less IP security 292 mechanism like SKIP. This obviates the need to set up a session 293 just to exchange UDP traffic with the firewall. 295 A solution based on SKIP is very attractive in this scenario, as no 296 round trip times are incurred before the mobile node and the 297 firewall achieve mutual trust: the firewall can start relaying 298 packets for the mobile node as soon as it receives the first one. 299 This, of course, implies that SKIP is being used with AH [7] so that 300 authentication information is contained in each packet. Encryption 301 by using ESP [6] is also assumed in this scenario, since the 302 Internet at large is considered a hostile environment. An ESP 303 transform that provides both authentication and encryption could be 304 used, in which case the AH header need not be included. 306 The firewall and the mobile node must both be previously configured 307 with the authenticated Diffie-Hellman public values for each other. 308 Strictly speaking, they could obtain them in real-time, using any of 309 the mechanisms defined by the SKIP protocol (on-line certificate 310 directory service or certificate discovery protocol). However, in 311 order to avoid round-trip times, it is preferable to manually 312 distribute each other's public keys to the the mobile node and the 313 SKIP firewall. This is part of the administrative process of 314 enabling a mobile node to roam in the general Internet. Home agents 315 and the firewall must also have access to each others public keys. 317 There are other proposals besides SKIP to achieve IP layer 318 security. However, they are session-oriented key management 319 solutions, and typically imply negotiations spanning several 320 round-trip times before cryptographically secure communications are 321 possible. In this respect they raise similar concerns to those 322 outlined previously in the discussion on SOCKS-based solutions. 323 Others have arrived at similar conclusions regarding the importance 324 of session-less key management for Mobile IP applications [8]. 326 Another advantage of SKIP is its support for nomadic applications. 327 Typically, two hosts communicating via a secure IP layer channel use 328 the IP source and destination addresses on incoming packets to 329 arrive at the appropriate security association. The SKIP header can 330 easily supersede this default mechanism by including the key ID the 331 recipient must use to obtain the right certificate. 333 The key id is specified by two fields in the SKIP header: 335 1) a name space identifier (NSID) to indicate which of the 336 possible name spaces is being used, and, 338 2) a master key identifier (MKID) that uniquely indicates (within 339 the given name space) an id to use in fetching the proper 340 certificate. 342 As an example, by setting NSID to 1 and MKID to its home address, a 343 mobile node tells a receiver "ignore the IP source and use my home 344 address instead to look up my public key". Similarly, setting NSID 345 to 8 enables using Unsigned Diffie-Hellman (UDH) certificates. In 346 this case, the MKID is set to the MD5 hash of the DH public key 347 [10]. 349 In addition to the NSID/MKID feature, Mobile IP is best supported by 350 an appropriate policy at the SKIP firewall in the form of a 351 "nomadic" access control list entry. This is an entry which is 352 filtered by key ID, instead of by IP source address, as is the usual 353 case. It translates to "allow access from any IP source address for 354 a given NSID/MKID combination". Furthermore, incoming packets MUST 355 have an AH header, so that after properly authenticating them, the 356 firewall establishes a "current address" or "dynamic binding" for 357 the nomadic host. The NSID/MKID combination determines which key 358 should be used with the nomadic host [9]. 360 Notice that this supports Mobile IP, because the mobile node always 361 initiates contact. Hence, the SKIP firewall has a chance to learn 362 the mobile node's "current address" from an incoming packet before 363 it attempts to encrypt an outgoing packet. 365 However, this precludes the use of simultaneous bindings by a mobile 366 node. At the firewall, the last Registration Request sent by the 367 mobile node replaces the association between its permanent address 368 and any prior care-of address. In order to support simultaneous 369 bindings the firewall must be able to interpret Mobile IP 370 registration messages. 372 Section 7.2.2 discusses another advantage of making the firewall 373 understand Mobile IP packet formats. 375 In what follows we assume a SKIP-based solution. 377 5. Agents and Mobile Node Configurations 379 The Mobile IP protocol specifies two ways that a mobile node can 380 register a mobility binding with its home agent, depending on which 381 address it uses as its tunnel endpoint: 383 a) an address advertised for that purpose by the foreign agent 385 b) an address belonging to one of the mobile node's interfaces 386 (i.e. operation with a co-located address). 388 From the firewall's point of view, the main difference between these 389 two cases hinges on which node prepares the outermost encrypting 390 encapsulation. The firewall must be able to obtain the public keys 391 of the node that creates the outermost SKIP header in an incoming 392 packet. This is only possible to guarantee in case "b", because the 393 mobile node and the firewall both belong to the same administrative 394 domain. The problem is even more apparent when the mobile node 395 attempts a Registration Request. Here, the foreign agent is not just 396 a relayer, it actually examines the packet sent by the mobile node, 397 and modifies its agent services accordingly. In short, assuming the 398 current specification of Mobile IP and the current lack of trust in 399 the internet at large, only case "b" is possible. Case "a" would 400 require an extension (e.g. a "relay" Registration Request), and 401 modifying code at the home agent, the firewall and the foreign 402 agent. 404 Assuming that the firewall offers a secure relay service (i.e. 405 decapsulation and forwarding of packets), the mobile node can reach 406 addresses internal to the private network by encapsulating the 407 packets in a SKIP header and directing them to the firewall. 409 Therefore, It is simplest to assume that the mobile node operates 410 with a co-located address. 412 6. Supporting Mobile IP: Secure Channel Configurations 414 The mobile node participates in two different types of traffic: 415 Mobile IP registration protocol and data. For the sake of 416 simplicity, the following discussion evaluates different secure 417 channel configurations by examining the initial Registration Request 418 sent by the mobile node to its home agent. 420 Assuming the mobile node operates with a co-located address, it can 421 communicate directly with the firewall. The latter is able to reach 422 the home agent in the private network. Also, the firewall must be 423 able to authenticate the mobile node. 425 The following channel configurations assume the mobile node operates 426 with a co-located address. The region between the HA (home agent) 427 and the FW (firewall) is a private network. The region between the 428 FW and the MN (mobile node) is the outside or public network. 430 6.1 I: Encryption only Outside of Private Network 432 HA FW MN 433 <=====================> SKIP (AH + ESP) 434 <-----------------------------------> Registration Request path 436 The traffic is only encrypted between the mobile node out on the 437 general Internet, and the firewall's external interface. This is 438 minimum required. It is the most desirable configuration as the more 439 expensive encrypted channel is only used where it is necessary: on 440 the public network. 442 6.2 II: End-to-End Encryption 444 Another possible configuration extends the encrypted tunnel through 445 the firewall: 447 HA FW MN 448 <===================================> SKIP (AH + ESP) 449 <-----------------------------------> Registration Request path 451 This limits the firewall to perform a simple packet relay or 452 gatewaying function. Even though this could be accomplished by using 453 the proper destination NSID in the packet, in practice it is 454 probably unrealizable. The reason is that this alternative is 455 probably not very popular with computer security personnel, because 456 authentication is not carried out by the firewall but by the home 457 agent, and the latter's security is potentially much weaker than the 458 former's. 460 6.3 III: End-to-End Encryption, Intermediate Authentication 462 A third alternative is to allow the firewall to be party to the 463 security association between the home agent and the mobile node. 464 After verifying authentication (AH header), the firewall forwards 465 the encrypted packet (ESP hdr) to the home agent. 467 HA FW MN 468 <+++++++++++++++++++++> SKIP authentication 469 <===================================> SKIP encryption 470 <-----------------------------------> Registration Request path 472 Here, SKIP is used to provide intermediate authentication with 473 end-to-end security. Although possible, this option implies that the 474 participating entities must share their long-term private keys with 475 the intermediate node. 477 Whereas Option 2 above is probably not agreeable to security and 478 system administration personnel, option 3 is unsavory to the end 479 user. 481 6.4 IV: Encryption Inside and Outside 483 HA FW MN 484 <============><=====================> SKIP (AH + ESP) 485 <-----------------------------------> Registration Request path 487 Traffic is encrypted on the public as well as on the private 488 network. On the public network, encryption is dictated by a security 489 association between the mobile node and the firewall. On the 490 private network, it is dictated by a security association between 491 the home agent and the firewall. 493 6.5 Choosing a Secure Channel Configuration 495 A potential problem in both options 2 and 3 is that their end-to-end 496 channel components assume that the mobile node and the home agent 497 have reachability to each other. This is generally not the case, as 498 the Internet routing fabric may not have routes to addresses that 499 belong to private networks, and the private routing fabric may 500 ignore how to route to public addresses -- or doing so may be 501 administratively restricted. Therefore, it is necessary for packets 502 to be addressed directly to the firewall, and indirectly -- via some 503 tunneling or relaying capability -- to the real destination on the 504 other side of the firewall. 506 Options 1 and 4 are essentially equivalent. The latter may be 507 considered overkill, because it uses encryption even within the 508 private network, and this is generally not necessary. What is 509 necessary even within the private network is for the home agent to 510 add an encapsulation (not necessarily encrypted) so as to direct 511 datagrams to the mobile node via the firewall. How this 512 encapsulation is achieved is the difference between options 1 and 513 4. Option 4 uses SKIP, while option 1 uses a cleartext 514 encapsulation mechanism. This is obtainable by, for example, using 515 IP in IP encapsulation [2]. 517 Options 1 and 4 are mostly interchangeable, except in pathologically 518 paranoid private networks. For example, option 1 allows a malicious 519 node operation from within the private network to launch a chosen 520 plaintext attack, by sending data through the firewall. 522 In the interest of being conservative, in what follows we assume 523 option 4 (i.e. traffic is encrypted on the general Internet, as well 524 as within the private network. 526 Since the firewall is party to the security associations governing 527 encryption on both the public and private networks, it is always 528 able to inspect the traffic being exchanged by the home agent and 529 the mobile node. If this is of any concern, the home agent and 530 mobile node could set up a bi-directional tunnel and encrypt it. 532 7. Mobile IP Registration Procedure with a SKIP Firewall 534 When roaming within a private network, a mobile node sends 535 Registration Requests directly to its home agent. On the public 536 Internet, it MUST encapsulates the original Registration Request in 537 a SKIP packet destined to the firewall. The mobile node MUST 538 distinguish between "inside" and "outside" addresses. This could be 539 accomplished by a set of rules defining the address ranges. 540 Nevertheless, actual installations may present serious difficulties 541 in defining exactly what is a private address and what is not. 543 Direct human input is a very effective method: it may be obvious to 544 the user that the current point of attachment is outside its private 545 network, and it should be possible to communicate this knowledge to 546 the mobile node software. 548 The home agent must also distinguish between "inside" and "outside" 549 addresses, but lacks the potential benefit of direct user input. 550 Accordingly, it should be possible for the mobile node to 551 communicate that knowledge to the home agent. To accomplish this we 552 define a Traversal Extension to the Registration Requests and 553 Replies. This extension is also useful when traversing multiple 554 firewalls. 556 In spite of the above mechanisms, errors in judgement are to be 557 expected. Accordingly, the firewall SHOULD be configured such that 558 it will still perform its relaying duties even if they are 559 unnecessarily required by a mobile node with an inside care-of 560 address. 562 Upon arriving at a foreign net and acquiring a care-of address, the 563 mobile node must first -- before any data transfer is possible -- 564 initiate a registration procedure. This consists of an authenticated 565 exchange by which the mobile node informs its home agent of its 566 current whereabouts (i.e. its current care-of address), and receives 567 an acknowledgement. This first step of the protocol is very 568 convenient, because the SKIP firewall can use it to dynamically 569 configure its packet filter. 571 The remainder of this section shows the packet formats used. 572 Section 7.1 discusses how a mobile node sends a Registration Request 573 to its home agent via the SKIP firewall. Section 7.2 discusses how 574 the home agent send the corresponding Registration Reply to the 575 mobile node. Section 7.3 defines the Traversal Extension for use 576 with Registration Requests and Replies. 578 7.1. Registration Request through the Firewall 580 The mobile node arrives at a foreign net, and using mechanisms 581 defined by Mobile IP, discovers it has moved away from home. It 582 acquires a local address at the foreign site, and composes a 583 Registration Request meant for its HA. The mobile node must decide 584 whether this packet needs to be processed by SKIP or not. 586 This is not a simple rule triggered by a given destination address. 587 It must be applied whenever the following conditions are met: 589 a) the mobile node is using a care-of address that does not 590 belong to the private network (i.e. the mobile node is 591 currently "outside" its private network), and 593 b) either of: 595 b1) the source address of the packet is the mobile node's 596 home address (e.g. this packet's endpoints are 597 dictated by a connection initiated while at home), or 599 b2) the source address of the packet is the care-of 600 address and the destination address belongs to the 601 private network 603 Since the above conditions are mobility related, it is best for the 604 Mobile IP function in the node to evaluate them, and then request 605 the appropriate security services from SKIP. 607 7.1.1. On the Outside (Public) Network 609 The SKIP module must use the firewall destination address and the 610 firewall's certificate in order to address and encrypt the packet. 611 It encrypts it using SKIP combined with the ESP [6] protocol and 612 possibly the AH [7] protocol. 614 The SKIP header's source NSID equals 1, indicating that the Master 615 Key-ID is the mobile node's home address. Notice that the IP 616 packet's source address corresponds to the care-of address -- an 617 address whose corresponding public key is unknown to the firewall. 619 It is also possible to use Unsigned Diffie-Hellman public values 620 [10]. Doing so greatly reduces SKIP's infrastructure requirements, 621 because there is no need for a Certificate Authority. Of course, for 622 this to be possible the principals' names MUST be securely 623 communicated. 625 REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL 626 +---------------+----------+----+-----+--------------+--------------+ 627 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request | 628 +---------------+----------+----+-----+--------------+--------------+ 630 IP Hdr (SKIP): 631 Source mobile node's care-of address 632 Destination firewall's public (outside) address 634 SKIP Hdr: 635 Source NSID = 1 636 Master Key-ID = IPv4 address of the mobile node 637 Destination NSID = 0 638 Master Key-ID = none 639 Inner IP Hdr: 640 Source mobile node's care-of address 641 Destination home agent's address 643 7.1.2. On the Inside (Private) Network 645 The SKIP Firewall's dynamic packet filtering uses this information 646 to establish a dynamic binding between the care-of address and the 647 mobile node's permanent home address. 649 The destination NSID field in the above packet is zero, prompting 650 the firewall to process the SKIP header and recover the internal 651 packet. It then delivers the original packet to another outbound 652 interface, because it is addressed to the home agent (an address 653 within the private network). Assuming secure channel configuration 654 number 4, the firewall encrypts the packet using SKIP before 655 forwarding to the home agent. 657 REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT 658 +---------------+----------+----+-----+--------------+--------------+ 659 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request | 660 +---------------+----------+----+-----+--------------+--------------+ 662 IP Hdr (SKIP): 663 Source firewall's private (inside) address 664 Destination home agent's address 666 SKIP Hdr: 667 Source NSID = 0 668 Master Key-ID = none 669 Destination NSID = 0 670 Master Key-ID = none 671 Inner IP Hdr: 672 Source mobile node's care-of address 673 Destination home agent's address 675 7.2. Registration Reply through the Firewall 677 The home agent processes the Registration Request, and composes a 678 Registration Reply. Before responding, it examines the care-of 679 address reported by the mobile node, and determines whether or not 680 it corresponds to an outside address. If so, the home agent needs 681 to send all traffic back through the firewall. The home agent can 682 accomplish this by encapsulating the original Registration Reply in 683 a SKIP packet destined to the firewall (i.e. we assume secure 684 channel configuration number 4). 686 7.2.1. On the Inside (Private) Network 688 The packet from the home agent to the mobile node via the SKIP 689 Firewall has the same format as shown above. The relevant fields 690 are: 692 REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL 693 +---------------+----------+----+-----+--------------+------------+ 694 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | 695 +---------------+----------+----+-----+--------------+------------+ 697 IP Hdr (SKIP): 698 Source home agent's address 699 Destination firewall's private (inside) address 701 SKIP Hdr: 702 Source NSID = 0 703 Master Key-ID = none 704 Destination NSID = 0 705 Master Key-ID = none 706 Inner IP Hdr: 707 Source home agent's address 708 Destination mobile node's care-of address 710 7.2.2. On the Outside (Public) Network 712 The SKIP Firewall recovers the original Registration Reply packet 713 and looks at the destination address: the mobile node's care-of 714 address. 716 The SKIP Firewall's dynamic packet filtering used the initial 717 Registration Request (Secton 7.1) to establish a dynamic mapping 718 between the care-of address and the mobile node's Master Key-ID. 719 Hence, before forwarding the Registration Reply, it encrypts it 720 using the mobile node's public key. 722 This dynamic binding capability and the use of tunneling mode ESP 723 obviate the need to extend the Mobile IP protocol with a "relay 724 Registration Request". However, it requires that the Registration 725 Reply exit the private network through the same firewall that 726 forwarded the corresponding Registration Request. 728 Instead of obtaining the mobile node's permanent address from the 729 dynamic binding, a Mobile IP aware firewall could also obtain it 730 from the Registration Reply itself. This renders the firewall 731 stateless, and lets Registration Requests and Replies traverse the 732 periphery of the private network through different firewalls. 734 REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE 735 +---------------+----------+----+-----+--------------+------------+ 736 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | 737 +---------------+----------+----+-----+--------------+------------+ 739 IP Hdr (SKIP): 740 Source firewall's public (outside) address 741 Destination mobile node's care-of address 743 SKIP Hdr: 744 Source NSID = 0 745 Master Key-ID = none 746 Destination NSID = 1 747 Master Key-ID = IPv4 addr of the mobile node 748 Inner IP Hdr: 749 Source home agent's address 750 Destination mobile node's care-of address 752 7.3. Traversal Extension 754 The Traversal Extension MAY be included by mobile nodes in 755 Registration Requests, and by home agents in Registration Replies. 756 As per Section 3.6.1.3 of [1], the Traversal Extension must appear 757 before the Mobile-Home Authentication Extension. A Traversal 758 Extension is an explicit notification that there are one or more 759 traversal points (firewalls, fireridges, etc) between the mobile 760 node and its home agent. Negotiating access past these systems may 761 imply a new authentication header, and possibly a new encapsulating 762 header (perhaps as part of tunnel-mode ESP) whose IP destination 763 address is the traversal address. 765 Negotiating access past traversal points does not necessarily 766 require cryptographic techniques. For example, systems at the 767 boundary between separate IP address spaces must be explicitly 768 targetted (perhaps using unencrypted IP in IP encapsulation). 770 A mobile node SHOULD include one Traversal Extension per traversal 771 point in its Registration Requests. If present, their order MUST 772 exactly match the order in which packets encounters them as they 773 flow from the mobile node towards the home agent. 775 Notice that there may be additional firewalls along the way, but the 776 list of traversal points SHOULD only include those systems with 777 which an explicit negotiation is required. 779 Similarly, the home agent SHOULD include one Traversal Extension per 780 traversal point in its Registration Replies. If present, their 781 order MUST exactly match the order in which packets encounter them 782 as they flow from the home agent to the mobile node. 784 A Traversal Extension does not include any indication about how 785 access is negotiated. Presumably, this information is obtained 786 through separate means. This document does not attempt to solve the 787 firewall discovery problem, that is, it does not specify how to 788 discover the list of traversal points. 790 As per section 1.9 of [1], the type value of 129 implies that if a 791 home agent or a mobile node encounter a Traversal Extension in a 792 Registration Request or Reply, they may silently ignore it. This is 793 consistent with the fact that the Traversal Extension is essentially 794 a hint. 796 0 1 2 3 797 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Type | Length | Reserved | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | MN to HA Traversal Address | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | HA to MN Traversal Address | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Type 808 129 810 Length 812 10 814 Reserved 816 0 818 MN to HA Traversal Address 820 The IP address of the an intermediate system or firewall 821 encountered by datagrams sent by the mobile node towards the 822 home agent. Typically, this is the external address of a 823 firewall or firewall complex. 825 This field MUST be initialized in Registration Requests. In 826 Registration Replies, it is typically all 0's, otherwise, the 827 mobile node must interpret it as a hint. 829 HA to MN Traversal Address 831 The IP address of an intermediate system or firewall 832 encountered by datagrams sent by the home agent towards the 833 mobile node. Typically, this is the internal address of a 834 firewall or firewall complex. 836 This field must be initialized in Registration Replies. In 837 Registration Requests, it is typically all 0's, otherwise, the 838 home agent must interpret it as a hint. 840 8. Data Transfer 842 Data transfer proceeds along lines similar to the Registration 843 Request outlined above. Section 8.1 discusses data traffic sent by 844 a mobile node to a correspondent node. Section 8.2 shows packet 845 formats for the reverse traffic being tunneled by the home agent to 846 the mobile node. 848 8.1. Data Packet From the Mobile Node to a Correspondent Node 850 The mobile node composes a packet destined to a correspondent node 851 located within the private network. 853 The Mobile IP function in the mobile node examines the Inner IP 854 header, and determines that it satisfies conditions "a" and "b1" 855 from Section 7.1. The mobile node requests the proper encryption and 856 encapsulation services from SKIP. 858 Thus, the mobile node with a co-located address sends encrypted 859 traffic to the firewall, using the following format: 861 DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL 862 +---------------+----------+----+-----+--------------+------+ 863 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP | 864 +---------------+----------+----+-----+--------------+------+ 866 IP Hdr (SKIP): 867 Source mobile node's care-of address 868 Destination public (outside) address on the firewall 870 SKIP Hdr: 871 Source NSID = 1 872 Master Key-ID = IPv4 address of the mobile node 873 Destination NSID = 0 874 Master Key-ID = none 875 Inner IP Hdr: 876 Source mobile node's home address 877 Destination correspondent node's address 879 The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr 880 and upper-layer payload (ULP) and checks the destination address. 881 Since the packet is destined to a correspondent node in the private 882 network, the "Inner" IP datagram is delivered internally. Once the 883 SKIP firewall injects this packet into the private network, it is 884 routed independently of its source address. 886 As this last assumption is not always true, the mobile node may 887 construct a bi-directional tunnel with its home agent. Doing so, 888 guarantees that the "Inner IP Hdr" is: 890 Inner IP Hdr: 891 Source care-of address 892 Destination home agent address 894 When at home, communication between the the mobile node and certain 895 external correspondent nodes may need to go through 896 application-specific firewalls or proxies, different from the SKIP 897 firewall. While on the public network, the mobile node's 898 communication with these hosts, MUST use a bi-directional tunnel. 900 8.2. Data Packet From a Correspondent Node to the Mobile Node 902 The home agent intercepts a packet from a correspondent node to the 903 mobile node. It encapsulates it such that the Mobile IP header's 904 source and destination addresses are the home agent and care-of 905 addresses, respectively. This would suffice for delivery within the 906 private network. Since the current care-of address of the mobile 907 node is not within the private network, this packet must be sent via 908 the firewall. The home agent can accomplish this by encapsulating 909 the datagram in a SKIP packet destined to the firewall (i.e. we 910 assume secure channel configuration number 4). 912 8.2.1 Within the Inside (Private) Network 914 From the home agent to the private (inside) address of the 915 firewall the packet format is: 917 DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL 918 +--------+------+----+-----+--------+--------+-----+ 919 | IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP | 920 | (SKIP) | Hdr | | | IP Hdr | IP Hdr | | 921 +--------+------+----+-----+--------+--------+-----+ 923 IP Hdr (SKIP): 924 Source home agent's address 925 Destination private (inside) address on the firewall 927 SKIP Hdr: 928 Source NSID = 0 929 Master Key-ID = none 930 Destination NSID = 0 931 Master Key-ID = none 933 Mobile-IP IP Hdr: 934 Source home agent's address 935 Destination care-of address 937 Inner IP Hdr: 938 Source correspondent node's address 939 Destination mobile node's address 941 ULP: upper-layer payload 943 The packet format above does not require the firewall to have a 944 dynamic binding. The association between the mobile node's permanent 945 address and it care-of address can be deduced from the contents of 946 the "Mobile-IP IP Hdr" and the "Inner IP Hdr". 948 Nevertheless, a nomadic binding is an assurance that currently the 949 mobile node is, in fact, at the care-of address. 951 8.2.2. On the Outside (Public) Network 953 The SKIP firewall intercepts the packet, and recovers the Mobile IP 954 encapsulated datagram. Before sending it out, the dynamic packet 955 filter configured by the original Registration Request triggers 956 encryption of this packet, this time by the SKIP firewall for 957 consumption by the mobile node. The resultant packet is: 959 DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE 960 +--------+------+----+-----+--------+--------+-----+ 961 | IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP | 962 | (SKIP) | Hdr | | | IP Hdr | IP Hdr | | 963 +--------+------+----+-----+--------+--------+-----+ 965 IP Hdr (SKIP): 966 Source firewall's public (outside) address 967 Destination mobile node's care-of address 969 SKIP Hdr: 970 Source NSID = 0 971 Master Key-ID = none 972 Destination NSID = 1 973 Master Key-ID = IPv4 address of the mobile node 975 Mobile-IP IP Hdr: 976 Source home agent's address 977 Destination care-of address 979 Inner IP Hdr: 980 Source correspondent node's address 981 Destination mobile node's address 983 ULP: upper-layer payload 985 At the mobile node, SKIP processes the packets sent by the 986 firewall. Eventually, the inner IP header and the upper-layer 987 packet (ULP) are retrieved and passed on. 989 9. Security Considerations 991 The topic of this document is security. Nevertheless, it is 992 imperative to point out the perils involved in allowing a flow of IP 993 packets through a firewall. In essence, the mobile host itself MUST 994 also take on responsibility for securing the private network, 995 because it extends its periphery. This does not mean it stops 996 exchanging unencrypted IP packets with hosts on the public network. 997 For example, it MAY have to do so in order to satisfy billing 998 requirements imposed by the foreign site, or to renew its DHCP 999 lease. In the latter case it might filter not only on IP source 1000 address, but also on protocol and port numbers. 1002 Therefore, it MUST have some firewall capabilities, otherwise, any 1003 malicious individual that gains access to it will have gained access 1004 to the private network as well. 1006 Acknowledgements 1008 Ideas in this document have benefited from discussions with at 1009 least the following people: Bill Danielson, Martin Patterson, Tom 1010 Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash 1011 Agrawal, Tsutomu Shimomura and Don Hoffman. 1013 References 1015 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 1017 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1018 1996. 1020 [3] A. Aziz and M. Patterson, Design and Implementation of SKIP, 1021 available on-line at http://skip.incog.com/inet-95.ps. A 1022 previous version of the paper was presented at INET '95 under 1023 the title Simple Key Management for Internet Protocols (SKIP), 1024 and appears in the conference proceedings under that title. 1026 [4] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and . Jones. 1027 SOCKS Protocol Version 5. RFC 1928, March 1996. 1029 [5] M. Leech. Username/Password Authentication for SOCKS V5. RFC 1030 1929, March 1996. 1032 [6] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995 1034 [7] R. Atkinson. IP Authentication Header. RFC 1826, August 1035 1995. 1037 [8] Stephen Kent, message to the IETF's IPSEC mailing list, 1038 Message-Id: , September 1039 6, 1996. 1041 [9] Tom Markson, private communication, June 12, 1996. 1043 [10] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned 1044 Diffie-Hellman Public Value. Available on-line as 1045 http://skip.incog.com/spec/EUDH.html. 1047 Authors' Addresses 1049 Gabriel E. Montenegro 1050 Sun Microsystems, Inc. 1051 901 San Antonio Road 1052 Mailstop UMPK 15-214 1053 Mountain View, California 94303 1055 Tel: (415)786-6288 1056 Fax: (415)786-6445 1058 gabriel.montenegro@Eng.Sun.COM 1060 Vipul Gupta 1061 Sun Microsystems, Inc. 1062 901 San Antonio Road 1063 Mailstop UMPK 15-214 1064 Mountain View, California 94303 1066 Tel: (415)786-3614 1067 Fax: (415)786-6445 1069 vipul.gupta@Eng.Sun.COM