`
`Atsushi Inoue, Masahiro Ishiyarna, Atsushi Fukumoto and Toshio Okamoto
`Communication and Information Systems Research Laboratories,
`Toshiba Corporation, R&D Center.
`{inoue,mosahirojuh‘umoto, aka} @isi.rdc.toshiha.co.jp
`
`Abstract
`
`As the commerciot use of the Internet becomes com-
`mon and the demand for mobite computing through
`the Internet is emerging,
`it is necessary to construct
`a secure niobite environment. This paper presents an
`imptemcntotion example of such a system which em-
`ploys a secure mobile JP protocot on stationary secu-
`rity gateways and mobite hosts. The [ETF standard
`Mooite IP protocol is modified with IP security primi-
`tiues, which controt the packet flow from a mobitc host
`through multiple security gateways. Using tP security
`primitives,
`the pocket going into a corporate network
`and the pocket going out the visiting network are both
`securety processed. This IP security based packet con-
`trot otlows transparent mobile access fiom anywhere on
`an IP network even with sufi‘icient security support by
`encrypting and authenticating lP packets. The current
`imptementation status and the performance contention
`is also reported.
`
`1.
`
`Introduction
`
`Security support is a key feature for wide commercial
`use of Internet. Demands for mobile computing are also
`emerging as smaller PCs and PDAs become more com-
`monly used. Users of such equipments want to commu—
`nicate from remote 1P connection points through var
`ious communication media. For example, even when
`an office weather is away, he may need to access propri~
`etary information inside the company from a satellite
`office.
`In order to realize such mobile application of
`Internet, a security mechanism for mobile environment
`is necessary.
`This paper proposes an approach with IP layer se-
`curity/mobility support to meet this challenge. The
`IP-laycr processing gives us a generic security/mobility
`solution because it does not afiect existing upper layer
`application software.
`IP security (IPsec) and Mobile IP are proposed by
`
`0—8186-7967-0I97 $10.00 © 1997 IEEE
`
`235
`
`[E'I‘F (Internet Engineering Task Force) as standard
`IP technologies. On IPsec, the standard protocol for
`packet authentication and encryption are proposed.
`Mobile [P is a protocol for supporting transparent ac~
`ccss from/to mobile host-s using tunneling technology.
`Combining these protocols, we are developing a pro
`totype system,
`in which secure mobile IP is imple-
`mented on gateway servers and mobile hosts. This pa-
`per presents the design policy of the prototype system,
`focusing on how the packets from remote mobile hosts
`can securely traverse the security gateways using lPsec
`primitives. The current implementation status and the
`preliminary performance evaluation is also reported.
`
`2. Key technologies
`
`2.1 Mobile IP
`
`Mobile IP [1] is a protocol for supporting transparent-
`IP mobility. With Mobile 1?, users can use a fixed
`(home) address assigned to the mobile host. even when
`the mobile host changes location on IP network. Mo~
`bile 1P supports hosts Inability as follows:
`
`\
`
`\
`
`
`
`:c:
`z t
`f
`
`:
`
`C A
`c
`
`Sta.- Cll
`135:: Homeeddr
`
`‘
`
`Figure 1.
`
`Mobile IP operation
`
`o A fixed home address is assigned to a mobile node.
`The mobile node can continue to use this home
`
`address even when it changes the location on the
`IP network.
`
`EX. 1011
`
`Apple V. MPH Techs. Oy
`IPR2019-00821
`
`Ex. 1011
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`
`
`a A Care—of~Add1'ess (CoA) is an address which is
`used by the mobile node on the visited network.
`A CoA is given from a foreign agent or assigned
`directly to the mobile node (by DHCP or other
`methods). The latter case is called “co-located
`care-of—address” .
`
`A home agent is placed on the home network where
`the mobile node is originally connected. The home
`agent receives information from the mobile node
`and maintains mobile information (such as the
`CoA). When the mobile node moves from its home
`network, the home agent receives packets in place
`of the mobile node, then forwards the packets to
`the mobile nodes current location.
`
`A foreign agent is placed on the visited network
`to which the mobile node has mOVes. The for—
`
`eign agent specifies a 00A for the mobile node. It
`receives the packets from the home agent and for—
`wards them to the mobile node, When the mobile
`
`node uses a co—located CoA, the foreign agent is
`not necessary.
`When a mobile node moves, it acquires a CoA on
`the visited network. After that, the mobile node
`sends a ”Registration request message” containing
`the care—of—address to its home agent. After the
`" Registration request message” is accepted, pack~
`ets destined for the mobile host’s original address
`{home address) are received by the home agent.
`Then the packet is encapsulated in IPinIP [2] des-
`tined for the registered COA and forwarded.
`When the mobile node uses a. co—located CoA, the
`packets from the home agent are directly trans—
`mitted to the mobiie node. The mobile node de-
`
`capsulates the forwarded packets and extracts the
`original packets destined for its home address (see
`Figure 1].
`When there is a foreign agent, the packets from
`the home agent are transmitted to the foreign
`agent. The foreign agent decapsulates the for-
`warded packets and forwards the original packets
`to the mobile node by link—layer transmission.
`When the mobile node sends packets to someone,
`it uses its home address, not the Carewof—address,
`for the source address.
`
`Therefore, the mobile node exchanges the packets
`as if it is on the home network [using its home
`address), even when it is away from its home net—
`work.
`
`2 .2
`
`IP security
`
`In order to satisfy security concerns, IP security [IPseo)
`is proposed[3].
`IPsec proposes two specific headers
`that are used to provide security services. One is
`
`the Authentication Header (AH) [4], which supports
`data integrity and authentication. The other is the
`Encapsulating Security Payload (ESP) [5], which sup
`ports integrity, authentication, and confidentiality to
`[P data-tgrams.1
`Various authentication/encryption algorithms can
`be used for AH/ ESP. The “Security Association” de-
`cides what algorithms are actually used. The Security
`Association is a set of parameters, such as authentica-
`tion/encryption algorithms, keys, and so on. A Secu-
`rity Parameter Index (SP1) is given as a parameter of
`AH/ESP. The combination ofa given SPI and Destina—
`tion Address uniquely identifies a particular “Security
`Assooiation”. Therefore, when an entity uses IPsec, it
`must negotiate a Security Association with the cone
`spondent IPsec entity in advance. The management of
`the Security Association is the role of key management
`protocol?
`the security is guaranteed on the 1?
`Using IPsec,
`layer without any impact to the upper layer applica—
`tions. Between the gateways and/or hosts which im-
`plement IPsec, a virtual private network (VPN) can be
`constructed with sufficient data secrecy, even on a Ionr
`security network like Internet.
`
`3.
`
`Security issues on mobile IP
`
`Mobile 1? provides transparent IP mobility support for
`mobile terminals. However, when we try to use Mobile
`IP for accessing a corporate network from a remote
`site, there might be several security flaws.
`
`3.1 Packets going into a corporate network
`On Mobile IF, the mobile node sends the packets with
`the source address set as its home address. Looking
`from the inside of the home network, we cannot distin-
`
`guish a mobile node’s packet from IP address spoofing
`attack packets coming from the outside with Inside ad-
`dress listed as the source address. The firewall at the
`
`entrance to the corporate network can detect that and
`refuse to pass the packet. If this packet can enter the
`corporate network, the network is a potential victim of
`an IP address Spoofing attack, and that is too danger-
`01.13.
`
`For regulating Mobile IP, some kind of authentica—
`tion is performed between the home agent and the mo-
`bile node. Therefore, it is difficult for an impostor to
`
`1Iv'la’hen integrity and authentication are only required,
`either AH or ESP can be used. If the performance is crit-
`ical, AH might be better (because hash is faster than en-
`cryption). If the trafiic must be hidden on the intermediate
`path, ESP should be used.
`20m current prototype system uses SKIP proposed by
`Sun Microsystems, for the key management protocol. See
`[6] for detail.
`
`236
`
`
`
`adopt the guise of the mobile node. The home agent
`processes the packet destined to the mobile node’s
`home address, but it has no way to check the packet
`coming from the outside with the source address set to
`the home. address. Therefore, the issue of IP address
`spoofing attack cannot be resolved within the Mobile
`IP framework.
`
`3.2 Packets going out from the visited
`network
`
`The packet from the mobile node might conflict with
`the firewall on the visited network, because the firewall
`protects the visited network by restricting the outgoing
`packet flow.
`
`3.3 Confidentiality of communication
`
`When a network is protected by a firewall, we assume
`that the network inside is secure, and send/receive the
`proprietary information without any protection (such
`as encryption).
`However, when a mobile node goes out of the pro-
`tected network, and tries to gain access to the net-
`work from a remote site, the preprietary information
`is moved outside of the protected network and might
`be subject to eavesdropping by others. Therefore, we
`have to guarantee the confidentiality of the information
`sent to the mobile node.
`
`As described above, when we try to access a pro—
`tected network using Mobile 1?, We need a mechanism
`which makes it possible to,
`(1) provide protection from IP packet forgery
`(2) secure traversal of firewalls
`(3) guarantee communication confidentiality
`
`3.4
`
`Issue resulting from combining IPsec and
`Mobile IP
`
`In IPsec,
`The above issues are all resolved by IPseC.
`the integrity of the IP datagram is guaranteed by AH
`and ESP, and the confidentiality is guaranteed by ESP.
`For issue (1), we can employ AH’s integrity property,
`confirming that the received packets are actually sent
`by the mobile node. For issue (2), we can also use AH
`between the mobile node and the firewall, which gnar-
`antees that the packet received by the firewalls comes
`from a mobile node with the priviledge of traversing
`the firewall, and that the packet is not altered between
`them. For issue (3), we can employ ESP’s confiden—
`tiality property for protecting the IP datagram. When
`the packet goes toward the outside mobile node, we can
`use ESP betWeen the firewall and the mobile node to
`
`avoid eavesdropping.
`All the above issues between the mobile node and
`
`the firewall are resolved by introducing IPsec. As IPsec
`
`and Mobile [P are designed independently, there is no
`impact on each other, even when we use them simulta-
`neously.
`However, when we combine Mobile IP and IPsec, a
`new issue arises. As the mobiie node moves over the
`
`[P network using IPsec, the correspondent IPsec entity
`might change depending on the 1P connection point.
`For example, consider the case when the mobile node
`communicates with best H1 in Figure 2. If the mobile
`node is at position A, it has to go through the firewall
`FW. But when it moves to position B, it does not goes
`through FW. When the mobile node talks with h05t
`H2, the situation is reversed.
`
`
`
`Figure 2.
`
`The change of traversed firewalls on
`Mobile Node’s movement.
`
`Therefore, the mobile node must identify which fire—
`walls (on the path toward the correspondent host) have
`to be traversed every time it changes location on IP
`network. Since we assume there are nested firewalls
`
`(inside one network), there might. be multiple firewalls
`to be traversed in general.
`
`4.
`
`Proposed system
`
`A typical system configuration is shown as Figure 3.
`An IPsec—processing firewall is called a “Security Gate—
`way (SGW)”. We assume that all firewalls in the sys-
`tem are SGWS with IPsec-processing capability. A
`SGW is typically placed on the boundary between the
`inside network of a certain organization and Internet
`(just like an ordinary firewall). Also, a SGW can be
`placed inside the organization in order to protect the
`network of a specific division.
`On the home (subjnetwork of a mobile node, there
`is a home agent (HA). The correspondent host (shown
`as CH) can be anywhere in the system as far as the
`SGW’s policy allows.
`
`4.1 Security Gateway
`
`As described before, the SGW provides security ser—
`
`vices (including lPsec) to the hosts of its protected
`network.
`\«Ve assume that each SGW.is properly main~
`tained by skilled system administrators, who can de—
`cide the security policies for the SGWs considering the
`
`237
`
`
`
` other Si re
`
`Figure 3. Typical system configuration
`
`various demands from the organizations. Therefore, if
`communication between two networks is allowed, the
`SGWs know each other and exchange the necessary in-
`formation with each other.
`
`4.2 Secure Mobile Node
`
`A mobile node has to process IPsec by itself. This
`
`1PSEC-processing mobile node is called a “Secure
`Mobile Node (SMN)". SMN uses co-located care-of-
`addresses. Therefore, SMN can decapsulate the pack—
`ets from the home agent, and no foreign agents are
`needed.
`
`4.3 Assumption for the proposed system
`
`the system configu—
`We assume the following about
`ration, the operation of system components, and the
`maintenance conditions.
`
`0 There are no IP address collisions on the prOposed
`system. That means, when one IP address is speci-
`fied, one host uniquely corresponds to the address.
`The correspondent host with which SMN can com-
`municate using Mobile IP, can be reached from the
`home network of the SMN. That means, when the
`SMN moves anywhere in the system, the commu—
`nication between the correspondent host and the
`home agent (which relays the packet to the current
`location of SMN) is guaranteed.
`We expect that SGWs are maintained by skilled
`system administrators. But on the other hand.
`SMNs are assumed to be used by ordinary users
`(without special skilis/knowledge). Therefore, we
`should limit the statically registered information
`on the SMN to be as small as possible.
`
`5. Dynamic gateway discovery
`
`When a Secure Mobile Node moves on an IP network,
`the path toward the correspondent host changes. This
`
`means that the SGWs to be traversed aiso change.
`However, the approach of installing all the informa-
`tion about all SGWs and their protected network sets
`onto a Secure Mobile Node does not meet the demand
`to limit the information on the Secure Mobile Node to
`
`the minimum possible level. Therefore, we have to in—
`vestigate the method of dynamically discovering SGWs
`to be traversed for a given correspondent host.
`
`5.1 Dynamic SGW discovery
`
`The basic strategy is that. when the packet traverse
`the SGW, the SGW report to the SMN that a kind of
`authentication is necessary.
`When receiving packets, an ordinary firewall decides
`whether it receives/forwards or discard the packets.
`This decision is based on the firewall’s security pol-
`icy. A SGW’s security policy is that “before a. packet
`is allowed to go through, a kind of authentication is
`necessary”. When the SGW receives packets on which
`no authentication has been done, the SGW notifies the
`source address that authentication is necessary for the
`received packets (usually the SMN) 3. For this authen—
`tication request message, a UDP or ICMP packet with
`some specific format can be used.
`We can use the AH mechanism of IPsec for authen-
`
`tication request between SGWs. On receiving this au-
`thentication request, the Mobile Node. appends the au-
`thentication requester SGW into the list of SGWs to
`be traversed. Then, the Mobile Node will then do the
`negotiation for exchanging the necessary authentica-
`tion key information with the SGW. This negotiation
`could be done either in an off-line manner or some on—
`
`line method, like exchanging certificate request [reply
`messages?
`Let’s consider the case that the Mobile Node MN
`
`communicates with host H traversing SGW 31 (Figure
`4). Si is on the path between MN and H. First, MN
`sends a plain 1P packet to host H. 5]. gets the packet
`and judges that an authentication code is necessary
`for forwarding this packet to H, so 81 returns the au-
`thentication request to the source address of the packet
`(MN). MN receives this request and append 31 to the
`list of SGWs to be traversed.
`
`5.2 Dynamic discovery and outside network
`
`When an organization employs a. SGW, it is common
`that it does not expose the internal H" network path in«
`formation to the outside world. The dynamic SGW dis-
`
`aThis authentication request might be returned to the
`SMN's home address. So, that request message might tra-
`verse a route other than that which the packet from the
`SMN used. Here, we assume that the traversal of an au~
`thentication request between SGWs is guaranteed.
`‘Each SGW maintains the authorized SMNs in its table
`
`238
`
`
`
`
`
`MN
`
`31
`
`stc: MN. dst: H
`
`
`fi‘v
`Security Policy check
`
`
`Authenticiion request
`
`Figure 4.
`
`Dynamic gateway discovery
`
`covery described above assumes that the packet surely
`arrives at the intermediate SGW along the path toward
`the destination correspondent hest. Therefore, a path
`from the mobile node’s current location to the desti-
`
`nation must exist. But when the mobile node goes to
`an outside network and tries to access an internal host,
`this assumption might not be valid.
`To avoid such a situation, we define a “default bor~
`der gateway”. A border gateway is a SGW placed on
`the border between inside/ outside networks for an or—
`ganization. A mobile node have to have at least one
`entry of the following information.
`
`(border gateway, All internal networks)
`All internal networks is a set of all network addresses
`
`which are used in the organization. All such networks
`are protected by one border gateway (not necessarily
`the specified border gateway). For example, three net-
`works {Home Site NetworkOther Site 1, Other Site 2)
`correspond to this All internal networks in Figure 3.
`We call the border gateway specified above a default
`border gateway. When a mobile node detects that its
`care—of—address is not included in the All internal net—
`works set and the address of CH is included in All in-
`
`ternal networks, then it uses this default border gateway
`as the Next-Hop SGW (without doing dynamic SGW
`discovery). Even if the mobile node is not in “All in-
`ternal networks", we assume that the ability to reach
`the default border gateway is guaranteed.
`The SMN’s default border gateway might be the in-
`correct border gateway. That is, even though the de-
`fault border gateway receives the packet and processed
`the IPsec (such as authentication and decryption), the
`destination of the packet is not included in the SGW’s
`protected network. In such a case, the default border
`gateway has to forward the packet to another border
`gateway, employing an appropriate IPsec mechanism
`between border gateways (See Figure :3)
`The advantage of using a default border gateway is
`as follows:
`
`First, it becomes poesiblc for a mobile node to so-
`curely communicate from an outside network to an
`internal network without registering the information
`
`
`
`Figure 5.
`
`Transmission between border
`
`gateways
`
`about all border gateways (and their protected net~
`works).
`If all SGWs supports the dynamic discovery
`method, the only information a SMN need to know is
`this (border golewor , All internal networks) pair.
`Many people believe that a firewall should not expose
`its information to the outside world. The firewalls must
`
`be “calm” and should not send unnecessary packets to
`the outside. The border gateways should be especially
`calm because they can be attacked from everywhere
`over the Internet. On the other hand, a Secure Mobile
`Node assumes reception of a response from the SGW
`in order to realize the dynamic SGW discovery, and
`this conflicts with the previous “SGW should be calm"
`principle. So, we have to find the balanced solution.
`On this system, we stipulate that all SMNs know
`(at least one) default border gateway. The SMN and
`the default border gateway do not exchange messages
`like the dynamic SGW discovery scheme. Therefore,
`when the SMN moves out of the organization, we can
`limit the packet flow between the SMN and the default
`border gateway to a minimum, and the border gateway
`can be maintained more securely.
`
`6. Communication model
`
`6.1 SGW traversal using IPsec
`
`Once the SGWs to be traversed are discovered, the
`Secure Mobile Node tries to share a Security Assoei—
`ation(SA) with each SGW. Though we don’t discuss
`the key exchange method here, we can use a key man-
`agement protocol, such as SKIP[6] and ISAKMPW] for
`that.
`
`After setting SA for each SGW, the IPsec mechanism
`is used for each SGW based on the 'SA. For example,
`consider the case when the Secure Mobile Node SMN
`
`communicates with host H traversing SGWs, Si and
`
`239
`
`
`
`Each SGW has to recognize that the packet comes from
`the Secure Mobile Node even with the SMN‘s care-of-
`
`address is specified. Therefore, the Secure Mobile Node
`has to negotiate with SGWs in advance.
`
`7.
`
`Implementation status and
`evaluation
`
`7.1
`
`Implementation status
`
`The prototype system is currently implemented on
`BSD/OS 2.1. The prototype system consists of (1)
`Mobile IP node,
`(2) Mobile IP home agent, and (3)
`IPsec module. Most of the componcnts are imple—
`mented as user applications. DES and Triple-DES are
`implemented as encryption algorithms, and the hash
`function for authentication is MD5. SKIP [6]
`is im-
`plemented as the key management protocol. Dynamic
`SGW discovery is not implemented yet.
`
`7.2 Performance
`
`In order to measure the overhead caused by IPsec and
`
`Mobile IP processing, we measured TCP bulk transfer
`rate by NetPerf 5. The test environment is showu in
`Figure 7. The results are summarized in Table 1. MTU
`is set to 1300 to avoid IP fragmentation.
`
`SMN: PSfltXJMI-lz. BSIN'OS 2.]
`CH: PSIQOMI-lz. BSWOS 2.I
`SGW: PSJ'I33MHZ. BSDIDS 2.1
`
`HA: PSIJUOMHZ. 1150305 2.1
`
`Figure 7. Environment for performance
`measurement
`
`Plain IP(1) is the result without using Mobile IP nor
`lPsec. SGW Operates as a router (no IPsec processing).
`On Mobile IP(2), only Mobile IP is used. SGW works
`as a router also. IPsec(3, 4) use SKIP as the key man—
`agement protocol. We measured both AH-only and
`AH—l—ESP cases. IPsec is used between the SGW and
`
`SMN. MIP+IPsec(5, 6) use both Mobile IP and [Fees
`simultaneously.
`the performance from CH
`Comparing (I) and (2),
`to SMN is worse. The packet from sender to receiver
`contains the payload, but the packet in the reverse di-
`rection contains ACK only. On transmitting from CH
`
`6.2 SGW to be discovered
`
`There are two paths along which SGWs to he traversed
`need to be discovered. One is the path from the current
`location of the mobile node to the home agent. The
`registration request/reply messages and IPinIP pack-
`ets from HA flow on this path. Once the mobile node
`moves, it maintains this path and sends Mobile IP reg—
`istration message to the home agent.
`The other is the path from the mobile node to the
`correspondent host. The packets from the mobile node
`flow on this path. As we assume that the path from
`the correspondent. host to the mobile node (via home
`agent) is already guaranteed (as the correspondent host
`is reachable from the mobile node’s home network). we
`need not care about. that.
`
`On both paths, when Secure Mobile Node uses IPsec,
`it should use the care-of-address for the outer 1P header
`
`because it might receive error information (such as
`ICMP unreachable) forwarded to the care—of—address.
`
`5URL:
`http:l/www.cup.hp.com/netperf/NetperfPage.html
`
`240
`
`S2 (in this order). Assume that SMN’s SA is set as
`using ESP with 81 and S2. The SMN processes the
`packet (destined for H) by ESP (with 82’s SA), then
`processes the packet (destined for S2) by ESP (with
`81’s SA). When 31 receives this packet,
`it decapsu—
`lates the packet and forwards the result packet. The
`forwarded packet is sent to 52. Then 52 processes the
`packet (just the same way), and forwards the decapsu—
`lated packet. That packet is forwarded to H.
`As Secure Mobile Node sent ESPs for both 51 and S2
`
`separately. both SI and S2 can authenticate that the
`sender of packet is surely SMN. The sequence (com—
`bined with dynamic SGW discovery scheme) is shown
`in Figure 6.
`
`H
`
`r
`.
`.
`I
`
`’
`’
`
`uI
`
`
`
`I HEMN
`I
`'
`tlsi: H
`—v—v—II
`
`'Aumcnu'catiou Item-ii
`
`. T
`
`Figure 6.
`
`he packets on traversing SGWs
`with IPsec
`
`MN
`.
`.
`
`SMMN
`deli H
`
`Avihcmisanm request
`
`51
`
`32
`
`.
`u
`.
`u
`
`.
`.
`.
`-
`
`I
`u
`'
`
`
`
`any Il'J connection point, it can automatically discover
`the security gateways along the path to the correspon—
`dent host. Since an IPsec mechanism operates on each
`security gateway, the packets from the mobile node can
`be securely passed over each SGW.
`A prototype system is implemented on BSD/OS. On
`the prototype, we have measured the performance. The
`result is also presented. The processing overhead is
`high on an high-speed LAN environment, but. on a low—
`speed WAN or serial line communication, the perfor—
`mance will be feasible.
`
`A number of topics are candidates for future work,
`including the in'iplementation of dynamic SGW discov—
`cry, a detailed mechanism for certificate distribution,
`route optimization, cooperation with existing firewalls,
`and so on.
`
`References
`
`[1] C. Perkins. lP Mobility Support. RFC- 2002, Octo-
`ber 1996.
`
`C. Perkins. IP Encapsulation within IP. RFC 2003,
`October 1996.
`
`R. Atkinson. Security Architecture for the Internet.
`Protocol. RFC 1825, AugiJst 1995.
`
`R. Atkinson. IP Authentication Header. RFC- 1826,
`August 1995.
`
`R. Atkinson. IP Encapsulating Payload. RFC 1827,
`August 1995
`
`A. Asia, T. Markson, H. Prafuilchandra. Simple
`Key—Management For Internet Protortols (SKIP),
`(1—D draft—ietf-ipsec-skip-07.txt), August 14, 1996
`
`D. Maughan, M. Schertler, M. Schneider, J. Turner.
`Internet Security Association and Key Management
`Protocol (ISAKMP), (l-D draft-ietf-ipsec-isakmp-
`07.txt}, February ‘21, 1991'
`
`SMN—i CH
`CH —>SMN
`SMN—i CH
`CH —)SMN
`SMN—i CH
`
`.
`.
`2 11
`3 22
`
`Table 1.
`
`Results of performance measurement
`From—i To
`
`protocol
`Mbit/sec
`Plain IP
`
`
`
`Plain IP
`
`Mobile IP
`
`
`
`Mobile IP
`
`
`lPsec (AH only)
`
`lPsec (Al-I only}
`
`
`
`SMN—er CH
`IPsec (AH+ESP)
`
`CH —>SMN
`
`IPsec (AH+ESP)
`SMN—i CH
`Both (All only)
`
`
`
`CH —+SMN
`Both (AH only)
`
`
`SMN—i CH
`Both (AH+ESP)
`
`
`CH —>SMN
`Both (AI-I-i—ESP)
`
`
`
`
`to SMN, the packet with large payload is encapsulated
`on the HA,
`then forwarded to the SMN. Therefore,
`the packet passes the CH’s link twice, and it consumes
`more (almost double) bandwidth. From the result for
`(5), the IPsec overhead is also very high.
`For the case using Mobile IP and IPsec simultane—
`ously, we expected that the performance would be al—
`most the same as the case when only IPsec is used.
`The reasons are:
`
`a The proeessing on each host for the packet from
`the SMN does not change from the case when
`IPsec is only used.
`0 The Mobile IP packet processing is done on the
`HA, and the IPsec processing is done on the SGW
`separately. On the SMN, only the processing for
`lPinIP decapsnlation is appended. Therefore, we
`expect that the overhead coming from the lPsec
`decryption processing might be more dominant
`than the portion of overhead from the Mobile [P
`However, comparing (6) and (4), we cannot
`ignore
`the performance degradation caused by Mobile IP. We
`want to study this in future.
`As this prototype implements most of the modules
`as user applications, a great deal of overhead seems to
`come from the data copy between the kernel and user
`spaces. We can expect better performance with kernel
`implementation.
`
`8. Concluding Remarks
`
`This paper proposes a system with secure mobile com~
`puting support, in which two IETF standard protocols,
`lPsec and Mobile W, are effectively combined. The
`proposed system consists of security gateways placed
`on each organization. mobile nodes which can move
`freely on the Internet, and home agents which main—
`tain the host mobility. When a mobile node moves to
`
`241
`
`