idnits 2.17.1 draft-ishiyama-gateway-traversal-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-26) 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 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. ** There are 30 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'IP' on line 414 -- Looks like a reference, but probably isn't: 'Failure' on line 530 -- Looks like a reference, but probably isn't: 'Site-2' on line 462 -- Looks like a reference, but probably isn't: 'Site-1' on line 487 -- Looks like a reference, but probably isn't: 'SMN' on line 575 == Unused Reference: '6' is defined on line 1127, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1826 (ref. '3') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '4') (Obsoleted by RFC 2406) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-skip is -06, but you're referring to -07. -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Experimental draft: draft-simpson-icmp-ipsec-fail (ref. '7') == Outdated reference: A later version (-03) exists of draft-montenegro-firewall-sup-00 ** Downref: Normative reference to an Informational draft: draft-montenegro-firewall-sup (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-04 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Gateway traversal for Mobile IP Dec.17 1996 3 Internet Engineering Task Force Masahiro Ishiyama 4 INTERNET DRAFT Atsushi Inoue 5 Atsushi Shimbo 6 Toshio Okamoto 8 Toshiba R&D Center 10 Gateway Traversal for Mobile IP using IPSEC primitives 11 draft-ishiyama-gateway-traversal-00.txt 13 Status of this memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This memo describes an approach of security support for Mobile IP 34 protocol. IPSEC and Mobile IP modules are combined and implemented 35 on gateways of all networks and mobile nodes. Each component 36 performs IPSEC packet encryption/authentication, and Mobile IP 37 processing. Using Next-hop negotiation between security gateways, 38 the packet from a mobile node in the visiting network can be 39 delivered to the home network through the security gateways in an 40 authenticated way. This mechanism allows minimal overhead for 41 traversing security gateways, and minimal information to be held on 42 each mobile node. 44 1. Introduction 46 This memo describes an approach of security support for Mobile IP 47 protocol, in which how the packet sent from a mobile node in the 49 Ishiyama, et al. Expires June 22, 1997 [Page 1] 50 visiting network can be delivered to a correspondent host (such as 51 in the home network) through the security gateways is described. 52 This mechanism allows minimal overhead for traversing security 53 gateways, and it allows minimal setup on each mobile node. 55 IPSEC and Mobile IP modules are combined and implemented on gateways 56 of all networks and mobile nodes. Each component performs IPSEC 57 packet encryption/authentication, and Mobile IP processing. 59 Our model of communication in such a system assumes that: 61 - Between the stationary security gateways, the necessary 62 information for constructing security associations to each other 63 is properly maintained. 64 - Using those information on each security gateway, Next-hop 65 negotiation mechanism can be used in order to let the packet go 66 through the security gateways in an authenticated way. 67 - For mobile nodes, necessary information for setting up the 68 communication should be minimized. So, dynamic negotiation 69 procedure between mobile nodes and security gateways are proposed. 71 Section 2 of this draft explains the system configuration for 72 combining IPSEC and Mobile IP protocols. Section 3 describes our 73 model of packet traversal from mobile nodes through the security 74 gateways. In section 4, an implementation example is proposed, 75 including the applicability of IPSEC/Mobile-IP combination depending 76 on the relative location of the mobile node and the correspondent 77 host. The packet format between the system components are also 78 described. In Section 5, the future works for the current 79 implementation is itemized. 81 2. System configuration 83 Figure 1 shows the proposed system configuration. The system 84 consists of, 86 - Security Gateways (SGW), which perform IPSEC processing, and 87 packet filtering from the mobile nodes if necessary. 88 - Security Mobile Nodes (SMN), which perform IPSEC processing by 89 themselves. SMNs are mobile nodes of Mobile IP protocol, which 90 performs the mobile registration of current location. 91 - Home Agents (HA) defined in Mobile IP [1]. 93 Home Agents are placed on the subnet where SMTs are originally 94 located. In [8], the IPSEC communication between the mobile node and 95 the home network is discussed, assuming that the HA in the home 96 network can handle IPSEC packets by itself. But in this draft, we 97 don't require such IPSEC handling capability on each Home Agent. So, 99 Ishiyama, et al. Expires June 22, 1997 [Page 2] 100 only decrypted (plain IP) packet is delivered to Home Agents. The 101 current implementation is Popup mode of mobile IP, so there are no 102 foreign agents in the proposed system now. Supporting foreign agents 103 is a future work. 105 [outside] 106 SMN CH 107 [Home Network] | | [Other site 1] 108 +--------------------+ | | +--------------------+ 109 | +-----------+ | | | | CH +----------+ | 110 | | | | | | | | CH | | 111 | | HA CH SGW0 --- SGW1-------(Internet)--------SGW2---SGW3 | | 112 | | | | | | | SMN | | 113 | +-----------+ CH | | | SMN +----------+ | 114 +--------------------+ | +--------------------+ 115 +---------SGW4---------+ 116 | CH | SMN | 117 | | | 118 | +-------SGW5-------+ | 119 | | | | 120 | | CH SMN | | 121 | +------------------+ | 122 +----------------------+ 123 [Other site 2] 125 Figure 1 System Configuration 127 2.1 Operation of each system component 129 An SGW is placed on the exit of some network. SGWs can be 130 nested-placed at the exit of inside network, like SGW0, SGW3, and 131 SGW5 in Figure 1. When it receives the IP packet from the host 132 inside the network, it performs IPSEC encryption and authentication 133 on the packet and forward it to the outside. When it receives the 134 IPSEC packet destined to the SGW, it performs IPSEC decryption and 135 authentication on the received packet and forward it to the host or 136 another SGW inside the network. 138 An SMN can perform IPSEC processing by itself. It 139 encrypts/decrypts/authenticates the packet at the endpoint of IPSEC 140 tunnel (VPN). We assume that the SGW/SMN at the endpoint of VPN 141 guarantee the security by IPSEC AH/ESP mechanism. An SMN also acts 142 as a mobile node on Mobile IP protocol. It sends the registration 143 message to the Home Agent in its home network. 145 An HA works as defined in Mobile IP protocol[1]. It captures the 146 packet destined to SMN's home address, performs IP-in-IP 148 Ishiyama, et al. Expires June 22, 1997 [Page 3] 149 encapsulation on the packet, then forward it to SMN's current 150 Care-of address. As described above, in this draft, the IPSEC 151 processing capability is not required to HA. Therefore, it receives 152 packet decrypted at the SGW of home network (home-SGW, SGW0 in 153 Figure 1), and the mobile IP encapsulated packet will be encrypted 154 again at the home-SGW and forwarded to the outside. 156 In Figure 1, We call SMN's Home-domain network as "home network". We 157 may call [Other site 1] and [Other site 2] as "visitor network". 158 Also, we call SMN staying inside visitor network as "visiting SMN". 159 "SGW-protected" means that a host is the network at which an SGW is 160 placed, that is, in either "home network" or "visitor network" in 161 Figure 1. 163 2.2 Addressing rules 165 We assume the following addressing rules for the proposed system in 166 Figure 1. 168 - All SGW-protected networks are private networks. They are managed 169 with their own addressing rules. 170 - No address collision occurs between multiple SGW-protected 171 networks. That is, if an address is given, the position of the 172 host (which SGW is protecting the host) is uniquely determined. 173 - Hosts outside the organization is addresses by global addresses. 174 For the SGWs placed at the boundary to the Internet (SGW1, SGW2, 175 and SGW4 in Figure 1), global addresses are also assigned. 177 2.3 Assumption for certificate management 179 As for the certificates (encryption/authentication keys) for IPSEC, 180 we assume that each gateway and mobile node can acquire the 181 necessary certificates in some methods. The detailed configuration 182 of Certificate Authority and/or the way of delivering certificates 183 are not discussed in this draft. 185 Once the necessary certificates are acquired, SGW/SMN should keep 186 certificate of frequently communicating hosts in its certificate 187 cache, independently with mobile nodes' mobility registrations. 189 2.4 Assumption for Position information 191 When an SMN moves out of private network, It have to know necessary 192 information for constructing a VPN path toward at least one 193 Border-SGW in the system. Here Border-SGW is the SGW which is placed 194 at the border between private network and the Internet. In Figure 1, 195 SGW1, SGW2, and SGW4 are the Border-SGWs in the system. 197 Ishiyama, et al. Expires June 22, 1997 [Page 4] 198 Also each SGW and SMN have to know all the networks in the system, 199 which is exchanging security information to each other and VPN can 200 be constructed among them. For example, Assume that [Home Network], 201 [Other site 1] and [Other site 2] in Figure 1 are exchanging 202 security information to each other and the VPNs can be constructed 203 among these networks. These networks are defined to be VPN-routable. 204 SGWs/SMNs can distinguish whether a given address belongs to such 205 VPN-routable network or not. The case when some of the networks are 206 not VPN-routable is discussed in 3.4. 208 When an SMN moves around IP network and communicate with IPSEC and 209 mobile IP autonomously , (1) at least one Border-SGW information, 210 and (2) VPN-routable network information have to be registered to 211 that SMN before it moves out. 213 This VPN-routable network information is implemented, for example, 214 by maintaining data which express the association between SGW and 215 its protecting address set. As described in 2.2, all SGW-protected 216 networks are uniquely addressed. So, if an address is given, we can 217 uniquely determine one SGW which protects that address. This SGW 218 look up is also used for determining current location of SMN and CH 219 (Section 4). 221 3. Issues for Secure Mobile IP communication 223 3.1 Communication model 225 In our communication model, a VPN path is configured from a SMN to 226 its correspondent host (CH), along which multiple SGWs is placed 227 (Figure 2). 229 Each SGW is properly maintained by the system administrator of each 230 network, and the security policy for the SGW is subject to the 231 policy of the network. So, packet filtering rule for an SGW might be 232 determined by the site system administrator regarding the site's 233 policy. Each SGW knows other SGWs and its protecting hosts. Also 234 each SGW may know the mobile nodes. 236 The only assumption about SGW's filtering rule is that even though 237 once an SGW rejects a packet, if the SGW negotiates with the sender 238 of that packet and the packet with negotiation information is 239 delivered to that SGW again, it will let the packet go through. 241 Therefore, if the SMN goes into a visitor network and tries to 242 communicate with a host outside the visitor network, it have to 243 negotiate with the SGW at the exit of the network in order to let 244 the packet go through the SGW. 246 Ishiyama, et al. Expires June 22, 1997 [Page 5] 247 +---+ +----+ +----+ +----+ +------+ +----+ 248 |SMN+---->+SGW1+-->+SGW2+-->+SGW3+-- ....... --->+SGW(N)+---->+ CH | 249 +---+ +----+ +----+ +----+ +------+ +----+ 251 Figure 2 The VPN path with SGW/SMN 253 In [9], a method for authenticated firewall traversal is 254 introduced. In the method, when a packet sent from mobile node 255 reaches a firewall, the firewall returns ICMP administration message 256 to the mobile node. Then the negotiation between the mobile node and 257 the firewall which rejects the packet, such as cookie exchange, is 258 performed. After that, the packet from the mobile node can pass the 259 firewall with authentication information attached on the packet. 261 If we use this method on our model, the returning of ICMP message and 262 the negotiation for SGW will be repeated N times in order to arrive 263 at CH. Even though the negotiation with the SGWs along the path is 264 successfully completed, N independent negotiated information 265 (Authentication header/AH, for example) have to be appended to the 266 packet like, 268 +-----+-----+-... +-------+-----+-----+---------------+ 269 |AH(1)|AH(2)| |AH(N-1)|AH(N)| ESP | Inner IP data | 270 +-----+-----+-...-+-------+-----+-----+---------------+ 272 Here, AH(i) means authentication header for negotiating between SMN 273 and SGW(i). This huge authentication headers attached to the packet 274 might degrade the total system performance. 276 In general, a packet need to be checked on each stage of SGW for 277 security concern. However, if we can assume that all SGWs are 278 stationary hosts, and are properly maintained by the system 279 administrators of the networks, that is, the security information 280 for setting up VPN between each other is registered in advance, an 281 SGW can perform negotiation using the shared information with the 282 previous/next stage of SGW. This negotiation method can control the 283 packet traversal of SGWs. If the packet is allowed to go through the 284 previous stage of SGW and the negotiation between the previous stage 285 of SGW and this SGW is valid, the packet is allowed to go through 286 this SGW also. This negotiation method between two SGW along the VPN 287 path is called "Next-hop negotiation". 289 In order to perform Next-hop negotiation efficiently, SGWs can 290 maintain routing information for other components in the system. If 291 the destination address of a packet is given, we can easily look up 292 the Next-hop SGW with the registered routing information. 294 Ishiyama, et al. Expires June 22, 1997 [Page 6] 295 In Figure 2, we assume that SGW1, SGW2, ...., SGW(N) are stationary 296 nodes, and all the necessary information for VPN routing and 297 necessary certificates are correctly maintained by the system 298 administrators. Therefore, when each SGW receives a packet, it can 299 distinguish the Next-hop SGW from the destination address in the 300 packet. Here we assume that authentication with AH between two nodes 301 are used for Next-hop negotiation. 303 When the packet from a mobile node reaches SGW1, the Next-hop AH 304 (AH12) with the Next-hop SGW2 is appended to the packet and 305 forwarded to SGW2. Next at SGW2, the MAC value for AH12 is checked. 306 If it is valid, then the Next-hop AH is replaced by AH23 (for SGW2 307 and SGW3) and forwarded to SGW3. On each SGW along the VPN path, the 308 Next-hop AH will be replaced and finally, the packet will reach 309 SGW(N). 311 As long as the packet goes through stationary SGWs which is 312 correctly setup by the administrators, and if the Next-hop AH is 313 correctly appended to the packet, failure message (such as ICMP 314 administration message in [9]) from SGWs will not be returned to the 315 mobile node. Also, the packet format is always, 317 +-------+------+-----+---------------+ 318 |next-AH|end-AH| ESP | Inner IP data | 319 +-------+------+-----+---------------+ 321 and never becomes larger. 323 3.2 Handling Packets from the Mobile Nodes 325 As a mobile node (SMN) moves around on the IP network dynamically, 326 we cannot expect the SMN's location and setup the necessary 327 information in advance. Rather it might be better to limit the 328 registered information on the SMN before moving as minimal as 329 possible. 331 And in general, just after an SMN is reconnected to IP network on 332 the visitor site, the SMN cannot understand the environment around 333 it. Therefore, when an SMN moved into a visitor network and start 334 the communication, it have to follow an procedure, by which it can 335 capture necessary information in order to construct communication 336 path to the outside the visitor network (especially to the SMN's 337 home network). 339 In the model on Figure 2, consider the case the mobile node (SMN) 340 connected at the visitor network tries to communicate with CH in the 341 home network through multiple SGWs. 343 Ishiyama, et al. Expires June 22, 1997 [Page 7] 344 When an SMN is reconnected, it does not even know that there are 345 SGWs (SGW1, ..., SGW(N)) along the path toward CH. So, the only thing 346 SMN can do first is to send a ordinary IP packet to the CH, and see 347 what happens at the SGWs. In our model of packet traversal from SMN 348 to home network, we assume the following: 350 - When the packet from SMN reaches the first SGW without 351 Next-hop negotiation between SMN and the SGW, failure message 352 (such as ICMP Security Failures Message[7]) is returned to the SMN 353 - On the endpoint of VPN, if the home SGW detect that the packet is 354 from the SMN but End-End negotiation is done by another SGW, then 355 it distinguish that packet as invalid and returns failure message. 357 Here we assume that authentication (AH) between two nodes are used 358 for Next-hop/End-End negotiation. When the IP packet reaches the 359 first SGW (SGW1), it detects that the packet is from visiting SMN 360 and illegal (by checking the source address), and returns failure 361 message to the SMN. With this failure reply, the SMN negotiates the 362 key for Next-hop AH, computes/attaches Next-hop AH, and resends the 363 packet to SGW1. Here the packet is authenticated but not encrypted 364 yet. 366 When SGW1 receives this packet, it tries to construct VPN with 367 SGW(N) at the home network of SMN. That means, SGW1 becomes the end 368 of VPN, so the End-End AH is computed between SGW1 and SGW(N), and 369 the packet is encrypted. Then, SGW1 relays the packet with Next-hop 370 AH for Next-stage SGW (SGW2) attached to the packet. 372 Finally the packet reaches SGW(N). Then Next-hop AH with previous 373 stage SGW(N-1) is checked and IPSEC processing is done. Here SGW(N) 374 detects, 376 - The contents of IPSEC is from the SMN which was originally in its 377 network. 378 - But the End-End AH is negotiated with another SGW (SGW1). 380 and this conflicts with the policy and SGW(N) returns failure message 381 to the SMN. 383 When SMN receives this failure message, then it performs IPSEC 384 processing by itself. It processes End-End AH with SGW(N) by itself. 385 And using the Next-hop AH key for SGW1 (previously acquired). SMN 386 puts Next-hop AH and sends to SGW1 again. In this case, SGW1 works 387 just the same as other SGWs along the VPN, that is, checks/replaces 388 the Next-hop AH and forward the packet to SGW2. This packet will 389 successfully traverse the SGWs and reach SGW(N) at the VPN endpoint. 390 These step is depicted as follows. The notation is the same as that 391 of Section 4. 393 Ishiyama, et al. Expires June 22, 1997 [Page 8] 394 Step1: Failed at SGW1 because of lack of Next-hop AH 396 [IP] 397 SMN SGW1 SGW(N) CH 398 --------------->X 399 <--------------- 400 [Failure] 402 Step2: Failed at SGW(N) because of inconsistency between packet contents 403 and End-End AH 405 [IP+NextAH] [IP+endAH] 406 SMN SGW1 SGW(N) CH 407 -NNNNNNNNNNNNNNN-EEEEEEEEEEEEEEEEEEEEEEEEE->X 409 <----------------EEEEEEEEEEEEEEEEEEEEEEEEE--- 410 [Failure] 412 Step3: Succeed in constructing VPN through SGW(N) 414 [IP+AH] [IP+AH] [IP] 415 SMN SGW1 SGW(N) CH 416 -NNNNNNNNNNNNNNN NNNNNN NNNNNN NNNNNNNN 417 -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE---------> 418 420 3.3 Handling packets from SMNs outside the organization 422 The scheme in the previous section describes the cases when SMN 423 moves into SGW-protected networks (organizations), and communicate 424 with other networks (such as home network) through the SGW placed on 425 the exit of that network. 427 As SMNs can perform IPSEC and Mobile IP processings by itself, it 428 can also move to the IP connection point on the Internet outside the 429 specific organization (where not protected by SGWs). In such a case, 430 the necessary information for constructing a VPN path toward at lease 431 one SGW placed on the boundary of VPN reachable organization 432 (Border-SGW) have to be installed on the SMN before it moves 433 outside. This is because we assume that once the packet reaches an 434 SGW on the VPN-routable network, the SGW knows all the VPN routing 435 information to deliver the packet toward the CH in the SGW-protected 436 network. So, when the Border-SGW receives the IPSEC packet from 437 outside SMN, it decrypts the packet and checks the destination CH 438 address. And the Border-SGW reencrypts the packet with the 439 correspondent-SGW (which protects CH). The packet is then delivered 441 Ishiyama, et al. Expires June 22, 1997 [Page 9] 442 through new VPN from Border-SGW to correspondent-SGW. 444 In some cases, there will be redundant IPSEC route from SMN to CH 445 via the Border-SGW, but it can be optimized with the negotiation 446 with SMN, Border-SGW and correspondent-SGW. 448 For example, in Figure 3, the SMN is outside of the organization, 449 and assume that CH is in Site-1. Both Site-1 and Site-2 are 450 SGW-protected network and VPN-routable. And assume that SMN only 451 knows the Border-SGW2. In such a case, if SMN want to communicate 452 with CH, SMN have to construct VPN2 toward SGW2 first. Once the VPN2 453 is established, SGW2 can route the packet toward SGW1-protected CH with 454 IPSEC between SGW2 and SGW1. If outside SMN knows the Border-SGW of 455 CH's network (SGW1), or route optimization is done to eliminate the 456 redundant routing via SGW2, SMN can communicate directly with CH 457 through SGW1 as [optimized] in Figure 3. In section 4.5.7, the 458 protocol example of such a case is explained. 460 [optimized] 461 ++<========SMN....... 462 [Site-2] // <1> : [Site-1] 463 +----------------+ // : +----------------+ 464 | |// :..> | | 465 | SGW2====>====>====>====>====>SGW1 CH | 466 | | <2> | | 467 +----------------+ +----------------+ 469 Figure 3 SMN outside the organization 471 3.4 SMN talking from a network lacking Next-hop information 473 The discussion in the previous sections assume that all 474 SGW-protected networks are VPN-routable, that is, any pair of SGWs 475 are exchanging information for constructing VPN. But in some case, 476 SMN might move to the network, where VPN is not constructed to other 477 network because of its site policy. This situation occurs when an 478 SMN moves into a network, which is not familiar with the SMN's home 479 network. 481 Figure 4 shows such an example. Here the policy of Site-1 is that 482 SGW1 does not exchange security information for constructing VPN 483 with other SGWs. When SMN moves into Site-1, it can understand 484 that it is not in the VPN-routable network using the its position 485 information described in 2.4. 487 [Site-1] [VPN Network] 488 +-------------+ +------------------------+ 489 | | | +-----------+ | 490 | | | | | | 491 | SMN---->SGW1------->(Internet)-------->SGW2--->SGW1--->CH | | 492 | | | | | | 493 | | | +-----------+ | 494 +-------------+ +------------------------+ 496 Figure 4 SMN in VPN unreachable network 498 SMN in Site-1 first tries to construct VPN to its Border-SGW (SGW2 499 in Figure 4). This is just the same as discussed in 3.3. When the 500 IPSEC packet (toward SGW2) reaches SGW1, the failure message is 501 returned and the negotiation between SMN and SGW1 is performed. 502 Then SMN sends the packet with Next-hop AH again, and the packet 503 goes through SGW1 and reaches SGW2. 505 In some cases, after entering to the VPN network protected by SGW2, 506 the packet will reach SGW3 inside the VPN network and is rejected 507 there. Then SGW3 returns failure message to SMN. At this time, SMN 508 recognizes that the VPN endpoint is not SGW2, but SGW3. Then SMN 509 processes the packet for VPN endpoint SGW3, with Next-hop AH for 510 SGW2 and SGW1 appended. This packet goes through SGW1 and SGW2, and 511 reaches SGW3 successfully. The packet format delivered from SMN to 512 CH is as follows: 514 Step1: Failed at SGW1 because of lack of Next-hop AH 516 SMN SGW1 SGW2 SGW1 CH 517 -EEEEE->X (--EEEEEEEEEEEEEEEEE--->) (End/End for SMN/SGW2) 519 <-------- 520 [Failure] 522 Step2: Reached to SGW2, but failed at SGW3 524 SMN SGW1 SGW2 SGW3 CH 525 NNNNNNNN 526 -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE------------->X 528 NNNNNNNNNNNNN 529 <--------EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE- 530 [Failure] 532 Step3: Succeed in constructing VPN through CH 534 SMN SGW1 SGW2 SGW3 CH 535 NNNNNNNN 536 NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 537 -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE-------------> 539 The sequence above shows that, if SMN moves into VPN-unroutable 540 network, the step-by-step negotiation like [9] is necessary for 541 securely delivering the packet from the SMN. 543 3.5 Communication with CH outside the organization 545 If the correspondent host (CH) of SMN is not in SGW-protected 546 network, SMN cannot communicate with IPSEC. Therefore, SMN 547 communicates with the CH either of the following way, depending on 548 the CH's attribute. 550 - If it is guaranteed that CH is reachable from SMN's home network, 551 SMN can use Mobile IP, but without IPSEC, though this is not 552 recommended for security reason. 553 - If the reachability of CH from SMN's home network is not 554 guaranteed, SMN uses its Care-of address and directly communicate 555 with CH by usual IP, though this is not recommended for security 556 reason. If SMN is in the SGW-protected network the Care-of address 557 is translated to a global address at the SGW of that network. 559 Or if SMN can use a proxy in the home network, it works as follows. 561 3.5.1 Communication through the proxy at home network 563 On many sites, the Internet access is controlled through proxies. 564 When the SMN communicate through a proxy in the home network, it 565 constructs VPN tunnel with home-SGW first. Through this tunnel, the 566 SMN communicate with the proxy securely by IPSEC. Then at the proxy, 567 the necessary processing (such as address translation) is done, then 568 the packet goes out through VPN between SGWs. 570 For the packet on the reverse direction, it is delivered to the 571 proxy at home network through VPN between SGWs. Then from the proxy 572 to SMN outside, the packet goes on mobile IP routing, via Home Agent 573 (Figure 5). 575 [SMN] 576 (home)| ^^ 577 | (8) || (1)VPN btwn SMN/Proxy 578 | ++=====++ 579 (7)IP-in-IP | || (3) toward 580 ------> | VV (2) VPN btwn Proxy/SGW1 CH 581 [HA]<------[SGW1/Proxy]=========================>[SGW2]------->[CH] 582 (6) Mobile | <========================= <------- 583 IP | (5) VPN btwn SGW1/Proxy (4) reply 584 | from CH 586 Figure 5 Communication through the proxy in the home network 588 3.6 Implementation issues 590 Next-hop negotiation is typically implemented by authentication 591 between two security nodes (Next-hop authentication). The 592 authentication is done just the same way as usual IPSEC processing. 593 That is, in order to let the packet pass through the next stage of 594 SGW, each SGW put Next-hop authentication header for the two SGWs 595 ahead of the packet. The next stage of SGW checks the Next-hop AH 596 for authenticating the sending SGW, and if the MAC value is valid, 597 then it is allowed to go through. As current implementation of 598 SGW/SMN uses SKIP [5] for key management protocol, typical packet 599 format with Next-hop AH is as follows: 601 +-----+-------+----+-----+-------+----+-----+---------------+ 602 | IP1 | SKIP1 | AH | IP2 | SKIP2 | AH | ESP | Inner IP data | 603 +-----+-------+----+-----+-------+----+-----+---------------+ 604 <----------> <----------------> 605 Next-hop End-End 606 authentication authentication/encryption 608 Here Next-hop AH is used only for negotiated packet traversal on 609 SGWs. So, the point is two SGWs (or SGW and SMN) share common 610 information (Next-hop-AH keys) on the authentication processing. 611 Data integrity checking is not the purpose of Next-hop 612 authentication. That means, the MAC computation can be omitted, for 613 example, only partial data, such as IP/SKIP/AH/ESP header portion 614 can be used for MAC computation in order to reduce the overhead. 616 This format is one typical example. In some cases, depending on the 617 security policy of each site, another form of Next-hop negotiation 618 can be introduced. For example, if the site policy does not allow 619 encrypted packets which cannot be decrypted on any host in the 620 network, Next-hop encryption can be used instead of End-End 621 encryption. 623 4. Implementation Example 625 In this section, we will summarize the current status of our 626 implementation, including the packet format for mobile IP 627 registration and data transmission. 629 4.1 Abbreviations and Notation of Figures 631 HA: Home Agent 632 CH: Correspondent Host 633 SGW: Security Gateway 634 SMN: Security Mobile Node 635 AH: Authentication Header (Defined in [3]) 636 ESP: Encapsulating Security Payload (Defined in [4]) 637 SKIP: Simple Key management for Internet protocol proposed in [5]. 638 Also means SKIP header in the packet format. 639 NSID: Name Space Identifier (specified in [5]) 640 MKID: Master Key Identifier (specified in [5]) 642 The notation in packet transmission figures means the following: 644 @: Relaying Mobile IP packets by HA 645 MMMMMMMM:Tunneling with IP-in-IP [2] 646 EEEEEEEE:Tunneling with SKIP/AH/ESP (End/End IPSEC) 647 NNNNNNNN:Tunneling with SKIP/AH (Next-hop IPSEC) 649 When encapsulation is done, lower protocol is encapsulated by upper 650 ones, for example, 652 MN CH 653 EEEEEEEEEEEEEEEEEEEEEEEEEE 654 --MMMMMMMMMMMMMMMMMMMMMMMMMM--> 656 means that IP-datagram from MN to CH is encapsulated with Mobile IP 657 protocol (IP-in-IP) and then the result datagram is encapsulated by 658 End/End IPSEC. 660 4.2 Classifying the Mobile IP operation 662 First, the operation is classified whether SMN/CH is SGW-protected 663 or outside. Here CH is a stationary host. Communication mode 664 between SMN and CH is classified as the table below. The position of 665 SMN/CH can be determined by watching home agent advertisement 666 message and looking up host position information described in 2.4. 668 CH position | SGW-protected | outside 669 SMN position | | 670 ----------------+--------------------+----------------------------- 671 SGW-protected |<1>VPN through SGW |<3>Usual (mobile) IP 672 | See 4.5 | See 3.5 673 ----------------+--------------------+----------------------------- 674 outside |<2>VPN through SMN |<4>Usual (mobile) IP 675 | See 4.5 | See 3.5 677 For the case that CH is outside (<3> and <4>), SMN talks with CH as 678 described in 3.5. That is, if CH's reachability from the SMN's home 679 network is not guaranteed, SMN have to talk directly with CH using 680 its Care-of address and usual IP (though it is not recommended). If 681 CH's reachability from SMN's home network is guaranteed, SMN can use 682 Mobile IP without IPSEC. For case <3>, if SMN is using private 683 managed address, it might be translated at the SGW, or if SMN uses 684 proxy in the home network, SMN first constructs VPN to the home 685 network, then the proxy delivers the packet to/from CH, as described 686 in 3.5.1. 688 [outside] 689 SMN CH 690 [Home Network] | | [Other site 1] 691 +----------------+ | | +----------------+ 692 | | +--------+----+-+ | CH1 | 693 | SMN CH0 | | | | | 694 | SGW0----+ Internet +----SGW1 | 695 | HA | | | | SMN | 696 | | +---+-----------+ | | 697 +----------------+ | +----------------+ 698 +-----SGW2-----+ 699 | | 700 | | 701 | CH2 SMN | 702 +--------------+ 703 [Other site 2] 705 Figure 6 System Configuration for the current implementation 707 If we assume the system configuration like Figure 6, VPN through 708 SGW/SMN (case of <1> and <2>) is classified depending on the 709 relative position of SMN/CH/HA as follows: 711 CH's position| SMN's | other site| 712 SMN's position | Home | 1 | 713 -------------------+---------+------------+ 714 Home Network | (1) | (2) | 715 -------------------+---------+------------+ 716 Other 1(CH's Home) | (3)* | (4)* | 717 -------------------+ +------------+ 718 Other 2 | | (5)* | 719 -------------------+---------+------------+ 720 Outside | (6)* | (7)* | 721 -------------------+---------+------------+ 722 * means SMN's IPSEC module is used for VPN 724 The protocols for each case will be examined in 4.5. 726 4.3 SKIP NSID/MKID Consideration 728 Current implementation uses SKIP as its key management protocol. In 729 section 4.5, the packet format including SKIP header is described. 730 For the NSID/MKID for SMNs, NSID value 1 (IPv4 address) is assigned, 731 and MKID is set as SMN's home address. This NSID/MKID specification 732 is introduced in [8], and the MKID is used for looking up the SMN's 733 security association. The SMN's home address is used because even 734 after SMN has moved, the same entity can be referenced. 736 4.4 Mobile IP Registration 738 The registration of the Care-of address for SMN is done as Mobile IP 739 registration protocol[1]. With the registration, HA can maintain the 740 mapping table between the SMNs and corresponding care-of addresses. 741 In accordance with the security policy for the visitor site, 742 visiting SMN's outbound packet have to be checked by SGW of visitor 743 site with Next-hop AH. 745 [Protocol Image] 747 SMN SGW1 (Network) SGW0 HA 748 <1> -EEEEEEEEE - - -> registration request 749 <2> <--------- Failure message 751 NNNNNNN NNNNNNNNNNNNNNNNNNN 752 --EEEEEEEEEEEEEEEEEEEEEEEEEEEE-------> registration request 753 <3> <4> 755 NNNNNNNNNNNNNNNNNNN 756 <-EEEEEEEEEEEEEEEEEEEEEEEEEEEE-------- registration reply 757 <5> 759 If the registration request from SMN cannot go through SGW1 at the 760 Visitor network, the SGW traversal described in 2.3 is used. After 761 SGW1 returns Failure message (such as ICMP Security Failures 762 Message[7]), SMN resend the registration request with Next-hop AH 763 for SGW1 ahead of the packet. The packet format is as follows: 765 [Packet Format] 766 <1> (The first registration request from SMN) 767 IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr) 768 SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst = NSID(0) 769 EndAH+ESP 770 Inner IP Hdr:(Src=SMN c/o addr, Dst = HA addr) 772 <2> (Failure message from SGW1) 773 IP Hdr:(Src=SGW1 addr, Dst=SMN c/o addr) 775 <3> (The second registration request from SMN) 776 IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr) 777 SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 778 NextAH:(SMN/SGW1) 779 IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) 780 SKIP Hdr2:(Src=NSID(1)/MKID(SMN addr), Dst=NSID(0)) 781 EndAH+ESP:(SMN/SGW0) 782 Inner IP Hdr:(Src=SMN c/o addr, Dst=HA addr) 784 <4> (Request Packet from SGW1 to SGW0) 785 IP Hdr1:(Src=SGW1 addr, Dst=SGW0 addr) 786 SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) 787 NextAH:(SGW1/SGW0) 788 IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) 789 SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 790 EndAH+ESP(SMN/SGW0) 791 Inner IP Hdr:(Src=SMN c/o addr, Dst = HA addr) 793 <5> (Reply Packet from SGW0 to SGW1) 794 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) 795 SKIP Hdr1:(Src=NSID(0), Dst = NSID(0)) 796 NextAH(SGW0/SGW1) 797 IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) 798 SKIP Hdr2:(Src=NSID(0), Dst = NSID(1)/MKID(SMN home addr)) 799 EndAH+ESP(SGW0/SMT) 800 Inner IP Hdr:(Src=HA addr, Dst=SMN c/o addr) 802 4.5 Data communication 804 Also for data communication, we assume that the Next-hop AH check is 805 necessary for the outbound packet from visiting SMN. 807 4.5.1 Both SMN/CH are in Home Network 808 [Protocol image] 810 SMN CH0 811 --------> (Usual IP communication) 812 <-------- 814 4.5.2 SMN is in Home Network, CH is in Other site (Site 1) 815 [Protocol image] 817 SMN SGW0 SGW1 CH1 818 <1> --------EEEEEEEEEEEEEEEEEEEEEEEE-------> (Usual VPN between SGWs) 819 <2> <-------EEEEEEEEEEEEEEEEEEEEEEEE-------- 821 [Packet Format] 822 <1> Packet from SGW0 to SGW1 823 IP Hdr:(Src=SGW0 addr, Dst=SGW1 addr) 824 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 825 EndAH+ESP(SGW0/SGW1) 826 Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) 828 <2> Packet from SGW1 to SGW0 829 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) 830 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 831 EndAH+ESP(SGW1/SGW0) 832 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 834 4.5.3 SMN is in Other site (Site 1), CH is in Home Network 835 [Protocol image] 837 SMN SGW1 (Network) SGW0 HA CH0 838 <1> <2> 839 NNNNNN NNNNNNNNNNNNNNNNNNNNNNN 840 -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE-------------> 841 <3> 842 NNNNNNNNNNNNNNNNNNNNNNN 843 EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 844 <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-@----- 846 [Packet Format] 847 <1> Packet from SMN to SGW1 848 IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr) 849 SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 850 NextAH(SMN/SGW1) 851 IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) 852 SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr),Dst=NSID(0)) 853 EndAH+ESP(SMN/SGW0) 854 Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr) 856 <2> Packet from SGW1 to SGW0 857 IP Hdr1:(Src=SGW1 addr, Dst=SGW0 addr) 858 SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) 859 NextAH(SGW1/SGW0) 860 IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) 861 SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 862 EndAH+ESP(SMN/SGW0) 863 Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr) 865 <3> Packet from SGW0 to SGW1 866 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) 867 SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) 868 NextAH(SGW0/SGW1) 869 IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) 870 SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) 871 IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) 872 Inner IP Hdr:(Src=CH0 addr, Dst=SMN home addr) 874 4.5.4 Both SMN/CH are in the same Other site (Site 1) 875 [Protocol image] 877 SMN CH1 SGW1 (Network) SGW0 HA 878 -------> <1> 879 -------EEEEEEEEEEEEEEEEEE------->@ 880 <2> | 881 NNNNNNNNNNNNNNNNNN | 882 EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V 883 <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ 884 SMN CH1 SGW1 (Network) SGW0 HA 886 [Packet Format] 887 <1> Packet from SGW1 to SGW0 888 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) 889 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 890 EndAH+ESP:(SGW1/SGW0) 891 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 893 <2> Packet from SGW0 to SGW1 894 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) 895 SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) 896 NextAH:(SGW0/SGW1) 897 IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) 898 SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) 899 EndAH+ESP:(SGW0/SMN) 900 IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) 901 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 903 4.5.5 SMN is in Other site (Site 1), CH is another Other site (Site 2) 904 [Protocol image] 905 SMN SGW1 (Network) SGW2 CH2 (Network) SGW0 HA 906 <1> <2> 907 NNNNN NNNNNNNNNNNNNNN 908 -EEEEEEEEEEEEEEEEEEEEEE------> 909 +<----- 910 | <3> 911 +-EEEEEEEEEEEEEEEEEEEEEE------>@ 912 <4> | 913 NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN | 914 EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V 915 <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ 916 SMN SGW1 (Network) SGW2 CH2 (Network) SGW0 HA 918 [Packet Format] 919 <1> Packet from SMN to SGW1 920 IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr) 921 SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 922 NextAH:(SMN/SGW1) 923 IP Hdr2:(Src=SMN c/o addr, Dst=SGW2 addr) 924 SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 925 EndAH+ESP:(SMN/SGW2) 926 Inner IP Hdr:(Src=SMN home addr, Dst=CH2 addr) 928 <2> Packet from SGW1 to SGW2 929 IP Hdr1:(Src=SGW1 addr, Dst=SGW2 addr) 930 SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) 931 NextAH:(SGW1/SGW2) 932 IP Hdr2:(Src=SMN c/o addr, Dst=SGW2 addr) 933 SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 934 EndAH+ESP:(SMN/SGW2) 935 Inner IP Hdr:(Src=SMN home addr, Dst=CH2 addr) 937 <3> Packet from SGW2 to SGW0 938 IP Hdr:(Src=SGW2 addr, Dst=SGW0 addr) 939 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 940 EndAH+ESP:(SGW2/SGW0) 941 Inner IP Hdr:(Src=CH2 addr, Dst=SMN home addr) 942 <4> Packet from SGW0 to SGW1 943 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) 944 SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) 945 NextAH:(SGW0/SGW1) 946 IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) 947 SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) 948 EndAH+ESP:(SGW0/SMN) 949 IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) 950 Inner IP Hdr:(Src=CH2 addr, Dst=SMN home addr) 952 4.5.6 SMN is outside, CH is in Home network 953 [Protocol image] 955 SMN (Network) SGW0 HA CH0 956 <1> -EEEEEEEEEEEEEEEEEEEEEEEEEEEEE--------------> 958 <2> EEEEEEEEEEEEEEEEEEEEEEEEEEEEE 959 <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM--@<----- 961 [Packet Format] 962 <1> Packet from SMN to SGW0 963 IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr) 964 SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 965 EndAH+ESP:(SMN/SGW0) 966 Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr) 968 <2> Packet from SGW0 to SMN 969 IP Hdr:(Src=SGW0 addr, Dst=SMN c/o addr) 970 SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) 971 EndAH+ESP:(SGW0/SMN) 972 IP Hdr2 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) 973 Inner IP Hdr:(Src=CH0 addr, Dst=SMN home addr) 975 4.5.7 SMN is outside, CH is in Other site (Site 1) 976 If outside SMN only knows Border-SGW of its home network (SGW0), the 977 data transmission is done as follows. 979 [Protocol image] 980 SMN (Network) SGW1 CH1 (Network) SGW0 HA 981 <1> 982 -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE--> 983 <2> | 984 <-EEEEEEEEEEEEEEEEEEE--+ 985 | 986 +-------> 987 +<------ 988 | <3> 989 +-EEEEEEEEEEEEEEEEEEEEEE------->@ 990 <4> | 991 EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V 992 <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ 993 SMN (Network) SGW1 CH1 (Network) SGW0 HA 995 [Packet Format] 996 <1> Packet from SMN to SGW0 997 IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr) 998 SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 999 EndAH+ESP:(SMN/SGW0) 1000 Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) 1002 <2> Packet from SGW0 to SGW1 1003 IP Hdr:(Src=SGW0 addr, Dst=SGW1 addr) 1004 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 1005 EndAH+ESP:(SGW0/SGW1) 1006 Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) 1008 <3> Packet from SGW1 to SGW0 1009 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) 1010 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 1011 EndAH+ESP:(SGW1/SGW0) 1012 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 1014 <4> Packet from SGW0 to SMN 1015 IP Hdr1:(Src=SGW0 addr, Dst=SMN c/o addr) 1016 SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) 1017 EndAH+ESP(SGW0/SMN) 1018 IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) 1019 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 1021 If outside SMN knows the Border-SGW of CH1's network, or route 1022 optimization is done to eliminate the redundant routing via SGW0, 1023 the data transmission is done as follows. 1025 [Protocol image] 1026 SMN (Network) SGW1 CH1 (Network) SGW0 HA 1027 <1> 1028 -EEEEEEEEEEEEEEE-------> 1030 +<------ <2> 1031 +-EEEEEEEEEEEEEEEEEEEEEE------->@ 1032 <3> | 1033 EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V 1034 <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ 1035 SMN (Network) SGW1 CH1 (Network) SGW0 HA 1037 [Packet Format] 1038 <1> Packet from SMN to SGW1 1039 IP Hdr:(Src=SMN c/o addr, Dst=SGW1 addr) 1040 SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) 1041 EndAH+ESP:(SMN/SGW1) 1042 Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) 1044 <2> Packet from SGW1 to SGW0 1045 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) 1046 SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) 1047 EndAH+ESP:(SGW1/SGW0) 1048 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 1050 <3> Packet from SGW0 to SMN 1051 IP Hdr1:(Src=SGW0 addr, Dst=SMN c/o addr) 1052 SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) 1053 EndAH+ESP(SGW0/SMN) 1054 IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) 1055 Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 1057 5. Future works 1059 5.1 Route Optimization consideration 1061 [10] specifies the route optimization for Mobile IP, assuming that 1062 the mobile nodes, correspondent hosts and the mobility agents keeps 1063 the binding caches, and based on the information kept in the binding 1064 caches, the optimized route is determined. However, this method 1065 forces the ordinary corresponding hosts of the special support for 1066 the Mobile IP, we don't use this. 1068 Instead, we are planning the route optimization, in which the 1069 necessary information is held/exchanged only on each SGW and SMN. 1070 The purpose of this route optimization is not only avoiding 1071 redundant routing caused by mobile IP but also avoiding redundant 1072 decryption/encryption on the Border-SGW, described in 3.3. 1073 In the case of 3.3, if SMN accomplishes VPN towards the CH via one 1074 of the Border-SGW. Once it is confirmed that the CH is directly 1075 routable from the SMT, the route can be optimized. With this 1076 optimization, redundant IPSEC processing (decryption/re-encryption) 1077 at the Border-SGW will be skipped and the overhead of data 1078 transmission will be reduced. 1080 The implementation and evaluation of this route optimization is a 1081 future work. 1083 5.2 FA mode consideration 1085 When there are foreign agents in the system, the packet is processed 1086 in the home network, (1) first IP-in-IP encapsulation at HA, (2) 1087 then IPSEC encapsulation at home-SGW. But when the packet is 1088 delivered to the visitor network, the decrypted packet have to be 1089 passed to FA first, and it conflicts the processing order in the 1090 home network. The possible solutions are: 1092 - home SGW remove the outer IP header (destined to SMN's Care-of 1093 address put by HA), process the packet with IPSEC, and put the 1094 removed IP header again outer of IPSEC processed packet. 1095 - home SGW caches mobility information and acts as proxy HA, and it 1096 encapsulates the packet in IPSEC first and Mobile IP next order. 1097 - Of course if HA/FA processes IPSEC by themselves (like proposed in 1099 [8]), there are no such issues of processing order. 1101 6. Security Considerations 1103 This entire document addresses security concerns. The security of 1104 the proposal in this draft completely depends upon IPSEC standard. 1105 Also for treating visiting mobile node properly, the security policy 1106 of each organization have to be configured and maintained properly. 1107 When a mobile node goes outside the organization and communicate to 1108 the Internet directly, proper mechanism for protecting the mobile 1109 node itself, such as packet filtering, is of course need to be 1110 supported. 1112 Acknowledgements 1114 Ideas in this document have benefited from discussions with Mark 1115 Lomas, Tom Markson, Rich Skrenta, Vipul Gupta, and Gabriel 1116 Montenegro. 1118 References 1119 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 1120 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1996. 1121 [3] R. Atkinson. IP Authentication Header. RFC 1826, August 1122 1995. 1123 [4] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995 1124 [5] A. Aziz, T. Markson, H. Prafullchandra. Simple Key-Management 1125 For Internet Protocols (SKIP), 1126 (I-D draft-ietf-ipsec-skip-07.txt), August 14, 1996 1127 [6] A. Aziz, T. Markson, H. Prafullchandra, R. Skrenta, G. 1128 Caronni. Certificate Discovery Protocol, 1129 (I-D draft-ietf-ipsec-cdp-01.txt), June 6, 1996 1130 [7] P. Karn, W.A. Simpson. ICMP Security Failures Messages. (I-D 1131 draft-simpson-icmp-ipsec-fail-02.txt), April 1996 1132 [8] G. Montenegro, V. Gupta. Firewall Support for Mobile IP, 1133 (I-D draft-montenegro-firewall-sup-00.txt), September 13, 1996 1134 [9] M.C. Richardson. Authenticated Firewall Traversal with IPsec, 1135 (I-D draft-richardson-ipsec-aft-00.txt), April 1996 1136 [10] D.B. Johnson, C. Perkins. Route Optimization in Mobile IP, 1137 (I-D draft-ietf-mobileip-optim-04.txt), February 1996 1139 Author's Address 1141 Masahiro Ishiyama 1142 Toshiba Corporation, R&D Center 1143 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1144 Japan 1145 Phone : +81-44-549-2238 1146 Email : masahiro@isl.rdc.toshiba.co.jp 1148 Atsushi Inoue 1149 Toshiba Corporation, R&D Center 1150 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1151 Japan 1152 Phone : +81-44-549-2238 1153 Email : inoue@isl.rdc.toshiba.co.jp 1155 Atsushi Shimbo 1156 Toshiba Corporation, R&D Center 1157 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1158 Japan 1159 Phone : +81-44-549-2238 1160 Email : shimbo@isl.rdc.toshiba.co.jp 1162 Toshio Okamoto 1163 Toshiba Corporation, R&D Center 1164 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1165 Japan 1166 Phone : +81-44-549-2238 1167 Email : oka@isl.rdc.toshiba.co.jp 1169 Ishiyama, et al. Expires May 1997 [Page 25]