idnits 2.17.1 draft-montenegro-firewall-sup-00.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-19) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 311: '...Incoming packets MUST have an AH heade...' RFC 2119 keyword, line 332: '...rincipals' names MUST be securely comm...' RFC 2119 keyword, line 439: '...ected IP traffic MAY be realized, if p...' RFC 2119 keyword, line 505: '... Internet, it MUST encapsulates the ...' RFC 2119 keyword, line 506: '...to the firewall. The mobile node MUST...' (7 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 (September 13, 1996) is 10080 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) == Unused Reference: '3' is defined on line 921, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 945, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1827 (ref. '9') (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 1826 (ref. '10') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 12 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 September 13, 1996 6 Firewall Support for Mobile IP 7 draft-montenegro-firewall-sup-00.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 author, 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 uses 43 cryptographic techniques to authenticate the parties involved in the 44 registration protocol. However, it makes no provisions for securing 45 data traffic. The mechanisms described in this document allow a 46 mobile node out on a public sector of the network to negotiate 47 access past a SKIP firewall, and construct a secure channel into its 48 home network. 50 1. Introduction 52 This document specifies what support is required at a firewall to 53 allow Mobile IP [1] hosts access into a private network from the 54 Internet. For example, a company employee could attach his/her 55 laptop to some Internet access point by: 57 a) Dialing into a PPP/SLIP account on an Internet service 58 provider's network. 60 b) Connecting into a 10Base-T or similar LAN network available 61 at, for example, an IETF terminal room, a local university, 62 or another company's premises. 64 Notice that in these examples, the mobile node's relevant interface 65 (PPP or 10Base-T) is configured with an IP address different from 66 that which it uses "normally" (i.e. at the office). Furthermore, the 67 IP address used is not necessarily a fixed assignment. It may be 68 assigned temporarily and dynamically at the beginning of the session 69 (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case). 71 The following discussion assumes a network configuration consisting 72 of a private network separated by a firewall from the general 73 Internet or public network. The systems involved are: 75 Private Network 77 A protected network separated from the Internet by hosts 78 enforcing access restrictions (firewalls). 80 Public Network 82 The Internet at large. Hosts are able to communicate with each 83 other throughout the public network without firewall-imposed 84 restrictions. 86 Mobile Node (MN) 88 Its permanent address falls within the range of the private 89 network. The user may remove the system from its home 90 network, and connects it to the Internet at another point. 91 The mechanisms outlined in this discussion render this 92 mobility transparent: the mobile node continues accessing 93 its home network and its resources exactly as if it were 94 still within it. Notice that when the mobile node leaves its 95 home network, it may migrate both within and outside of the 96 private network's boundaries. As defined by Mobile IP [1], a 97 mobile node uses a care-of address while roaming. 99 Pop-up 101 A mobile node whose care-of address is an address associated 102 to one of its own interfaces. This address may be a temporary 103 address acquired dynamically (e.g. by means of DHCP or PPP's 104 IPCP), or through manual intervention. It may also be a 105 permanent address assigned to one of the mobile node's 106 interfaces (e.g. a permanent PPP address). Since pop-ups do 107 not require a separate foreign agent, they can operate in 108 foreign nets that lack Mobile IP support. 110 Home Agent (HA) for the mobile node 112 Serves as a location registry and router as described in the 113 Mobile IP IETF draft. 115 Foreign Agent (FA) 117 Serves as a registration relayer and care of address for the 118 mobile node as described in the Mobile IP IETF draft. 120 Correspondent Host (CH) 122 A system that is exchanging data packets with the mobile 123 node. Its communication with the mobile node does not change 124 regardless of the latter's current point of attachment to the 125 network. 127 Firewall (FW) 129 The system (or collection of systems) that enforces access 130 control between the private network and the general Internet. 131 It may do so by a combination of functions such as application 132 gatewaying, packet filtering and cryptographic techniques. 134 The mechanisms described in this document allow a mobile node out on 135 a public sector of the network to negotiate access past a SKIP 136 firewall, and construct a secure channel into its home network. 137 This enables it to communicate with correspondent hosts that belong 138 to the private network, and, if bi-directional tunnels are used, 139 with external hosts that are reachable when the mobile node is at 140 home. 142 This document does not address the scenarion in which the mobile 143 node attempts to access its private network, while within another 144 private network. 146 Sections 2 and 3 provide an overview of the environment being 147 considered and the restrictions it imposes. Sections 4 examines 148 firewall technologies. Section 5 discusses the best mode of 149 operation of the participating entities from the point of view of 150 Mobile IP. Section 6 discusses possible configuration for the 151 secure channel. Finally, packet formats are the topic of of 152 sections 7 and 8. 154 2. Mobility without a Firewall 156 Suppose the mobile node is roaming throughout the general Internet, 157 but its home network is not protected by a firewall. This is 158 typically found in academic environment as opposed to corporate 159 networks. 161 This works as prescribed by Mobile IP [1]. The only proviso is that 162 the mobile node would most probably operate as a pop-up instead of 163 using a separate foreign agent's care-of address. This is because, 164 at least in the near term, it is far more likely to be able to 165 secure a temporary care-of-address than it is to find a foreign 166 agent already deployed at the site you are visiting. For example: 168 - Internet Service Provider (ISP): pre-assigns customers IP 169 addresses, or hands them out dynamically via PPP's address 170 negotiation. 172 - IETF terminal room: typically pre-assigns addresses for your use 174 - other places would probably offer DHCP services 176 3. Restrictions imposed by a Firewall 178 The firewall imposes restrictions on packets entering or leaving the 179 private network. Packets are not allowed through unless they conform 180 to a filtering specification, or unless there is a negotiation 181 involving some sort of authentication. 183 Another restriction is imposed by the separation between private 184 addresses and general Internet addresses. Strictly speaking, this is 185 not imposed by a firewall, but by the characteristics of the private 186 network. For example, if a packet destined to an internal address 187 originates in the general Internet, it will probably not be 188 delivered. It is not that the firewall drops it. Rather, the 189 Internet's routing fabric is unable to process it. This elicits an 190 ICMP host unreachable packet sent back to the originating node. 192 Because of this, the firewall must be explicitly targeted as the 193 destination node by outside packets seeking to enter the private 194 network. The routing fabric in the general Internet will only see 195 the public address of the firewall and route accordingly. Once the 196 packet arrives at the firewall, the real packet destined to a 197 private address must be recovered. 199 4. Two Firewall Options: Application relay and IP Security 201 Before delving into any details, lets examine two technologies which 202 may provide firewall support for mobile nodes: 204 - application relaying or proxying, or 205 - IP Security 207 To understand the implications, let's examine two specific schemes 208 to accomplish the above: SOCKS version 5 and SKIP. 210 4.1 SOCKS version 5 [5] 212 There is an effort within the authenticated firewall traversal WG 213 (aft) of the IETF to provide a common interface for application 214 relays. 216 The solution being proposed is a revised specification of the SOCKS 217 protocol. Version 5 has been extended to include UDP services as 218 well. The SOCKS solution requires that the mobile node -- or 219 another node on its behalf -- establish a TCP session to exchange 220 UDP traffic with the FW. It also has to use the SOCKS library to 221 encapsulate the traffic meant for the FW. The steps required by a 222 SOCKS solution are: 224 - TCP connection established to port 1080 (1.5 round trips) 226 - version identifier/method selection negotiation (1 round trip) 228 - method-dependent negotiation. For example, the 229 Username/Password Authentication [6] requires 1 round trip: 231 1. client sends a Username/Password request 232 2. FW (server) responds 234 The GSS-API negotiation [7] requires at least 3 round 235 trips: 237 1. client context establishment (at least 1 round trip) 238 2. client initial token/server reply (1 round trip) 239 3. message protection subnegotiation (at least 1 round trip) 241 - (finally) SOCKS request/reply (1 round trip) 243 This is a minimum of 4 (6 with GSS-API) round-trips before the 244 client is able to pass data through the FW using the following 245 header: 247 +----+------+------+----------+----------+----------+ 248 |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | 249 +----+------+------+----------+----------+----------+ 250 | 2 | 1 | 1 | Variable | 2 | Variable | 251 +----+------+------+----------+----------+----------+ 253 Bear in mind that the above must be done each time the mobile 254 registers a new care-of address. In addition to this inefficiency, 255 this scheme requires that we use UDP to encapsulate IP datagrams. 256 There is at least one commercial network that does this, but it is 257 not the best solution. 259 This header contains the relay information needed by all parties 260 involved to reach those not directly reachable. 262 4.2 SKIP [4] 264 Alternatively, traffic from the mobile node to the firewall could be 265 encrypted and authenticated using a session-less IP security 266 mechanism like SKIP. This obviates the need to set up a TCP session 267 just to exchange UDP traffic with the firewall. 269 A solution based on SKIP is very attractive in this scenario, as no 270 round trip times are involved before the mobile node and the 271 firewall achieve mutual trust: the firewall can start relaying 272 packets for the mobile node as soon as it receives the first one. 273 This, of course, implies that SKIP is being used with AH [10] so 274 that authentication information is contained in each packet. 275 Encryption by using ESP [9] is also assumed in this scenario, since 276 the Internet at large is considered a hostile environment. An ESP 277 transform that provides both authentication and encryption could be 278 used, in which case the AH header need not be included. 280 The firewall and the mobile node must both be previously configured 281 with the authenticated Diffie-Hellman public values for each other. 283 Strictly speaking, they could obtain them in real-time, using any of 284 the mechanisms defined by the SKIP protocol (online certificate 285 directory service or certificate discovery protocol). However, in 286 order to avoid round-trip times, it is preferable to manually 287 distribute each other's public keys to the the mobile node and the 288 SKIP firewall. This is part of the administrative process of 289 enabling a mobile node to roam in the general Internet. Home agents 290 and the firewall must also have access to each others public keys. 292 There are other proposals besides SKIP to achieve IP layer 293 security. However, they are session-oriented key management 294 solutions, and typically imply negotiations spanning several 295 round-trip times before cryptographically secure communications are 296 possible. In this respect they raise similar concerns to those 297 outlined previously in the discussion on SOCKS-based solutions. 298 Others have arrived at similar conclusions regarding the importance 299 of session-less key management for Mobile IP applications [12]. 301 Another advantage of SKIP is its support for nomadic applications. 302 Typically, two hosts communicating via a secure IP layer channel use 303 the IP source and destination addresses on incoming packets to 304 arrive at the appropriate security association. The SKIP header can 305 easily supersede this default mechanism by including the key ID the 306 recipient must use to obtain the right certificate. The access 307 control entry for a nomadic host at a SKIP firewall is a so-called 308 "nomadic" entry, which is filtered by key ID, instead of by IP 309 source address, as is the usual case. It basically translates to 310 "allow access from "any IP source address" if "keyID=". Incoming packets MUST have an AH header, so that after 312 properly authenticating them, the firewall establishes a "current 313 address" for the nomadic host. This information determines which 314 key should be used when encrypting outgoing packets [13]. 316 Notice that this supports Mobile IP, because the mobile node always 317 initiates contact, so the SKIP firewall always has a chance to learn 318 the "current address" to use when encrypting an outgoing packet. 320 However, this precludes the use of simultaneous bindings by a mobile 321 node. At the firewall, the last Registration Request sent by the 322 mobile node replaces the association between its permanent address 323 and any prior care-of address. In order to support simultaneous 324 bindings the firewall must be able to interpret Mobile IP 325 registration messages. 327 If in addition to registration messages, the firewall understands 328 the Mobile IP encapsulation process, it is possible to use Unsigned 329 Diffie-Hellman public values [14]. Doing so greatly reduces SKIP's 330 infrastructure requirements, because there is no need for a 331 Certificate Authority. Of course, for this to be possible the 332 principals' names MUST be securely communicated. 334 Section 7.2.2 discusses another advantage of making the firewall 335 understand Mobile IP packet formats. 337 In what follows we assume a SKIP-based solution. 339 5. Supporting Mobile IP: Agents and Mobile Node Configurations 341 The Mobile IP protocol specifies two ways that a mobile node can 342 register a mobility binding with its home agent, depending on which 343 address it uses as its tunnel endpoint: 345 a) an address advertised for that purpose by the foreign agent 347 b) an address belonging to one of the mobile node's interfaces 348 (i.e. pop-up operation). 350 From the firewall's point of view, the main difference between these 351 two cases hinges on which node prepares the outermost encrypting 352 encapsulation. The firewall must be able to obtain the public keys 353 of the node that creates the outermost SKIP header in an incoming 354 packet. This is only possible to guarantee in case "b", because the 355 mobile node and the firewall both belong to the same administrative 356 domain. The problem is even more apparent when the mobile node 357 attempts a registration request. Here, the foreign agent is not just 358 a relayer, it actually examines the packet sent by the mobile node, 359 and modifies its agent services accordingly. In short, assuming the 360 current specification of Mobile IP and the current lack of trust in 361 the internet at large, only case "b" is possible. Case "a" would 362 require an extension (e.g. a "relay" registration request), and 363 modifying code at the home agent, the firewall and the foreign 364 agent. 366 Assuming that the firewall offers a secure relay service (i.e. 367 decapsulation and forwarding of packets), the mobile node can reach 368 addresses internal to the private network by encapsulating the 369 packets in a SKIP header and directing them to the firewall. 371 Therefore, It is simplest to assume that the mobile node operates as 372 a pop-up. 374 6. Supporting Mobile IP: Secure Channel Configurations 376 The mobile node participates in two different types of traffic: 378 Mobile IP registration protocol and regular data. For the sake of 379 simplicity, the following discussion evaluates different secure 380 channel configurations by examining the initial registration request 381 sent by the mobile node to its home agent. 383 Assuming the mobile node operates as a pop-up, it can talk directly 384 to the firewall. The latter is able to reach the home agent in the 385 private network. Also, the firewall must be able to authenticate the 386 mobile node. 388 The following channel configurations assume the mobile node is 389 operating in pop-up mode. The region between the HA (home agent) and 390 the FW (firewall) is a private network. The region between the FW 391 and the MN (mobile node) is the outside or public network. 393 6.1 Option 1: Encryption only Outside of Private Network 395 HA FW MN 396 <=====================> SKIP (AH + ESP) 397 <-----------------------------------> Data path 399 The traffic is only encrypted between the mobile node out on the 400 general Internet, and the firewall's external interface. This is 401 minimum required. It is the most desirable configuration as the more 402 expensive encrypted channel is only used where it is necessary: on 403 the public network. 405 6.2 Option 2: End-to-End Encryption 407 Another possible configuration extends the encrypted tunnel through 408 the FW: 410 HA FW MN 411 <===================================> SKIP (AH + ESP) 412 <-----------------------------------> Data path 414 This limits the FW to perform a simple packet relay or gatewaying 415 function. Even though this could be accomplished by using the proper 416 destination NSID in the packet, in practice it is probably 417 unrealizable. The reason is that this alternative is probably not 418 very popular with computer security personnel, as the authentication 419 functions are now being carried out by the HA, whose security is 420 potentially much weaker than the FW operated by computer security 421 personnel. 423 6.3 Option 3: End-to-End Encryption, Intermediate Authentication 425 A third alternative is to allow the FW to be party to the security 426 association with the mobile node for *authentication* purposes only 427 (AH header), and then forward the encrypted packet (ESP hdr) to the 428 HA. 430 HA FW MN 431 <+++++++++++++++++++++> SKIP authentication 432 <===================================> SKIP encryption 433 <-----------------------------------> Data path 435 The SKIP specification refers to this as "Intermediate 436 Authentication with End-to-End security using SKIP" [4]: 438 "Using SKIP, intermediate authentication of end-to-end 439 protected IP traffic MAY be realized, if participating 440 principals can share their long-term private keys with the 441 intermediate node. This may not be desirable if the long-term 442 keys belong to individual users, because of privacy related 443 concerns,..." 445 Whereas Option 2 above is probably not agreeable to security and 446 system administration personnel, option 3 is unsavory to the end 447 user. 449 6.4 Option 4: Encryption Inside and Outside 450 HA FW MN 451 <============><=====================> SKIP (AH + ESP) 452 <-----------------------------------> Data path 454 Traffic is encrypted on the public as well as on the private 455 network. On the public network, encryption is dictated by a security 456 association between the mobile node and the firewall. On the 457 private network, it is dictated by a security association between 458 the home agent and the firewall. 460 6.5 Choosing a Secure Channel Configuration 462 A potential problem in both options 2 and 3 is that their end-to-end 463 channel components assume that the mobile node and the home agent 464 have reachability to each other. This is generally not the case, as 465 the Internet routing fabric may not have routes to addresses that 466 belong to private networks, and the private routing fabric may 467 ignore how to route to public addresses -- or doing so may be 468 administratively restricted. Therefore, it is necessary for packets 469 to be addressed directly to the firewall, and indirectly -- via some 470 tunneling or relaying capability -- to the real destination on the 471 other side of the firewall. 473 Options 1 and 4 are essentially equivalent. The latter may be 474 considered overkill, because it uses encryption even within the 475 private network, and this is generally not necessary. What is 476 necessary even within the private network is for the home agent to 477 add an encapsulation (not necessarily encrypted) so as to direct 478 datagrams to the mobile node via the firewall. How this 479 encapsulation is achieved is the difference between options 1 and 480 4. Option 4 uses SKIP, while option 1 uses a cleartext 481 encapsulation mechanism. This is obtainable by, for example, using 482 IP in IP encapsulation [2], or by use of a currently undefined null 483 transform in the SKIP header. 485 Options 1 and 4 are mostly interchangeable, except in pathologically 486 paranoid private networks. For example, option 1 allows a malicious 487 node operation from within the private network to launch a chosen 488 plaintext attack, by sending data through the firewall. 490 In the interest of being conservative, in what follows we assume 491 option 4 (i.e. traffic is encrypted on the general Internet, as well 492 as within the private network. 494 Since the firewall is party to the security associations governing 495 encryption on both the public and private networks, it is always 496 able to inspect the traffic being exchanged by the home agent and 497 the mobile node. If this is of any concern, the home agent and 498 mobile node could set up a bi-directional tunnel [8] and encrypt 499 it. 501 7. Mobile IP Registration Procedure with a SKIP Firewall 503 When roaming within a private network, a mobile node sends 504 registration requests directly to its home agent. On the public 505 Internet, it MUST encapsulates the original registration request in 506 a SKIP packet destined to the firewall. The mobile node MUST 507 distinguish between "inside" and "outside" addresses. This could be 508 accomplished by a set of rules defining the address ranges. 509 Nevertheless, actual installations may present serious difficulties 510 in defining exactly what is a private address and what is not. 511 Because of this, errors in judgement are to be expected. 512 Accordingly, the firewall SHOULD be configured such that it will 513 still perform its relaying duties even if they are unnecessarily 514 required by a mobile node with an inside care-of address. 516 Upon arriving at a foreign net and acquiring a care-of address, the 517 mobile node must first -- before any data transfer is possible -- 518 initiate a registration procedure. This consists of an authenticated 519 exchange by which the mobile node informs its home agent of its 520 current whereabouts (i.e. its current care-of address), and receives 521 an acknowledgement. This first step of the protocol is very 522 convenient, because the SKIP firewall can use it to dynamically 523 configure its packet filter. 525 The remainder if this section shows the packet formats used. 526 Section 7.1 discusses how a mobile node sends a Registration Request 527 to its home agent via the SKIP firewall. Section 7.2 discusses how 528 the home agent send the corresponding Registration Reply to the 529 mobile node. 531 7.1. Registration Request from the Mobile Node to the Home Agent via 532 the SKIP Firewall 534 The mobile node arrives at a foreign net, and using mechanisms 535 defined by Mobile IP, discovers it has moved away from home. It 536 acquires a local address at the foreign site, and composes a 537 registration request meant for its HA. It must decide whether this 538 packet needs to be processed by SKIP or not. 540 This is not a simple rule triggered by a given destination address. 541 It must be applied whenever the following conditions are met: 543 a) the mobile node is using a care-of address that does not 544 belong to the private network (i.e. the mobile node is 545 "outside" its private network), and 547 b) either of: 549 b1) the source address of the packet is the mobile node's 550 home address, or 552 b2) the source address of the packet is the care-of 553 address and the destination address belongs to the 554 private network 556 Since the above conditions are mobility related, it is best for the 557 Mobile IP function in the node to evaluate them, and then -- using a 558 special API -- request the appropriate security services from SKIP. 560 The SKIP module must use the firewall destination address and the 561 firewall's certificate in order to address and encrypt the packet. 562 It encrypts it using SKIP combined with the ESP [9] protocol and 563 possibly the AH [10] protocol. The SKIP header's NSID fields 564 indicate that the Master Key-ID for the source is that of the mobile 565 node's home address, even though the packet's source address 566 corresponds to the care-of address -- an address whose corresponding 567 public key is unknown to the firewall. 569 The SKIP Firewall's dynamic packet filtering uses this information 570 to establish a dynamic mapping between the care-of address and the 571 mobile node's Master Key-ID. 573 The destination NSID field is zero, prompting the firewall to 574 process the SKIP header and recover the internal packet. It then 575 delivers the original packet to another outbound interface, because 576 it is addressed to the home agent (an address within the private 577 network). Assuming secure channel configuration number 4, the 578 firewall will encrypt the packet using SKIP before forwarding to the 579 home agent. 581 PACKET FORMAT 1: 582 +---------------+----------+----+-----+--------------+--------------+ 583 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request | 584 +---------------+----------+----+-----+--------------+--------------+ 586 IP Hdr (SKIP): 587 Source mobile node's care-of address 588 Destination public (outside) address on the firewall 590 SKIP Hdr: 591 Source NSID = 1 592 Master Key-ID = IPv4 address of the mobile node 593 Destination NSID = 0 594 Master Key-ID = none 595 Inner IP Hdr: 596 Source mobile node's care-of address 597 Destination home agent's address 599 7.2. Registration Reply from the Home Agent to the Mobile Node via the 600 SKIP Firewall 602 The home agent processes the registration request, and composes a 603 registration reply. Before responding, it examines the care-of 604 address reported by the mobile node, and determines whether or not 605 it corresponds to an outside address. If so, the home agent needs 606 to send all traffic back through the firewall. The home agent can 607 accomplish this by encapsulating the original registration reply in 608 a SKIP packet destined to the firewall (i.e. we assume secure 609 channel configuration number 4). 611 7.2.1. On the Inside (Private) Network 613 The packet from the home agent to the mobile node via the SKIP 614 Firewall has the same format as shown above. The relevant fields 615 are: 617 PACKET FORMAT 2: 618 +---------------+----------+----+-----+--------------+------------+ 619 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | 620 +---------------+----------+----+-----+--------------+------------+ 622 IP Hdr (SKIP): 623 Source home agent's address 624 Destination private (inside) address on the firewall 626 SKIP Hdr: 627 Source NSID = 0 628 Master Key-ID = none 629 Destination NSID = 0 630 Master Key-ID = none 631 Inner IP Hdr: 632 Source home agent's address 633 Destination mobile node's care-of address 635 7.2.2. On the Outside (Public) Network 637 The SKIP Firewall recovers the original registration reply packet 638 and looks at the destination address: the mobile node's care-of 639 address. 641 The SKIP Firewall's dynamic packet filtering used the initial 642 registration request (Secton 7.1) to establish a dynamic mapping 643 between the care-of address and the mobile node's Master Key-ID. 644 Hence, before forwarding the registration reply, it encrypts it 645 using the mobile node's public key. 647 This dynamic binding capability and the use of tunneling mode ESP 648 obviate the need to extend the Mobile IP protocol with a "relay 649 registration request". However, it requires that the Registration 650 Reply exit the private network through the same firewall that 651 forwarded the corresponding Registration Request. 653 Instead of obtaining the mobile node's permanent address from the 654 dynamic binding, a Mobile IP aware firewall could also obtain it 655 from the Registration Reply itself. This renders the firewall 656 stateless, and lets Registration Requests and Replies traverse the 657 periphery of the private network through different firewalls. 659 PACKET FORMAT 3: 660 +---------------+----------+----+-----+--------------+------------+ 661 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply | 662 +---------------+----------+----+-----+--------------+------------+ 664 IP Hdr (SKIP): 665 Source firewall's public (outside) address 666 Destination mobile node's care-of address 668 SKIP Hdr: 669 Source NSID = 0 670 Master Key-ID = none 671 Destination NSID = 1 672 Master Key-ID = IPv4 addr of the mobile node 673 Inner IP Hdr: 674 Source home agent's address 675 Destination mobile node's care-of address 677 8. Data Transfer 679 Data transfer proceeds along lines similar to the registration 680 request outlined above. Section 8.1 discusses data traffic sent by 681 a mobile node to a correspondent host. Sections 8.2, 8.3 and 8.4 682 show three alternative packet formats for the reverse traffic from 683 the home agent to the mobile node. 685 8.1. Data Packet From the Mobile Node to a Correspondent Host 687 The mobile node composes a packet destined to a correspondent host 688 located within the private network. 690 The Mobile IP function in the mobile node examines the Inner IP 691 header, and determines that it satisfies conditions "a" and "b1" 692 from Section 7.1. The mobile node requests the proper encryption and 693 encapsulation services from SKIP. 695 Thus, the mobile node in pop-up mode sends encrypted traffic to the 696 firewall, using the following format: 698 PACKET FORMAT 4: 699 +---------------+----------+----+-----+--------------+------+ 700 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP | 701 +---------------+----------+----+-----+--------------+------+ 703 IP Hdr (SKIP): 704 Source mobile node's care-of address 705 Destination public (outside) address on the firewall 707 SKIP Hdr: 708 Source NSID = 1 709 Master Key-ID = IPv4 address of the mobile node 710 Destination NSID = 0 711 Master Key-ID = none 712 Inner IP Hdr: 713 Source mobile node's home address 714 Destination correspondent host's address 716 The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr 717 and upper-layer packet (ULP) and checks the destination address. 718 Since the packet is destined to a correspondent host in the private 719 network, the "Inner" IP datagram is delivered internally. Once the 720 SKIP firewall injects this packet into the private network, it is 721 routed independently of its source address. 723 As this last assumption is not always true, the mobile node may 724 construct a bi-directional tunnel [8] with its home agent. Doing 725 so, guarantees that the "Inner IP Hdr" is: 727 Inner IP Hdr: 728 Source mobile node's home address 729 Destination home agent address 731 When at home, communication between the the mobile node and certain 732 external correspondent hosts might need to go through 733 application-specific firewalls or proxies, different from the SKIP 734 firewall. When on the public network, the mobile node's 735 communication with these hosts, MUST use a bi-directional tunnel. 737 8.2. Data Packet Tunneled by the Home Agent to the Mobile Node 739 The home agent intercepts a packet from a correspondent host to the 740 mobile node. It encapsulates it such that the Mobile IP header's 741 source and destination addresses are the home agent and care-of 742 addresses, respectively. This would suffice for delivery within the 743 private network. Since the current care-of address of the mobile 744 node is not within the private network, this packet must be sent via 745 the firewall. The home agent can accomplish this by encapsulating 746 the datagram in a SKIP packet destined to the firewall (i.e. we 747 assume secure channel configuration number 4). 749 8.2.1 Within the Inside (Private) Network 751 From the home agent to the private (inside) address of the 752 firewall the packet format is: 754 PACKET FORMAT 5: 755 +--------+------+----+-----+--------+--------+-----+ 756 | IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP | 757 | (SKIP) | Hdr | | | IP Hdr | IP Hdr | | 758 +--------+------+----+-----+--------+--------+-----+ 760 IP Hdr (SKIP): 761 Source home agent's address 762 Destination private (inside) address on the firewall 764 SKIP Hdr: 765 Source NSID = 0 766 Master Key-ID = none 767 Destination NSID = 0 768 Master Key-ID = none 770 Mobile-IP IP Hdr: 771 Source home agent's address 772 Destination care-of address 774 Inner IP Hdr: 775 Source correspondent host's address 776 Destination mobile node's address 778 ULP: upper-layer packet 780 The SKIP firewall intercepts the packet and recovers the 781 Mobile IP encapsulated packet. Before sending out this 782 packet, the dynamic packet filter configured by the original 783 registration request above triggers encryption of this packet, 784 this time by the SKIP firewall for consumption by the mobile node. 786 The packet format above does not require the firewall to have a 787 dynamic entry. The association between the mobile node's 788 permanent address and it care-of address can be deduced from the 789 contents of the "Mobile-IP IP Hdr" and the "Inner IP Hdr". 791 The home agent MAY eliminate the Mobile IP header if it 792 discriminates between mobile nodes that are registered within the 793 private network, and those that are outside. In this case, the 794 resultant packet is: 796 PACKET FORMAT 6: 797 +---------------+----------+----+-----+--------------+-----+ 798 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP | 799 +---------------+----------+----+-----+--------------+-----+ 801 IP Hdr (SKIP): 802 Source home agent's address 803 Destination private (inside) address on the firewall 805 SKIP Hdr: 806 Source NSID = 0 807 Master Key-ID = none 808 Destination NSID = 0 809 Master Key-ID = none 811 Inner IP Hdr: 812 Source correspondent host's address 813 Destination mobile node's address 815 The SKIP firewall decrypts the packet, and recovers the original 816 datagram. Before forwarding it, it examines its ruleset. It finds a 817 dynamic rule which was added in response to the Registration Request 818 sent by the mobile node. Accordingly, the SKIP firewall encrypts the 819 packet again before forwarding to the mobile node's care-of 820 address. 822 This optimization requires that the firewall keep some state in the 823 form of the aforementioned dynamic entry for the mobile node. 825 8.2.2. On the Outside (Public) Network 827 The SKIP firewall intercepts the packet, and--assuming packet format 828 5--recovers the Mobile IP encapsulated datagram. Before sending it 829 out, the dynamic packet filter configured by the original 830 Registration Request triggers encryption of this packet, this time 831 by the SKIP firewall for consumption by the mobile node. The 832 resultant packet is: 834 PACKET FORMAT 7: 835 +--------+------+----+-----+--------+--------+-----+ 836 | IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP | 837 | (SKIP) | Hdr | | | IP Hdr | IP Hdr | | 838 +--------+------+----+-----+--------+--------+-----+ 840 IP Hdr (SKIP): 841 Source firewall's public (outside) address 842 Destination mobile node's care-of address 844 SKIP Hdr: 845 Source NSID = 0 846 Master Key-ID = none 847 Destination NSID = 1 848 Master Key-ID = IPv4 address of the mobile node 850 Mobile-IP IP Hdr: 851 Source home agent's address 852 Destination care-of address 854 Inner IP Hdr: 855 Source correspondent host's address 856 Destination mobile node's address 858 If the firewall receives a packet in format 6, the outgoing 859 datagram to the mobile node is: 861 PACKET FORMAT 8: 862 +---------------+----------+----+-----+--------------+-----+ 863 | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP | 864 +---------------+----------+----+-----+--------------+-----+ 866 IP Hdr (SKIP): 867 Source public (outside) address on the firewall 868 Destination mobile node's care-of address 870 SKIP Hdr: 871 Source NSID = 0 872 Master Key-ID = none 873 Destination NSID = 1 874 Master Key-ID = IPv4 address of the mobile node 876 Inner IP Hdr: 877 Source correspondent host's address 878 Destination mobile node's address 880 As an optimization, the firewall MAY produce packet format 8 even if 881 the packet it receives from the home agent is in format 5. This is 882 possible even if the firewall lacks state in the form of a dynamic 883 binding. 885 At the mobile node, SKIP processes the packets sent by the 886 firewall. Eventually, the inner IP header and the upper-layer 887 packet (ULP) are retrieved and passed on. 889 9. Security Considerations 891 The topic of this document is security. Nevertheless, it is 892 imperative to point out the perils involved in allowing a flow of IP 893 packets through a firewall. In essence, the mobile host itself MUST 894 also take on responsibility for securing the private network, 895 because it extends its periphery. This does not mean it stops 896 exchanging unencrypted IP packets with hosts on the public network. 897 For example, it MAY have to do so in order to satisfy billing 898 requirements imposed by the foreign site, or to renew its DHCP 899 lease. In the latter case it might filter not only on IP source 900 address, but also on protocol and port numbers. 902 Therefore, it MUST have some firewall capabilities, otherwise, any 903 malicious individual that gains access to it will have gained access 904 to the private network as well. 906 Acknowledgements 908 Ideas in this document have benefited from discussions with at 909 least the following people: Bill Danielson, Martin Patterson, Tom 910 Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash 911 Agrawal, Tsutomu Shimomura and Don Hoffman. 913 References 915 [1] C. Perkins. IP Mobility Support. Internet Draft -- work in 916 progress, May 1996. 918 [2] C. Perkins. IP Encapsulation within IP. Internet Draft -- 919 work in progress, May 1996. 921 [3] C. Perkins. Minimal Encapsulation within IP. Internet Draft 922 -- work in progress, May 1996. 924 [4] A. Aziz, T. Markson, H. Prafullchandra. Simple Key-Management 925 For Internet Protocols (SKIP). Internet Draft -- work in 926 progress, August 14, 1996. 928 [5] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and . Jones. 929 SOCKS Protocol Version 5. RFC 1928, March 1996. 931 [6] M. Leech. Username/Password Authentication for SOCKS V5. RFC 932 1929, March 1996. 934 [7] P V McMahon. GSS-API Authentication Method for SOCKS Version 935 5. Internet Draft -- work in progress, July 1995. 937 [8] G. Montenegro. Bi-directional Tunneling for Mobile IP. 938 Internet Draft -- work in progress, September 1996. 940 [9] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995 942 [10] R. Atkinson. IP Authentication Header. RFC 1826, August 943 1995. 945 [11] A. Aziz, M. Patterson. "Design and Implementation of SKIP". 946 Internet Commerce Group white paper ICG-95-004, June 28, 1995. 948 [12] Stephen Kent, message to the IETF's IPSEC mailing list, 949 Message-Id: , September 950 6, 1996. 952 [13] Tom Markson, private communication, June 12, 1996. 954 [14] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned 955 Diffie-Hellman Public Value. Internet Draft -- work in 956 progress, August 14, 1996. 958 Author's Address 960 Gabriel E. Montenegro 961 Sun Microsystems, Inc. 962 2550 Garcia Avenue 963 Mailstop UMPK 15-214 964 Mountain View, California 94043-1100 966 Tel: (415)786-6288 967 Fax: (415)786-6445 969 gabriel.montenegro@Eng.Sun.COM 971 Vipul Gupta 972 Sun Microsystems, Inc. 973 2550 Garcia Avenue 974 Mailstop UMPK 15-214 975 Mountain View, California 94043-1100 977 Tel: (415)786-3614 978 Fax: (415)786-6445 980 vipul.gupta@Eng.Sun.COM