throbber
Secure Mobile IP Using IP Security Primitives
`
`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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket