idnits 2.17.1 draft-ietf-mobileip-ipsec-use-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 a Security Considerations section. ** 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. ** There are 77 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 119: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 120: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 134: '...roaming over the Internet SHOULD enjoy...' RFC 2119 keyword, line 161: '... A MN SHOULD be allowed to have the ...' RFC 2119 keyword, line 163: '...rding the home subnet MUST permit this...' (40 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 1997) is 9658 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) -- Missing reference section? 'TBD' on line 518 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP John K. Zao, BBN Technologies 2 Internet Draft Matt Condell, BBN Technologies 3 draft-ietf-mobileip-ipsec-use-00.txt November 1997 5 Use of IPSec in Mobile IP 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 Distribution of this memo is unlimited. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id- abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Copyright (C) The Internet Society (November 1997). All Rights 28 Reserved. 30 Abstract 32 The use of IPSec ESP protocol in the Mobile IP packet redirection 33 tunnels will protect the redirected packets against both passive and 34 active attacks launched and aid these packets to traverse the firewalls 35 surrounding both the home and the foreign subnets visited by the mobile 36 nodes. 38 This document proposes a scheme to negotiate the use of IPSec ESP on 39 selected Mobile IP tunnels and a procedure to establish these tunnels 40 with the aid of automatic key and security association management protocol 41 such as ISAKMP. 43 Table of Contents 45 1. Introduction........................................................3 46 2. Security Requirements of Mobile IP..................................4 47 2.1 Security Requirements of Mobile Nodes..............................4 48 2.1.1 Connectivity Protection between Mobile Nodes and Home Subnets....4 49 2.1.2 Connectivity Protection between Mobile Nodes and Other Subnets...5 50 2.2 Security Requirements of Visiting Subnets..........................5 51 2.2.1 Protection of Network Resources..................................6 52 2.2.2 Protection of Local Traffic......................................6 53 3. Use of IPSec on Mobile IP Redirection Tunnels.......................6 54 3.1 Operation Principles...............................................6 55 3.2 Choice of IPSec Protected Mobile IP Tunnels........................7 56 3.2.1 MN-HA Tunnels....................................................9 57 3.2.2 HA-FA Tunnels....................................................9 58 3.2.3 MN-FA Tunnels...................................................10 59 4. Changes to Mobile IP Messages......................................10 60 4.1 Extension to Mobility Agent Advertisement.........................10 61 4.2 Extension to Mobile IP Registration Request.......................11 62 4.3 Mobile IP Registration Reply......................................12 63 5. Procedure for MIP-IPSec Tunnel Establishment.......................12 64 5.1 Selection of MIP-IPSec Tunnels....................................12 65 5.2 Negotiation of Security Associations and Keys.....................13 66 5.3 Activation of MIP-IPSec Tunnels...................................13 67 6. Format of Encapsulated Packets.....................................14 68 7. References.........................................................14 69 Disclaimer............................................................15 70 Author Information....................................................15 72 1. Introduction 74 IP mobility support or Mobile IP [rfc2002] enables a mobile node to 75 change its attachment point on the Internet while maintaining its IP 76 address(es) as well as its network connectivity using these IP 77 addresses. The protocol permits mobile internetworking to be done on 78 the network layer; however, it also introduces new vulnerabilities to 79 the global internet, most notably: 81 1. the possibility for an adverse node to spoof the identity of 82 a mobile node and redirect the packets destined for the 83 mobile node to other network locations, 85 2. the risks for potentially hostile nodes (coming from 86 different network administrative domains) to launch 87 passive/active attacks against one another when they use 88 common network resources and services offered by a mobility 89 supporting subnet. 91 The first type of vulnerability can be surmounted by the strong 92 authentication mechanisms built into both basic Mobile IP [rfc2002] 93 and route optimized Mobile IP [mip-optim]. With the aid of a public 94 key infrastructure [moips], a scaleable countermeasure against the 95 spoofing attack can readily be deployed. In contrast, the second type 96 of vulnerability was left largely unattended. This Internet Draft 97 proposes a scheme to apply IP security protocol [ipsec-arch] onto the 98 IP-IP encapsulation used by Mobile IP to redirect IP datagrams to and 99 from the mobile nodes. The purpose is to provide authentication and 100 confidentiality services to Mobile IP redirection traffics in order 101 to protect them against passive and active attacks and to help them 102 pass through security gateways. 104 The proposed scheme includes 106 1. a mechanism for negotiating the use of IPSec protection on 107 selected Mobile IP redirection tunnels, 108 2. a procedure for establishing these IPSec protected tunnels 109 and 110 3. the formats of tunneled packets in either full IP-IP or 111 minimal IP-IP encapsulations. 113 In the next two sections, we will first study the security services 114 that are needed to counter the second vulnerability of mobile 115 internetworking, and the different IPSec tunnels that can be set up 116 in the context of Mobile IP. Then, we will describe the three parts 117 of the proposed scheme in separate sections. 119 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 120 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 121 document, are to be interpreted as described in RFC 2119 [rfc2119]. 123 2. Security Requirements of Mobile IP 125 The security requirements of mobile internetworking should be 126 considered from two perspectives: (1) the expectation of the mobile 127 nodes to retain their network services and protect their 128 communication when they visit the foreign subnets and (2) the 129 expectation of the foreign subnets to protect their network resources 130 and local traffic while they are visited by the mobile nodes. 132 2.1 Security Requirements of Mobile Nodes 134 Basically, a mobile node (MN) roaming over the Internet SHOULD enjoy 135 safe and persistent IP connectivity as much as this is permitted by 136 the policies of its home and visiting subnets. Persistency of IP 137 connectivity means that the connections should be handoff correctly 138 and quickly so that the MN can maintain its TCP sessions when it 139 changes its network attachment point. Safety means traffics to and 140 from the MN should enjoy similar level of security (with respect to 141 passive and active attacks) as it is on its home subnet. 143 The strong authentication of registration messages in both basic and 144 route optimized Mobile IP is a crucial step to ensure correct and 145 persistent IP connectivity for the MN. Nevertheless, this service 146 must be augmented by the other security services (listed below in 147 their priorities) as permitted or required by the security policies 148 of the home and visiting subnets. 150 Notational remarks: In the specification of security services, 151 following terms carry special meanings as described below: 153 authentication = data origin authentication combined with 154 connectionless message integrity - a typical 155 IPSec service 156 optional = security services to be employed only if it is 157 explicit required by security policy. 159 2.1.1 Connectivity Protection between Mobile Nodes and Home Subnets 161 A MN SHOULD be allowed to have the same IP connectivity with the 162 corresponding hosts (CHs) on its home subnet as it is on the home 163 subnet. Security gateways guarding the home subnet MUST permit this 164 level of connectivity once a policy consisting of some or all of the 165 following security requirements is satisfied. The MN MUST be 166 informed of any constraints to its home connectivity before or during 167 Mobile IP registration. 169 o Authentication of traffic from the mobile node to its home 170 subnet enforced by the security gateways protecting the home 171 subnet (authentication of incoming traffic) 173 o [optional] Confidentiality of traffic between the mobile node 174 and the security gateways protecting its home subnet 176 o [optional] Confidentiality of traffic between the mobile node 177 and the corresponding hosts (end-to-end fine-grain protection) 179 o [optional] Authentication of traffic between the mobile node 180 and the corresponding hosts (end-to-end fine-grain protection) 182 2.1.2 Connectivity Protection between Mobile Nodes and Other Subnets 184 The MN visiting the subnet SHOULD be allowed to communicate with a 185 selected set of corresponding hosts (CHs) that is specified by the 186 security policy of the visiting subnet. The permission of MN 187 connectivity MUST be qualified by satisfaction of some or all of the 188 following security services: 190 o [optional] Authentication of traffic from the mobile node to 191 the security gateways protecting the visiting subnet 192 (authentication of outgoing traffic) 194 Note: reverse tunneling must be used if INGRES source 195 filtering is employed by the security gateways. 197 o [optional] Confidentiality of traffic between the mobile node 198 and the corresponding hosts (end-to-end fine-grain protection) 200 o [optional] Authentication of traffic between the mobile node 201 and the corresponding hosts (end-to-end fine-grain protection) 203 The set of connectable CHs MAY be further limited by the security 204 policy of MN's home subnet. This indirect application of security 205 policy is beyond the scope of this document. 207 2.2 Security Requirements of Visiting Subnets 209 A foreign subnet visited by mobile nodes (MNs) SHOULD employ 210 necessary measures (1) to restrict the use of its network resources 211 (communication media, printers and servers) by the MNs and (2) to 212 protect the traffic flows among local nodes from possible 213 passive/active attacks launched by the MNs. 215 2.2.1 Protection of Network Resources 217 The access of the foreign subnet SHOULD be controlled when the MNs 218 register through one of its foreign agents (FAs), and the access of 219 selected resources (such as servers) MAY be further controlled by 220 applying strong authentication and rule/identity-based access control 221 to individual MN. 223 o Access control of the mobile node to the visiting subnet - if 224 possible, the FAs SHOULD verify the identity of visiting MNs 225 either directly or indirectly via their home agents (HAs) 226 before issuing a care-of address to MN and permitting a 227 successful completion of the registration process. 229 o [optional] Authentication of traffic between the mobile node 230 and the corresponding hosts on the visiting subnet (end-to-end 231 authentication) 233 2.2.2 Protection of Local Traffic 235 If the foreign subnet uses a shared medium such as Ethernet for 236 communication then a visiting MN may eavesdrop, delete, insert or 237 alter packets passing among the local hosts over the medium. Hence, 238 encryption and message integrity checks SHOULD be in place to protect 239 sensitive communication among the local hosts as well as between the 240 local hosts and other MNs. 242 o [optional] Confidentiality and data integrity of traffic 243 between local hosts on the visiting subnet 245 3. Use of IPSec on Mobile IP Redirection Tunnels 247 3.1 Operation Principles 249 This Internet Draft proposes a scheme of using IPSec ESP [ipsec-esp] 250 protocol to protect selected Mobile IP redirection tunnels. These 251 IPSec protected Mobile IP tunnels (MIP_IPSec tunnels) offer message 252 confidentiality and authentication (including data origin 253 authentication and connectionless integrity) but NOT anti-replay 254 services to the IP datagrams to and from the mobile nodes (MNs) 255 passing through the mobility agents, i.e. home agents (HAs) and 256 foreign agents (FAs). We believe that selective use of these tunnels 257 coupled with rule/identity based access control can provide the 258 security services described in Sect.2. 260 The proposed scheme made certain assumptions on the architecture and 261 implementation of this secure Mobile IP system. These assumptions are 262 stated below: 264 o In order to use the MIP-IPSec tunnels and the mobility agents 265 for the best protection of the mobile Internet, both FAs and 266 HAs SHOULD function as IPSec supporting security gateways 267 capable of performing packet encryption/decryption and packet 268 filtering based on strong authentication. 270 o On a firewall protected foreign subnet, the FAs SHOULD be the 271 firewalls closest to the mobile nodes (MNs). Other firewalls 272 on the subnet SHOULD permit the IPSec protected packets to and 273 from the FAs to pass through. Reverse tunneling must be used 274 if INGRES source filtering is employed by the firewalls. 276 o The HAs SHOULD function as the innermost firewall guarding the 277 home subnet. Similarly, other firewalls on the subnet SHOULD 278 permit the IPSec protected packets to and from the HAs to pass 279 through. 281 o The IPSec implementation is expected to be integrated with the 282 Mobile IP implementation. Such an approach allows the use of a 283 single IP-IP encapsulation to be used for both IPSec 284 protection and Mobile IP packet redirection (except when MN-HA 285 IPSec tunnels are used). The approach is also consistent with 286 the new roles of FAs and HAs as IPSec supporting security 287 gateways. Both the "bump-in-the-stack" (BITS) or the 288 "bump-in-the-stack" (BITW) approaches will introduce an extra 289 IP encapsulation. 291 3.2 Choice of IPSec Protected Mobile IP Tunnels 293 Figure 1 tabulates all the possible IPSec Mobile IP tunnels existing 294 due to different Mobile IP options: collocated car-of-addresses 295 [rfc200], reverse tunneling [mip-reverse-tunnel] and route-optimized 296 Mobile IP [mip-optim]. The rows of the table list the tunnels roughly 297 according to their importance in fulfilling the security requirement 298 mentioned in Sect.2. The columns represent different combination of 299 Mobile IP options, and the blank entries in the table imply the 300 absence of the tunnels underneath specific Mobile IP options. 301 Following notations are used in the table: 303 C,~C - denote the use and not use of collocated care-of-address. 304 R,~R - denote the use and not use of reverse tunneling. 305 T* - denotes the cases that an additional IPSec tunnel will be 306 encapsulated within the Mobile IP tunnels. 307 Te - denotes the case that requires the use of encapsulated delivery 308 from MN and FA in the implementation of Mobile IP reverse 309 tunnels. 310 (T)- denotes the cases that duplicate the security functions of other 311 tunneling cases. 312 X - denotes the cases that correspond to IPSec protection between 313 end hosts, and thus can be implemented using transport mode. 314 O - denotes the cases that exist only in route-optimized Mobile IP. 316 |------------------------------------------| 317 | | ~C,~R | C,~R | ~C,R | C,R | 318 |------------------------------------------| 319 | HA -> MN | T* | T* | T* | T* | 320 |------------------------------------------| 321 | MN -> HA | T* | T* | T* | T* | 322 |------------------------------------------| 323 | HA -> FA | T | (T) | T | (T) | 324 |------------------------------------------| 325 | FA -> HA | | | T | (T) | 326 |------------------------------------------| 327 | FA -> MN | T | | T | | 328 |------------------------------------------| 329 | MN -> FA | | | Te | | 330 |------------------------------------------| 331 | CH -> MN | X | X | X | X | 332 |------------------------------------------| 333 | MN -> CH | X | X | X | X | 334 |------------------------------------------| 335 | CH -> FA | O | O | O | O | 336 |------------------------------------------| 337 | FA -> CH | O | O | O | O | 338 |------------------------------------------| 339 | CH -> HA | | | | | 340 |------------------------------------------| 341 | HA -> CH | | | | | 342 |------------------------------------------| 343 Figure 1. Choices of IPSec Protected Mobile IP Tunnels 345 The MIP-IPSec tunnels running between MN-HA, HA-FA, FA-MN are the 346 essential ones for fulfilling the security requirements. They will be 347 examined individually in the following paragraphs. In addition, the 348 end-to-end IPSec protection between MNs and CHs can be used in 349 combination with the IPSec tunnels. Notice that Mobile IP tunnels do 350 NOT run between CHs and HAs, and the tunnels running between CHs and 351 FAs exist only in route-optimized Mobile IP. This is because 352 corresponding hosts may be completely ignorant of Mobile IP, and may 353 not know of the existence of FAs and HAs. 355 3.2.1 MN-HA Tunnels 357 The MN-HA MIP-IPSec tunnels can be used to provide data-origin 358 authentication plus connectionless integrity and data 359 confidentiality. They are most useful in providing a secure 360 communication path between a MN and its home subnet as described in 361 [ipsec-arch, case 4] as shown in the following diagram. 363 ============================== 364 | | 365 | ---|-------------------------- 366 | | | | 367 H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | 368 | Intranet) | 369 ------------------------------ 370 admin. boundary 372 The data-origin authentication and connectionless integrity can 373 counter active attack while data confidentiality can frustrate 374 eavesdropping. By using the tunnels in both directions, a MN SHOULD 375 be allowed to enjoy same connectivity as it has at home. 377 The MN-HA tunnels are, however, more expensive to establish -- since 378 they are NOT one of the Mobile IP redirection tunnels, they must be 379 established separate- ly with the use of an additional IP header. 381 3.2.2 HA-FA Tunnels 383 The MIP-IPSec tunnel going from a HA to a FA (and from a FA to a HA 384 if reverse tunnel and FA Care-of Address are used) can be implemented 385 by simply adding IPSec protection to the existing Mobile IP tunnels. 387 The tunnels can also be used to support data-origin authentication 388 plus connectionless integrity and data confidentiality. They 389 establish virtual private network (VPN) connections between the home 390 subnet of the MN and the foreign subnet currently visited by the MN 391 as shown in the following diagram. 393 ========================= 394 | | 395 -------------------|---- ---|--------------------- 396 | | | | | | 397 | H1 -- (Local -- SG1* |-- (Internet) --| SG2* -- (Local --- H2 | 398 | Intranet) | | Intranet) | 399 ------------------------ ------------------------- 400 admin. boundary admin. boundary 402 The main uses of the FA-HA tunnels are (1) to frustrate passive and 403 active attacks from the open Internet, and (2) to traverse firewalls 404 between FAs and HAs. Such a tunnel MAY allow the MN to access its home 405 subnet only if it is coupled with strong authentication of the MN by the 406 FA and system security of the FA. 408 3.2.3 MN-FA Tunnels 410 The MN-FA MIP-IPSec tunnels can be used in two ways if no link-layer 411 protection has already provided the services: 413 1. data confidentiality for MN over the foreign network and 414 2. data origin authentication of MN-FA exchange. 416 The MN-FA tunnels exist only if MN chooses to use an FA Care-of 417 Address and they must be built by re-encapsulating the IP datagrams. 418 Hence, these tunnels are ex- pensive to use and should be replaced by 419 MN-CH end-to-end IPSec protection or MN-HA IPSec tunnels whenever 420 possible. 422 4. Changes to Mobile IP Messages 424 In order for the mobile nodes (MNs) and the mobility agents (FAs and 425 HAs) to agree on the selection of MIP-IPSec tunnels, the FA and the 426 MN SHOULD use the following two extensions (added to the mobility 427 agent advertisement and the registration request) for proposing their 428 choices. Upon reception of the registration request, the HA SHOULD 429 decide weather to accept and reject the proposal based on its 430 security policy and then return its decision using the return codes 431 in the registration reply. Such a selection process is deemed 432 necessary owing to the difficulty of formulating static IPSec 433 policies to handle the migration of mobile nodes. Because FAs and HAs 434 SHOULD only serve the MNs if they complete the registration process, 435 it is necessary to devise a mechanism to generate the IPSec policies 436 for the selected tunnels and insert them into the security policy 437 database (SPD) at the end of the process. 439 4.1 Extension to Mobility Agent Advertisement 441 An FA IPSec Tunnel Extension is added to the mobility agent 442 advertisement message, which conforms to the format of an ICMP router 443 advertisement. The purpose of the extension is to carry FA's choice 444 of MIP-IPSec tunnels. The type- length-value (TLV) format of the 445 extension is shown in Figure 2. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length |F|R| reserved |F|R| reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |<- MN Tunnel ->|<- HA Tunnel ->| 455 Figure 2. FA IPSec Tunnel Extension 457 Type [TBD] 459 Length 2 bytes 461 F IPSec Protection for Forward Tunnels ( HA->FA, FA->MN ) 463 R IPSec Protection for Reverse Tunnels ( FA->HA, MN->FA ) 465 reserved IGNORED upon reception; MUST be set to ZERO during 466 transmission 468 4.2 Extension to Mobile IP Registration Request 470 An MN IPSec Tunnel Extension is added to the registration request 471 message. This extension indicates the choices of MIP-IPSec tunnels 472 made by MN based on its own policy and its knowledge of FA's choices. 473 The extension carries SIX flags, each when SET indicates the use of 474 IPSec on a possible tunnel. The extension format is shown in Figure 475 3. To simplify processing, the flags in the FA IPSec Tunnel 476 Extensions remain in the same positions. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type | Length |F|R| |F|R| |F|R| reserved | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 FA HA HA 484 |<- MN Tunnel ->|<- FA Tunnel ->| 486 Figure 3. MN IPSec Tunnel Extension 488 Type [TBD] 490 Length 2 bytes 492 F IPSec Protection for Forward Tunnels 493 ( HA->FA, FA->MN, HA->MN ) 495 R IPSec Protection for Reverse Tunnels 496 ( FA->HA, MN->FA, MN->HA ) 498 reserved IGNORED upon reception; MUST be set to ZERO 499 during transmission 501 4.3 Mobile IP Registration Reply 503 FOUR error codes are added to the registration reply for conveying 504 possible failures of the tunnel selection process. 506 Service denial by HA: 508 Values Semantics 509 ------ ---------------------------- 510 [TBD] Tunnel Selection Conflict 511 [TBD] Tunnel Selection Unsupported 513 Service denial by FA: 515 Values Semantics 516 ------ ---------------------------- 517 [TBD] Tunnel Selection Conflict 518 [TBD] Tunnel Selection Unsupported 520 5. Procedure for MIP-IPSec Tunnel Establishment 522 The process of establishing the MIP-IPSec tunnels can be divided in 523 three steps: (1) tunnel selection, (2) security association 524 negotiation and (3) tunnel activation. Among them, tunnel selection 525 happens concurrently with Mobile IP registration and tunnel 526 activation occurs also in ordinary Mobile IP tunneling. The 527 insertion of security association (SA) negotiation is a new step, and 528 it introduces a new complexity to the process: owing to the possible 529 failure of SA negotiation, a MIP-IPSec tunnel MAY need to be 530 dismantled even after a success- ful Mobile IP registration. The case 531 will be discussed in a following section. 533 5.1 Selection of MIP-IPSec Tunnels 535 Like Mobile IP registration, the tunnel selection process begins with 536 mobility agent advertisement. FAs SHOULD announce their IPSec 537 tunneling requirements in the FA IPSec tunnel extension after 538 consulting their security policies. The advertisement is usually NOT 539 authenticated due to the lack of key management prior to this 540 process. 542 After receiving the advertisement message, an MN MAY response by 543 sending an MN registration request to the FA, and MAY attach an MN 544 IPSec tunnel extension to the request. The extension MUST carry the 545 choice of MIP-IPSec tunnels made by the MN based on its own security 546 policy and FA's choice conveyed in the advertisement. The 547 registration request including the extension MUST be authenticated to 548 the HA of the MN, and MAY also be authenticated to the FA if keys 549 have been exchanged between the MN and the FA. 551 Upon receiving the registration request, FA MUST compare its own 552 choices of IPSec tunnel with the corresponding choices of the MN, and 553 return a "Tunnel Selection Conflict" error in an FA registration 554 reply to MN if a mismatch is found. Otherwise, FA SHOULD forward the 555 registration request to the HA. 557 When the HA receives the registration request, it MUST check the 558 IPSec tunnel choices against its own security policies (beside of 559 making other Mobile IP registration decisions). HA MUST return a 560 "Tunnel Selection Unsupported" error in an HA registration reply if 561 the choices are incompatible to its policies. 563 Any error code in the registration replies MUST cause the failure of 564 the registration process. A successful registration process will 565 cause appropriate entries to be inserted in the IPSec SPD in MN, FA 566 and HA as a preparation for subsequent SA negotiations. 568 5.2 Negotiation of Security Associations and Keys 570 The negotiation process is analogous to that of an ordinary IPSec 571 tunnel esta- blishment. A successful Mobile IP registration promises 572 only IP connectivity between the mobile node and the relevant 573 mobility agents, but leaves the IP traffic without any protection. SA 574 negotiations SHOULD then be conducted through these unprotected IP 575 tunnels using protocols like ISAKMP [isakmp]. A failure of the 576 negotiations SHOULD imply a failure of establishing the corresponding 577 MIP- IPSec tunnel. Thus, it MUST cause the generation of proper error 578 events and the prohibition of any secure communication via the 579 corresponding tunnel. Whether the Mobile IP tunnel should be 580 dismantled SHOULD be decided according to the Mobile IP policies 581 enforced by the end points. 583 5.3 Activation of MIP-IPSec Tunnels 585 Since the existence of Mobile IP tunnels do NOT necessarily imply the 586 existence of corresponding MIP-IPSec tunnels, the IPSec tunneling 587 services MUST only be activated after the successful negotiation of 588 necessary security associations. Before such activation, only 589 limited types of traffic, e.g. key management exchanges, are allowed 590 to use these tunnels. General traffic can only use the tunnels when 591 the required IPSec services are in place. 593 6. Format of Encapsulated Packets 595 In the cases that IPSec tunneling services are added to the existing 596 Mobile IP tunnels, both tunnels SHOULD be implemented using a common 597 IP-IP encapsulation [Sect.6.1]. In the only case of MN-HA tunneling, 598 an MN-HA IPSec tunnel MUST be embedded into outer Mobile IP (HA-FA, 599 FA-MN) tunnels. Hence, an extra IP header will be inserted along with 600 ESP header between the Mobile IP encapsulation and the original IP 601 header. 603 The IP encapsulation can be implemented using either full IP-IP 604 encapsulation [full-ipip] or minimal IP-IP encapsulation [mini-ipip]. 605 The only exception is that the extra IP header that implements the 606 MN-HA IPSec tunnel can NOT be in the form of minimal encapsulation. 608 7. References 610 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate 611 Requirement Level," RFC-2119, March 1997. 613 [rfc2002] C. Perkins (ed.) "IP Mobility Support." RFC2002, proposed 614 standard. IETF Mobile IP Working Group, Oct. 96. 616 [mip-optim]D.B. Johnson, C. Perkins. "Route Optimization in MIP." 617 , IETF Mobile IP Working 618 Group, Nov. 95. 620 [mip-tunnel-reverse]G. Montenegro. "Reverse tunneling for Mobile IP". 621 , IETF Mobile IP 622 Working Group, Mar. 97. 624 [isakmp] D. Maughan, M. Schertler, M. Schneider, J. Turner. 625 "Internet Security Association & Key Management Protocol 626 (ISAKMP)" , IPSec Working 627 Group, Feb. 97. 629 [ipsec-arch]S. Kent, R. Atkinson. "Security Architecture for the 630 Internet Protocol." , IETF 631 Network Working Group, Aug. 95. 633 [moips] J. Zao, S. Kent, J. Gahm, G. Troxel, M. Condell, P. 634 Helinek, N. Yuan, I. Castineyra. "A Public-Key Based 635 Secure Mobile IP". MobiCom97. Sep. 97. 637 Disclaimer 639 The views and specification here are those of the authors and are not 640 necessarily those of their employers. The authors and their 641 employers specifically disclaim responsibility for any problems 642 arising from correct or incorrect implementation or use of this 643 specification. 645 Author Information 647 Dr. John K. Zao 648 BBN Technologies 649 70 Fawcett Street 650 Cambridge, MA 02138 651 USA 652 E-mail: jzao@bbn.com 653 Telephone: +1 (617) 873-2438 655 Matt Condell 656 BBN Technologies 657 10 Moulton Street 658 Cambridge, MA 02138 659 USA 660 E-mail: mcondell@bbn.com 661 Telephone: +1 (617) 873-6203 663 Copyright (C) The Internet Society (November 1997). All Rights 664 Reserved. 666 This document and translations of it may be copied and furnished to 667 others, and derivative works that comment on or otherwise explain it 668 or assist in its implementation may be prepared, copied, published 669 and distributed, in whole or in part, without restriction of any 670 kind, provided that the above copyright notice and this paragraph are 671 included on all such copies and derivative works. However, this 672 document itself may not be modified in any way, such as by removing 673 the copyright notice or references to the Internet Society or other 674 Internet organizations, except as needed for the purpose of 675 developing Internet standards in which case the procedures for 676 copyrights defined in the Internet Standards process must be 677 followed, or as required to translate it into languages other than 678 English. 680 The limited permissions granted above are perpetual and will not be 681 revoked by the Internet Society or its successors or assigns. 683 This document and the information contained herein is provided on an 684 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 685 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 686 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 687 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 688 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.