idnits 2.17.1 draft-montenegro-firewall-sup-02.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-23) 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 218: '...is, the firewall MUST be explicitly ta...' RFC 2119 keyword, line 314: '...he firewall also MUST have, be able to...' RFC 2119 keyword, line 355: '...". Furthermore, incoming packets MUST...' RFC 2119 keyword, line 391: '...n. The firewall MUST be able to obtai...' RFC 2119 keyword, line 423: '...te network. Also, the firewall MUST be...' (19 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 (November 11, 1997) is 9660 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. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro 3 INTERNET DRAFT V. Gupta 4 Sun Microsystems, Inc. 5 November 11, 1997 7 Firewall Support for Mobile IP 8 draft-montenegro-firewall-sup-02.txt 10 Status of This Memo 12 This document is a submission to the Mobile IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 either to the authors, or to the mobile-ip@SmallWorks.COM mailing 15 list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet- Drafts as 27 reference material or to cite them other than as ``work in 28 progress.'' 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 32 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Abstract 38 The Mobile IP specification establishes the mechanisms that enable a 39 mobile host to maintain and use the same IP address as it changes 40 its point of attachment to the network. Mobility implies higher 41 security risks than static operation, because the traffic may at 42 times take unforeseen network paths with unknown or unpredictable 43 security characteristics. The Mobile IP specification makes no 44 provisions for securing data traffic. The mechanisms described in 45 this document allow a mobile node out on a public sector of the 46 internet to negotiate access past a SKIP firewall, and construct a 47 secure channel into its home network. 49 In addition to securing traffic, our mechanisms allow a mobile node 50 to roam into regions that (1) impose ingress filtering, and (2) use 51 a different address space. 53 Table of Contents 55 1. Introduction ................................................... 4 56 2. Mobility without a Firewall .................................... 6 57 3. Restrictions imposed by a Firewall ............................. 6 58 4. Two Firewall Options: Application relay and IP Security ........ 7 59 4.1 SOCKS version 5 [4] ........................................... 7 60 4.2 SKIP [3] ...................................................... 8 61 5. Agents and Mobile Node Configurations .......................... 10 62 6. Supporting Mobile IP: Secure Channel Configurations ............ 11 63 6.1 I: Encryption only Outside of Private Network ................. 11 64 6.2 II: End-to-End Encryption ..................................... 12 65 6.3 III: End-to-End Encryption, Intermediate Authentication ....... 12 66 6.4 IV: Encryption Inside and Outside ............................. 13 67 6.5 Choosing a Secure Channel Configuration ....................... 13 68 7. Mobile IP Registration Procedure with a SKIP Firewall .......... 14 69 7.1. Registration Request through the Firewall .................... 15 70 7.1.1. On the Outside (Public) Network ............................ 16 71 7.1.2. On the Inside (Private) Network ............................ 16 72 7.2. Registration Reply through the Firewall ...................... 17 73 7.2.1. On the Inside (Private) Network ............................ 17 74 7.2.2. On the Outside (Public) Network ............................ 18 75 7.3. Traversal Extension .......................................... 19 76 8. Data Transfer .................................................. 21 77 8.1. Data Packet From the Mobile Node to a Correspondent Node ..... 21 78 8.2. Data Packet From a Correspondent Node to the Mobile Node ..... 22 79 8.2.1 Within the Inside (Private) Network ......................... 23 80 8.2.2. On the Outside (Public) Network ............................ 24 81 9. Security Considerations ........................................ 24 82 Acknowledgements .................................................. 25 83 References ........................................................ 25 84 1. Introduction 86 This document specifies what support is required at the firewall, 87 the Mobile IP [1] home agent and the Mobile IP mobile node to enable 88 the latter to access a private network from the Internet. For 89 example, a company employee could attach his/her laptop to some 90 Internet access point by: 92 a) Dialing into a PPP/SLIP account on an Internet service 93 provider's network. 95 b) Connecting into a 10Base-T or similar LAN network available 96 at, for example, an IETF terminal room, a local university, 97 or another company's premises. 99 Notice that in these examples, the mobile node's relevant interface 100 (PPP or 10Base-T) is configured with an IP address different from 101 that which it uses "normally" (i.e. at the office). Furthermore, the 102 IP address used is not necessarily a fixed assignment. It may be 103 assigned temporarily and dynamically at the beginning of the session 104 (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case). 106 The following discussion assumes a network configuration consisting 107 of a private network separated by a firewall from the general 108 Internet or public network. The systems involved are: 110 Private Network 112 A protected network separated from the Internet by hosts 113 enforcing access restrictions (firewalls). A private network 114 may use a private address space, and its addresses may not 115 even be routable by the general internet. 117 Public Network 119 The Internet at large. Hosts are able to communicate with each 120 other throughout the public network without firewall-imposed 121 restrictions. 123 Mobile Node (MN) 125 Its permanent address falls within the range of the private 126 network. The user removes the system from its home network, 127 and connects it to the Internet at another point. The 128 mechanisms outlined in this discussion render this mobility 129 transparent: the mobile node continues accessing its home 130 network and its resources exactly as if it were still within 131 it. Notice that when the mobile node leaves its home 132 network, it may migrate both within and outside of the 133 private network's boundaries. As defined by Mobile IP [1], a 134 mobile node uses a care-of address while roaming. 136 Home Agent (HA) for the mobile node 138 Serves as a location registry and router as described in the 139 Mobile IP IETF draft. 141 Foreign Agent (FA) 143 Serves as a registration relayer and care of address for the 144 mobile node as described in the Mobile IP IETF draft. 146 Correspondent Node (CH) 148 A system that is exchanging data packets with the mobile 149 node. 151 Firewall (FW) 153 The system (or collection of systems) that enforces access 154 control between the private network and the general Internet. 155 It may do so by a combination of functions such as application 156 gatewaying, packet filtering and cryptographic techniques. 158 The mechanisms described in this document allow a mobile node out on 159 a public sector of the network to negotiate access past a SKIP 160 firewall, and construct a secure channel into its home network. 161 This enables it to communicate with correspondent nodes that belong 162 to the private network, and, if bi-directional tunnels are used, 163 with external hosts that are reachable when the mobile node is at 164 home. The mobile node enjoys the same level of connectivity and 165 privacy as it does when it is in its home network. 167 This document does not address the scenario in which the mobile 168 node attempts to access its private network, while within another 169 private network. 171 Sections 2 and 3 provide an overview of the environment being 172 considered and the restrictions it imposes. Section 4 examines 173 firewall technologies. Section 5 discusses the best mode of 174 operation of the participating entities from the point of view of 175 Mobile IP. Section 6 discusses possible configuration for the 176 secure channel. Finally, packet formats are the topic of sections 7 177 and 8. 179 2. Mobility without a Firewall 181 Suppose the mobile node is roaming throughout the general Internet, 182 but its home network is not protected by a firewall. This is 183 typically found in academic environment as opposed to corporate 184 networks. 186 This works as prescribed by Mobile IP [1]. The only proviso is that 187 the mobile node would most probably operate with a co-located 188 address instead of using a separate foreign agent's care-of 189 address. This is because, at least in the near term, it is far more 190 likely to be able to secure a temporary care-of-address than it is 191 to find a foreign agent already deployed at the site you are 192 visiting. For example: 194 - Internet Service Provider: pre-assigns customers IP addresses, 195 or assigns them out dynamically via PPP's address negotiation. 197 - An IETF terminal room may pre-assign addresses for your use or 198 offer DHCP services. 200 - Other locations probably would offer DHCP services. 202 3. Restrictions imposed by a Firewall 204 The firewall imposes restrictions on packets entering or leaving the 205 private network. Packets are not allowed through unless they conform 206 to a filtering specification, or unless there is a negotiation 207 involving some sort of authentication. 209 Another restriction is imposed by the separation between private 210 addresses and general Internet addresses. Strictly speaking, this is 211 not imposed by a firewall, but by the characteristics of the private 212 network. For example, if a packet destined to an internal address 213 originates in the general Internet, it will probably not be 214 delivered. It is not that the firewall drops it. Rather, the 215 Internet's routing fabric is unable to process it. This elicits an 216 ICMP host unreachable packet sent back to the originating node. 218 Because of this, the firewall MUST be explicitly targeted as the 219 destination node by outside packets seeking to enter the private 220 network. The routing fabric in the general Internet will only see 221 the public address of the firewall and route accordingly. Once the 222 packet arrives at the firewall, the real packet destined to a 223 private address is recovered. 225 4. Two Firewall Options: Application relay and IP Security 227 Before delving into any details, lets examine two technologies which 228 may provide firewall support for mobile nodes: 230 - application relaying or proxying, or 232 - IP Security. 234 To understand the implications, let's examine two specific schemes 235 to accomplish the above: SOCKS version 5 and SKIP. 237 4.1 SOCKS version 5 [4] 239 There is an effort within the authenticated firewall traversal WG 240 (aft) of the IETF to provide a common interface for application 241 relays. 243 The solution being proposed is a revised specification of the SOCKS 244 protocol. Version 5 has been extended to include UDP services as 245 well. The SOCKS solution requires that the mobile node -- or 246 another node on its behalf -- establish a TCP session to exchange 247 UDP traffic with the FW. It also has to use the SOCKS library to 248 encapsulate the traffic meant for the FW. The steps required by a 249 SOCKS solution are: 251 - TCP connection established to port 1080 (1.5 round trips) 253 - version identifier/method selection negotiation (1 round trip) 254 - method-dependent negotiation. For example, the 255 Username/Password Authentication [5] requires 1 round trip: 257 1. client sends a Username/Password request 258 2. FW (server) responds 260 The GSS-API negotiation requires at least 3 round trips: 262 1. client context establishment (at least 1 round trip) 263 2. client initial token/server reply (1 round trip) 264 3. message protection subnegotiation (at least 1 round trip) 266 - (finally) SOCKS request/reply (1 round trip) 268 This is a minimum of 4 (6 with GSS-API) round-trips before the 269 client is able to pass data through the FW using the following 270 header: 272 +----+------+------+----------+----------+----------+ 273 |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | 274 +----+------+------+----------+----------+----------+ 275 | 2 | 1 | 1 | Variable | 2 | Variable | 276 +----+------+------+----------+----------+----------+ 278 Bear in mind that the above must be done each time the mobile 279 registers a new care-of address. In addition to this inefficiency, 280 this scheme requires that we use UDP to encapsulate IP datagrams. 281 There is at least one commercial network that does this, but it is 282 not the best solution. 284 Furthermore, SOCKS defines how to establish authenticated 285 connections, but currently it does not provide a clear solution to 286 the problem of encrypting the traffic. 288 This header contains the relay information needed by all parties 289 involved to reach those not directly reachable. 291 4.2 SKIP [3] 293 Alternatively, traffic from the mobile node to the firewall could be 294 encrypted and authenticated using a session-less IP security 295 mechanism like SKIP. This obviates the need to set up a session 296 just to exchange UDP traffic with the firewall. 298 A solution based on SKIP is very attractive in this scenario, as no 299 round trip times are incurred before the mobile node and the 300 firewall achieve mutual trust: the firewall can start relaying 301 packets for the mobile node as soon as it receives the first one. 302 This, of course, implies that SKIP is being used with AH [7] so that 303 authentication information is contained in each packet. Encryption 304 by using ESP [6] is also assumed in this scenario, since the 305 Internet at large is considered a hostile environment. An ESP 306 transform that provides both authentication and encryption could be 307 used, in which case the AH header need not be included. 309 The firewall and the mobile node may be previously configured with 310 each other's authenticated Diffie-Hellman public components (also 311 known as public values). Alternatively, they could exchange them in 312 real-time using any of the mechanisms defined by the SKIP protocol 313 (on-line certificate directory service or certificate discovery 314 protocol). Home agents and the firewall also MUST have, be able to 315 exchange or obtain each other's public components. 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 component". Similarly, setting 345 NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates. 347 In this case, the MKID is set to the MD5 hash of the DH public 348 component [10]. 350 In addition to the NSID/MKID feature, Mobile IP is best supported by 351 an appropriate policy at the SKIP firewall in the form of a 352 "nomadic" access control list entry. This is an entry which is 353 filtered by key ID, instead of by IP source address, as is the usual 354 case. It translates to "allow access from any IP source address for 355 a given NSID/MKID combination". Furthermore, incoming packets MUST 356 have an AH header, so that after properly authenticating them, the 357 firewall establishes a "current address" or "dynamic binding" for 358 the nomadic host. The NSID/MKID combination determines which key 359 should be used with the nomadic host [9]. 361 Notice that this supports Mobile IP, because the mobile node always 362 initiates contact. Hence, the SKIP firewall has a chance to learn 363 the mobile node's "current address" from an incoming packet before 364 it attempts to encrypt an outgoing packet. 366 However, this precludes the use of simultaneous bindings by a mobile 367 node. At the firewall, the last Registration Request sent by the 368 mobile node replaces the association between its permanent address 369 and any prior care-of address. In order to support simultaneous 370 bindings the firewall must be able to interpret Mobile IP 371 registration messages. 373 Section 7.2.2 discusses another advantage of making the firewall 374 understand Mobile IP packet formats. 376 In what follows we assume a SKIP-based solution. 378 5. Agents and Mobile Node Configurations 380 Depending on which address it uses as its tunnel endpoint, the 381 Mobile IP protocol specifies two ways in which a mobile node can 382 register a mobility binding with its home agent. 384 a) an address advertised for that purpose by the foreign agent 386 b) an address belonging to one of the mobile node's interfaces 387 (i.e. operation with a co-located address). 389 From the firewall's point of view, the main difference between these 390 two cases hinges on which node prepares the outermost encrypting 391 encapsulation. The firewall MUST be able to obtain the 392 Diffie-Hellman public component of the node that creates the 393 outermost SKIP header in an incoming packet. This is only possible 394 to guarantee in case "b", because the mobile node and the firewall 395 both belong to the same administrative domain. The problem is even 396 more apparent when the mobile node attempts a Registration Request. 397 Here, the foreign agent is not just a relayer, it actually examines 398 the packet sent by the mobile node, and modifies its agent services 399 accordingly. In short, assuming the current specification of Mobile 400 IP and the current lack of trust in the internet at large, only case 401 "b" is possible. Case "a" would require an extension (e.g. a "relay" 402 Registration Request), and modifying code at the home agent, the 403 firewall and the foreign agent. 405 Assuming that the firewall offers a secure relay service (i.e. 406 decapsulation and forwarding of packets), the mobile node can reach 407 addresses internal to the private network by encapsulating the 408 packets in a SKIP header and directing them to the firewall. 410 Therefore, It is simplest to assume that the mobile node operates 411 with a co-located address. 413 6. Supporting Mobile IP: Secure Channel Configurations 415 The mobile node participates in two different types of traffic: 416 Mobile IP registration protocol and data. For the sake of 417 simplicity, the following discussion evaluates different secure 418 channel configurations by examining the initial Registration Request 419 sent by the mobile node to its home agent. 421 Assuming the mobile node operates with a co-located address, it can 422 communicate directly with the firewall. The latter is able to reach 423 the home agent in the private network. Also, the firewall MUST be 424 able to authenticate the mobile node. 426 The following channel configurations assume the mobile node operates 427 with a co-located address. The region between the HA (home agent) 428 and the FW (firewall) is a private network. The region between the 429 FW and the MN (mobile node) is the outside or public network. 431 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 disclose their pairwise long-term 475 Diffie-Hellman shared secret to 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 can exchange IP traffic directly with each other. This is generally 498 not the case, as the Internet routing fabric may not have routes to 499 addresses that belong to private networks, and the private routing 500 fabric may ignore how to route to public addresses -- or doing so 501 may be administratively restricted. Therefore, it is necessary for 502 packets to be addressed directly to the firewall, and indirectly -- 503 via some tunneling or relaying capability -- to the real destination 504 on the 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. The type of 512 encapsulation used determines the difference between options 1 and 513 4. Whereas option 4 uses SKIP, 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. The difference is, of 518 course, that the former does not protect the data from eavesdroppers 519 within the private network itself. This may be unacceptable in 520 certain cases. Traffic from some departments in a company (for 521 example payroll or legal) may need to be encrypted as it traverses 522 other sections of the company. 524 In the interest of being conservative, in what follows we assume 525 option 4 (i.e. traffic is encrypted on the general Internet, as well 526 as within the private network. 528 Since the firewall is party to the security associations governing 529 encryption on both the public and private networks, it is always 530 able to inspect the traffic being exchanged by the home agent and 531 the mobile node. If this is of any concern, the home agent and 532 mobile node could set up a bi-directional tunnel and encrypt it. 534 7. Mobile IP Registration Procedure with a SKIP Firewall 536 When roaming within a private network, a mobile node sends 537 Registration Requests directly to its home agent. On the public 538 Internet, it MUST encapsulate the original Registration Request in a 539 SKIP packet destined to the firewall. The mobile node MUST 540 distinguish between "inside" and "outside" addresses. This could be 541 accomplished by a set of rules defining the address ranges. 542 Nevertheless, actual installations may present serious difficulties 543 in defining exactly what is a private address and what is not. 545 Direct human input is a very effective method: it may be obvious to 546 the user that the current point of attachment is outside its private 547 network, and it should be possible to communicate this knowledge to 548 the mobile node software. 550 The home agent must also distinguish between "inside" and "outside" 551 addresses, but lacks the potential benefit of direct user input. 552 Accordingly, it should be possible for the mobile node to 553 communicate that knowledge to the home agent. To accomplish this we 554 define a Traversal Extension to the Registration Requests and 555 Replies. This extension is also useful when traversing multiple 556 firewalls. 558 In spite of the above mechanisms, errors in judgement are to be 559 expected. Accordingly, the firewall SHOULD be configured such that 560 it will still perform its relaying duties even if they are 561 unnecessarily required by a mobile node with an inside care-of 562 address. 564 Upon arriving at a foreign net and acquiring a care-of address, the 565 mobile node must first -- before any data transfer is possible -- 566 initiate a registration procedure. This consists of an authenticated 567 exchange by which the mobile node informs its home agent of its 568 current whereabouts (i.e. its current care-of address), and receives 569 an acknowledgement. This first step of the protocol is very 570 convenient, because the SKIP firewall can use it to dynamically 571 configure its packet filter. 573 The remainder of this section shows the packet formats used. 574 Section 7.1 discusses how a mobile node sends a Registration Request 575 to its home agent via the SKIP firewall. Section 7.2 discusses how 576 the home agent send the corresponding Registration Reply to the 577 mobile node. Section 7.3 defines the Traversal Extension for use 578 with Registration Requests and Replies. 580 7.1. Registration Request through the Firewall 582 The mobile node arrives at a foreign net, and using mechanisms 583 defined by Mobile IP, discovers it has moved away from home. It 584 acquires a local address at the foreign site, and composes a 585 Registration Request meant for its home agent. The mobile node must 586 decide whether this packet needs to be processed by SKIP or not. 588 This is not a simple rule triggered by a given destination address. 589 It must be applied whenever the following conditions are met: 591 a) the mobile node is using a care-of address that does not 592 belong to the private network (i.e. the mobile node is 593 currently "outside" its private network), and 595 b) either of: 597 b1) the source address of the packet is the mobile node's 598 home address (e.g. this packet's endpoints are 599 dictated by a connection initiated while at home), or 601 b2) the source address of the packet is the care-of 602 address and the destination address belongs to the 603 private network 605 Since the above conditions are mobility related, it is best for the 606 Mobile IP function in the node to evaluate them, and then request 607 the appropriate security services from SKIP. 609 7.1.1. On the Outside (Public) Network 611 The SKIP module must use the firewall destination address and the 612 firewall's certificate in order to address and encrypt the packet. 613 It encrypts it using SKIP combined with the ESP [6] protocol and 614 possibly the AH [7] protocol. 616 The SKIP header's source NSID equals 1, indicating that the Master 617 Key-ID is the mobile node's home address. Notice that the IP 618 packet's source address corresponds to the care-of address -- an 619 address whose corresponding public component is unknown to the 620 firewall. 622 It is also possible to use Unsigned Diffie-Hellman public components 623 [10]. Doing so greatly reduces SKIP's infrastructure requirements, 624 because there is no need for a Certificate Authority. Of course, for 625 this to be possible the principals' names MUST be securely 626 communicated. 628 REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL 629 +---------------+----------+----+-----+--------------+--------------+ 630 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request | 631 +---------------+----------+----+-----+--------------+--------------+ 633 IP Hdr (SKIP): 634 Source mobile node's care-of address 635 Destination firewall's public (outside) address 637 SKIP Hdr: 638 Source NSID = 1 639 Master Key-ID = IPv4 address of the mobile node 640 Destination NSID = 0 641 Master Key-ID = none 642 Inner IP Hdr: 643 Source mobile node's care-of address 644 Destination home agent's address 646 7.1.2. On the Inside (Private) Network 648 The SKIP Firewall's dynamic packet filtering uses this information 649 to establish a dynamic binding between the care-of address and the 650 mobile node's permanent home address. 652 The destination NSID field in the above packet is zero, prompting 653 the firewall to process the SKIP header and recover the internal 654 packet. It then delivers the original packet to another outbound 655 interface, because it is addressed to the home agent (an address 656 within the private network). Assuming secure channel configuration 657 number 4, the firewall encrypts the packet using SKIP before 658 forwarding to the home agent. 660 REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT 661 +---------------+----------+----+-----+--------------+--------------+ 662 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request | 663 +---------------+----------+----+-----+--------------+--------------+ 665 IP Hdr (SKIP): 666 Source firewall's private (inside) address 667 Destination home agent's address 669 SKIP Hdr: 670 Source NSID = 0 671 Master Key-ID = none 672 Destination NSID = 0 673 Master Key-ID = none 674 Inner IP Hdr: 675 Source mobile node's care-of address 676 Destination home agent's address 678 7.2. Registration Reply through the Firewall 680 The home agent processes the Registration Request, and composes a 681 Registration Reply. Before responding, it examines the care-of 682 address reported by the mobile node, and determines whether or not 683 it corresponds to an outside address. If so, the home agent needs 684 to send all traffic back through the firewall. The home agent can 685 accomplish this by encapsulating the original Registration Reply in 686 a SKIP packet destined to the firewall (i.e. we assume secure 687 channel configuration number 4). 689 7.2.1. On the Inside (Private) Network 690 The packet from the home agent to the mobile node via the SKIP 691 Firewall has the same format as shown above. The relevant fields 692 are: 694 REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL 695 +---------------+----------+----+-----+--------------+------------+ 696 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | 697 +---------------+----------+----+-----+--------------+------------+ 699 IP Hdr (SKIP): 700 Source home agent's address 701 Destination firewall's private (inside) address 703 SKIP Hdr: 704 Source NSID = 0 705 Master Key-ID = none 706 Destination NSID = 0 707 Master Key-ID = none 708 Inner IP Hdr: 709 Source home agent's address 710 Destination mobile node's care-of address 712 7.2.2. On the Outside (Public) Network 714 The SKIP Firewall recovers the original Registration Reply packet 715 and looks at the destination address: the mobile node's care-of 716 address. 718 The SKIP Firewall's dynamic packet filtering used the initial 719 Registration Request (Secton 7.1) to establish a dynamic mapping 720 between the care-of address and the mobile node's Master Key-ID. 721 Hence, before forwarding the Registration Reply, it encrypts it 722 using the mobile node's public component. 724 This dynamic binding capability and the use of tunneling mode ESP 725 obviate the need to extend the Mobile IP protocol with a "relay 726 Registration Request". However, it requires that the Registration 727 Reply exit the private network through the same firewall that 728 forwarded the corresponding Registration Request. 730 Instead of obtaining the mobile node's permanent address from the 731 dynamic binding, a Mobile IP aware firewall could also obtain it 732 from the Registration Reply itself. This renders the firewall 733 stateless, and lets Registration Requests and Replies traverse the 734 periphery of the private network through different firewalls. 736 REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE 737 +---------------+----------+----+-----+--------------+------------+ 738 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | 739 +---------------+----------+----+-----+--------------+------------+ 741 IP Hdr (SKIP): 742 Source firewall's public (outside) address 743 Destination mobile node's care-of address 745 SKIP Hdr: 746 Source NSID = 0 747 Master Key-ID = none 748 Destination NSID = 1 749 Master Key-ID = IPv4 addr of the mobile node 750 Inner IP Hdr: 751 Source home agent's address 752 Destination mobile node's care-of address 754 7.3. Traversal Extension 756 The Traversal Extension MAY be included by mobile nodes in 757 Registration Requests, and by home agents in Registration Replies. 758 As per Section 3.6.1.3 of [1], the Traversal Extension must appear 759 before the Mobile-Home Authentication Extension. A Traversal 760 Extension is an explicit notification that there are one or more 761 traversal points (firewalls, fireridges, etc) between the mobile 762 node and its home agent. Negotiating access past these systems may 763 imply a new authentication header, and possibly a new encapsulating 764 header (perhaps as part of tunnel-mode ESP) whose IP destination 765 address is the traversal address. 767 Negotiating access past traversal points does not necessarily 768 require cryptographic techniques. For example, systems at the 769 boundary between separate IP address spaces must be explicitly 770 targetted (perhaps using unencrypted IP in IP encapsulation). 772 A mobile node SHOULD include one Traversal Extension per traversal 773 point in its Registration Requests. If present, their order MUST 774 exactly match the order in which packets encounter them as they flow 775 from the mobile node towards the home agent. 777 Notice that there may be additional firewalls along the way, but the 778 list of traversal points SHOULD only include those systems with 779 which an explicit negotiation is required. 781 Similarly, the home agent SHOULD include one Traversal Extension per 782 traversal point in its Registration Replies. If present, their 783 order MUST exactly match the order in which packets encounter them 784 as they flow from the home agent to the mobile node. 786 A Traversal Extension does not include any indication about how 787 access is negotiated. Presumably, this information is obtained 788 through separate means. This document does not attempt to solve the 789 firewall discovery problem, that is, it does not specify how to 790 discover the list of traversal points. 792 As per section 1.9 of [1], the fact that the type value falls within 793 the range 128 to 255 implies that if a home agent or a mobile node 794 encounter a Traversal Extension in a Registration Request or Reply, 795 they may silently ignore it. This is consistent with the fact that 796 the Traversal Extension is essentially a hint. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | Reserved | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | MN to HA Traversal Address | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | HA to MN Traversal Address | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Type 810 TBD [Note: Need a number in the range 128 to 255.] 812 Length 814 10 816 Reserved 818 0 820 MN to HA Traversal Address 822 The IP address of the an intermediate system or firewall 823 encountered by datagrams sent by the mobile node towards the 824 home agent. Typically, this is the external address of a 825 firewall or firewall complex. 827 This field MUST be initialized in Registration Requests. In 828 Registration Replies, it is typically all 0's, otherwise, the 829 mobile node SHOULD interpret it as a hint. 831 HA to MN Traversal Address 833 The IP address of an intermediate system or firewall 834 encountered by datagrams sent by the home agent towards the 835 mobile node. Typically, this is the internal address of a 836 firewall or firewall complex. 838 This field MUST be initialized in Registration Replies. In 839 Registration Requests, it is typically all 0's, otherwise, the 840 home agent SHOULD interpret it as a hint. 842 8. Data Transfer 844 Data transfer proceeds along lines similar to the Registration 845 Request outlined above. Section 8.1 discusses data traffic sent by 846 a mobile node to a correspondent node. Section 8.2 shows packet 847 formats for the reverse traffic being tunneled by the home agent to 848 the mobile node. 850 8.1. Data Packet From the Mobile Node to a Correspondent Node 852 The mobile node composes a packet destined to a correspondent node 853 located within the private network. 855 The Mobile IP function in the mobile node examines the Inner IP 856 header, and determines that it satisfies conditions "a" and "b1" 857 from Section 7.1. The mobile node requests the proper encryption and 858 encapsulation services from SKIP. 860 Thus, the mobile node with a co-located address sends encrypted 861 traffic to the firewall, using the following format: 863 DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL 864 +---------------+----------+----+-----+--------------+------+ 865 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP | 866 +---------------+----------+----+-----+--------------+------+ 868 IP Hdr (SKIP): 869 Source mobile node's care-of address 870 Destination public (outside) address on the firewall 872 SKIP Hdr: 873 Source NSID = 1 874 Master Key-ID = IPv4 address of the mobile node 875 Destination NSID = 0 876 Master Key-ID = none 877 Inner IP Hdr: 878 Source mobile node's home address 879 Destination correspondent node's address 881 The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr 882 and upper-layer payload (ULP) and checks the destination address. 883 Since the packet is destined to a correspondent node in the private 884 network, the "Inner" IP datagram is delivered internally. Once the 885 SKIP firewall injects this packet into the private network, it is 886 routed independently of its source address. 888 As this last assumption is not always true, the mobile node may 889 construct a bi-directional tunnel with its home agent. Doing so, 890 guarantees that the "Inner IP Hdr" is: 892 Inner IP Hdr: 893 Source care-of address 894 Destination home agent address 896 When at home, communication between the the mobile node and certain 897 external correspondent nodes may need to go through 898 application-specific firewalls or proxies, different from the SKIP 899 firewall. While on the public network, the mobile node's 900 communication with these hosts, MUST use a bi-directional tunnel. 902 8.2. Data Packet From a Correspondent Node to the Mobile Node 904 The home agent intercepts a packet from a correspondent node to the 905 mobile node. It encapsulates it such that the Mobile IP 906 encapsulating IP header's source and destination addresses are the 907 home agent and care-of addresses, respectively. This would suffice 908 for delivery within the private network. Since the current care-of 909 address of the mobile node is not within the private network, this 910 packet MUST be sent via the firewall. The home agent can accomplish 911 this by encapsulating the datagram in a SKIP packet destined to the 912 firewall (i.e. we assume secure channel configuration number 4). 914 8.2.1 Within the Inside (Private) Network 916 From the home agent to the private (inside) address of the 917 firewall the packet format is: 919 DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL 920 +--------+------+----+-----+--------+--------+-----+ 921 | IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP | 922 | (SKIP) | Hdr | | | IP Hdr | IP Hdr | | 923 +--------+------+----+-----+--------+--------+-----+ 925 IP Hdr (SKIP): 926 Source home agent's address 927 Destination private (inside) address on the firewall 929 SKIP Hdr: 930 Source NSID = 0 931 Master Key-ID = none 932 Destination NSID = 0 933 Master Key-ID = none 935 Mobile-IP IP Hdr: 936 Source home agent's address 937 Destination care-of address 939 Inner IP Hdr: 940 Source correspondent node's address 941 Destination mobile node's address 943 ULP: upper-layer payload 945 The packet format above does not require the firewall to have a 946 dynamic binding. The association between the mobile node's permanent 947 address and it care-of address can be deduced from the contents of 948 the "Mobile-IP IP Hdr" and the "Inner IP Hdr". 950 Nevertheless, a nomadic binding is an assurance that currently the 951 mobile node is, in fact, at the care-of address. 953 8.2.2. On the Outside (Public) Network 955 The SKIP firewall intercepts the packet, and recovers the Mobile IP 956 encapsulated datagram. Before sending it out, the dynamic packet 957 filter configured by the original Registration Request triggers 958 encryption of this packet, this time by the SKIP firewall for 959 consumption by the mobile node. The resultant packet is: 961 DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE 962 +--------+------+----+-----+--------+--------+-----+ 963 | IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP | 964 | (SKIP) | Hdr | | | IP Hdr | IP Hdr | | 965 +--------+------+----+-----+--------+--------+-----+ 967 IP Hdr (SKIP): 968 Source firewall's public (outside) address 969 Destination mobile node's care-of address 971 SKIP Hdr: 972 Source NSID = 0 973 Master Key-ID = none 974 Destination NSID = 1 975 Master Key-ID = IPv4 address of the mobile node 977 Mobile-IP IP Hdr: 978 Source home agent's address 979 Destination care-of address 981 Inner IP Hdr: 982 Source correspondent node's address 983 Destination mobile node's address 985 ULP: upper-layer payload 987 At the mobile node, SKIP processes the packets sent by the 988 firewall. Eventually, the inner IP header and the upper-layer 989 packet (ULP) are retrieved and passed on. 991 9. Security Considerations 993 The topic of this document is security. Nevertheless, it is 994 imperative to point out the perils involved in allowing a flow of IP 995 packets through a firewall. In essence, the mobile host itself MUST 996 also take on responsibility for securing the private network, 997 because it extends its periphery. This does not mean it stops 998 exchanging unencrypted IP packets with hosts on the public network. 999 For example, it MAY have to do so in order to satisfy billing 1000 requirements imposed by the foreign site, or to renew its DHCP 1001 lease. In the latter case it might filter not only on IP source 1002 address, but also on protocol and port numbers. 1004 Therefore, it MUST have some firewall capabilities, otherwise, any 1005 malicious individual that gains access to it will have gained access 1006 to the private network as well. 1008 Acknowledgements 1010 Ideas in this document have benefited from discussions with at 1011 least the following people: Bill Danielson, Martin Patterson, Tom 1012 Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash 1013 Agrawal, Tsutomu Shimomura and Don Hoffman. Jim Solomon has also 1014 provided many helpful comments on this document. 1016 References 1018 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 1020 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1021 1996. 1023 [3] A. Aziz and M. Patterson, Design and Implementation of SKIP, 1024 available on-line at http://skip.incog.com/inet-95.ps. A 1025 previous version of the paper was presented at INET '95 under 1026 the title Simple Key Management for Internet Protocols (SKIP), 1027 and appears in the conference proceedings under that title. 1029 [4] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and . Jones. 1030 SOCKS Protocol Version 5. RFC 1928, March 1996. 1032 [5] M. Leech. Username/Password Authentication for SOCKS V5. RFC 1033 1929, March 1996. 1035 [6] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995 1037 [7] R. Atkinson. IP Authentication Header. RFC 1826, August 1038 1995. 1040 [8] Stephen Kent, message to the IETF's IPSEC mailing list, 1041 Message-Id: , September 1042 6, 1996. 1044 [9] Tom Markson, private communication, June 12, 1996. 1046 [10] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned 1047 Diffie-Hellman Public Value. Available on-line as 1048 http://skip.incog.com/spec/EUDH.html. 1050 Authors' Addresses 1052 Gabriel E. Montenegro 1053 Sun Microsystems, Inc. 1054 901 San Antonio Road 1055 Mailstop UMPK 15-214 1056 Mountain View, California 94303 1058 Tel: (415)786-6288 1059 Fax: (415)786-6445 1061 gabriel.montenegro@Eng.Sun.COM 1063 Vipul Gupta 1064 Sun Microsystems, Inc. 1065 901 San Antonio Road 1066 Mailstop UMPK 15-214 1067 Mountain View, California 94303 1069 Tel: (415)786-3614 1070 Fax: (415)786-6445 1072 vipul.gupta@Eng.Sun.COM