The present invention relates to the field of mobile computing, and, more particularly to a seamless, secure roaming solution across enterprise firewalls.
Use of mobile computing devices (hereafter “mobile nodes”) such as laptops, notebook computers, personal digital assistants (“PDAs”) and cellular telephones is becoming increasingly popular today. These mobile nodes enable users to move from one location to another (“roam”), while continuing to maintain their connectivity to the same network. Given its increasing popularity, it is unsurprising that most corporate (“enterprise”) networks today attempt to facilitate fast and secure mobile computing.
In order to roam freely, networks today generally conform to mobile IP standards promulgated by the Internet Engineering Task Force (“IETF”). Mobile IPv4 (IETF RFC 3344, August 2002) is currently the predominant standard, and many networks today are Mobile IPv4 compliant. The standard, however, fails to provide solutions to obstacles that arise in certain roaming scenarios.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements, and in which:
Embodiments of the present invention provide a seamless roaming solution across enterprise security mechanisms such as firewalls. Reference in the specification to “one embodiment” or “an embodiment” of the present invention means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment,” “according to one embodiment” or the like appearing in various places throughout the specification are not necessarily all referring to the same embodiment.
Alternatively, when MN 140 leaves its home subnet, it may register with HA 130 via a foreign agent (“FA 135”) on MN 140's new (“foreign”) subnet. By registering with FA 135, MN 140 may use FA 135's IP address as its COA when registering with HA 130. In this scenario, HA 130 continues to intercept all packets addressed to MN 140, but these packets are now rerouted to FA 135, namely MN 140's COA as provided to HA 130. FA 135 examines all packets it receives, and sends the appropriate ones to MN 140 at its current location on the foreign subnet. This configuration is commonly referred to as a “non co-located” communications mode. The decision of whether to use co-located or non co-located mode is well known to those of ordinary skill in the art. Certain networks may, for example, force MN 140 to register with FA 135 in order to maintain its transport connections. In other networks, MN 140 may have the option of registering with FA 135 or operating in a co-located mode.
Corporate Intranet 100 may also be coupled to an external network, such as the Internet, and MN 140 may roam between Corporate Intranet 100 and the external network.
For security purposes, many network topologies are likely to include security gateways such as Virtual Private Network (“VPN”) gateways (collectively illustrated in
The presence of VPN Gateway 225 introduces a layer of complexity when MN 140 attempts to roam between Corporate Intranet 100 and External Network 205. More specifically, if VPN Gateway 225 exists between Corporate Intranet 100 and External Network 205, when MN 140 exits Corporate Intranet 100 to roam on External Network 205, MN 140 has to first establish a secure IP connection (illustrated conceptually as “IPSec Tunnel 245”) with VPN Gateway 225 in order to maintain its current transport connections. IPSec Tunnel 245 between MN 140 and VPN Gateway 225 is associated with two tunnel IP addresses. The two addresses correspond to Tunnel Outer Address (“TOA”), namely the address of MN 140 on External Network 205, External Networkand Tunnel Inner Address (“TIA”), the address that is assigned to MN 140, which is logically on a subnet inside Corporate Intranet 100. In the example above, IPSec Tunnel 225's TOA corresponds to MN 140's COA. Use of IPSec tunnels with VPN gateways are well known to those of ordinary skill in the art and further descriptions of such are omitted herein.
Once IPSec Tunnel 245 is established between MN 140 and VPN Gateway 225, if MN 140 roams on External Network 205, MN 140 must continuously update HA 130 via IPSec Tunnel 145 with its new COA. As described above, however, IPSec Tunnel 145's TOA corresponds to MN 140's COA. Thus, in co-located mode, as MN 140 changes its current point of network attachment and its COA changes, MN 140 will have to renegotiate a new IPSec tunnel with VPN Gateway 225 with its new COA as the new IPSec tunnel's TOA. This renegotiation process has significant performance implications and may cause packet flows to timeout prior to successful renegotiation.
In non co-located mode, MN 140's COA may also continuously change as it roams on External Network 205. Each time MN 140 moves from one subnet to another on External Network 205, it may register with a different foreign agent on each respective subnets. Each time MN 140 registers with a different foreign agent, MN 140's COA may change since MN 140 uses the foreign agent's address as its COA. In this configuration, however, the presence of VPN Gateway 225, and by extension, the use of IPSec Tunnel 145, preclude FA 235 (which is likely to be in a different administrative domain from HA 130 and any other foreign agents on External Network 205 from being able to view the contents of the IP packets it receives from MN 140 and HA 130. In other words, FA 235 will not be able to decrypt the IP packets between MN 140 and HA 130. Consequently, FA 235 may not be not able to deliver the packets to and from MN 140 and/or HA 130.
Embodiments of the present invention resolve difficulties arising from mobile nodes attempting to securely roam across enterprise DMZs that include VPN gateways. In co-located modes (where mobile nodes obtain COAs via DHCP or other similar protocols), embodiments of the present invention improve performance by addressing the problem described above, namely that mobile nodes have to renegotiate IPSec tunnels with VPN gateways each time they move from one subnet to another on the foreign networks. In non co-located modes (where mobile nodes register with foreign agents and use the foreign agent's IP address as their COA), embodiments of the present invention enable mobile nodes to communicate across VPN Gateways via IPSec tunnels, while maintaining their transport connections.
Embodiments of the present invention are described in conformance with the Mobile IPv4 standard (IETF RFC 3344, August 2002). It will be readily apparent to those of ordinary skill in the art, however, that embodiments of the present invention may be implemented on networks confirming to other roaming standards. Networks may be compliant with Mobile IPv6 (IETF Mobile IPv6, Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In Progress), October 2002), for example, but due to the current nature of such networks, the above-described problems are unlikely to arise. It will be readily apparent to those of ordinary skill in the art, however, that in the event such problems do arise within Mobile IPv6 or other similar networks, embodiments of the present invention may easily be modified for use on such networks.
According to embodiments of the present invention, MN 140 may include, but is not limited to, laptops, notebook computers, handheld computing devices, personal digital assistants (PDAs), cellular telephones, and other such devices capable of wireless access. The following represent typical roaming scenarios for MN 140. First, as described with respect to
In one embodiment, MN 140 may roam from a subnet within Corporate Intranet 100, across Corporate DMZ 210, to a subnet on External Network 205. In this scenario, in order to communicate (or maintain existing communications) with nodes such as Correspondent Node (“CN”) 310 on Corporate Intranet 100, according to an embodiment of the invention, MN 140 registers with HAi 300 and HAx 305. More specifically, MN 140 first registers with HAx 305 and obtains its home address on HAx 305 (“MN_Hx”) and its care-of address on External Network 205 (hereafter “COAx”), which may be obtained via a DHCP server and/or other similar means. The DHCP server may, for example, be owned by a service provider on External Network 205. In other embodiments, MN 140 may obtain COAx from Foreign Agent 235.
MN 140 then establishes IPSec Tunnel 315 to VPN Gateway 225. Once again, IPSec Tunnel 315 between MN 140 and VPN Gateway 225 is associated with two tunnel addresses, TOA and TIA. According to embodiments of the present invention, prior to or during the process of negotiating with VPN Gateway 225 to establish IPSec Tunnel 315, MN 140 and/or VPN Gateway 225 may assign MN_Hx as the TOA, and MN 140's home address on HAi (“MN_Hi”) as the TIA. It will be readily apparent to those of ordinary skill in the art that the process of assigning MN_Hx and MN_Hi to TOA and TIA respectively may be performed in a number of ways. MN_Hi is an invariant address assigned either statically or dynamically to MN 140. MN_Hi may, for example, be manually associated with MN 140 by a corporate Information Technology department or other such entity. Alternatively, the address may be assigned dynamically through a registration request from MN 140, combined with a Network Address Identifier (“NAI”) extension. Other similar methodologies may be employed in various embodiments. The previous description assumes that MN 140 is aware of its invariant home address prior to roaming outside Corporate Intranet 100. If, however, MN 140 does not initially know its home address when it roams from Corporate Intranet 100 to External Network 205, MN 140 may have to perform additional steps described in detail later in this specification.
Once IPSec Tunnel 315 is established, MN 140 may register (via IPSec Tunnel 315) with HAi 300 and provide HAi 300 with its home address (MN_Hi) and a care-of address with respect to HAi 300 (“COAi”). In one embodiment, COAi is VPN Gateway 225's private IP address. Thereafter, MN 140 may apply IPSec security protocols to all IP packets it transmits, and send these packets securely to nodes on Corporate Intranet 100 via IPSec Tunnel 315 and vice versa. IPSec security protocols may include the IP Authentication Header (“AH”) protocol and the Encapsulating Security Payload (“ESP”) protocol. AH may provide connectionless integrity, data origin authentication and optional anti-replay services while ESP may provide encryption, limited traffic flow confidentiality, connectionless integrity, data origin authentication and anti-replay services. For the purposes of this specification, references to “encryption” and/or variations thereof generally refer to applying AH and/or ESP to IP packets, and references to “IPSec-protected IP packets” refers to IP packets that are encrypted. The mechanisms to perform such encryption are known to those of ordinary skill in the art and description of such is therefore omitted herein in order not to unnecessarily obscure embodiments of the present invention.
Once MN 140 is registered with HAx and HAi, and IPSec Tunnel 315 has been established, MN 140 may send and receive IPSec-protected IP packets to and from CN 310. As illustrated conceptually in
In an embodiment, CN 310 may respond to the IP packet by sending out a responsive IP packet to MN 140. In an alternate embodiment, CN 310 may initiate correspondence with MN 140. In either instance, since MN 140 is registered with HAi 300, any packets from CN 310 may be intercepted by HAi 300 in 407. HAi 300 examines the packet and sends the packet to COAi (i.e., VPN Gateway 225's private address which is MN 140's care-of address with respect to HAi 300) in 408. VPN Gateway 225 receives the encrypted IP packet, removes the outer IP encapsulation and examines the packet to determine the address of the destination node, in this case MN 140. Upon identifying MN 140 as the destination node, VPN Gateway 225 encrypts the packet and sends the packet to MN_Hx. Since MN 140 is registered with HAx 305 on External Network 205, HAx 305 intercepts that packet in 409. HAx 305 examines the IP packet, identifies MN 140 as the destination node, and in 410, HAx 305 routes the packet to MN 140's COAx (i.e., MN 140's current subnet location on External Network 205).
As described above, the previous descriptions assume that MN 140 knows its home address when it initially exits Corporate Intranet 100. In the event MN 140 is not yet aware of its home address and/or has not yet been assigned a home address when it exits Corporate Intranet 100 onto External Network 205, the embodiments of the invention may still be applied. In this situation, however, MN 140 may initially register with HAx 305, establish a temporary IPSec tunnel (“IPSec Temp”) with VPN gateway 225, and register with HAi 235. When registering with HAi 235, MN 140 may leave the “home address” field empty, thus allowing HAi to assign a home address to MN 140. Once MN 140 receives this assigned home address, it may then tear down IPSec Tunnel Temp and establish IPSec Tunnel 315 using the recently assigned invariant home address as the TIA. Thereafter, embodiments of the invention may be applied as described above.
According to embodiments of the present invention, when MN 140 roams from External Network 205 back to Corporate Intranet 100, MN 140 may remain registered with HAi 300. MN 140 may, however, tear down IPSec Tunnel 315. For the purposes of this application, “tear down” includes removing associations between MN 140, HAx 305, TIA and TOA. MN 140 may then continue to roam within Corporate Intranet 100 while maintaining its transport connections.
If MN Mobile Node 140 exits Corporate Intranet 100, intending to roam solely on External Network 205, i.e. it does not intend to communicate with any nodes on Corporate Network 100, MN 140 may simply register with HAx 305 and establish IPSec Tunnel 315 with VPN Gateway 225. MN 140 does not, in this scenario, have to register with HAi 300 because HAi 300 only routes packets within Corporate Network 100. By establishing IPSec Tunnel 315 with VPN Gateway 225, however, MN 140 may maintain its transport connections on Corporate Network 100 and communicate securely with other nodes on External Network 205.
The mobile nodes, home agents and VPNs according to embodiments of the present invention may be implemented on a variety of data processing devices. It will be readily apparent to those of ordinary skill in the art that these data processing devices may include various software, and may comprise any devices capable of supporting mobile networks, including but not limited to mainframes, workstations, personal computers, laptops, portable handheld computers, PDAs and/or cellular telephones. In an embodiment, mobile nodes may comprise portable data processing systems such as laptops, handheld computing devices, personal digital assistants and/or cellular telephones. According to one embodiment, home agents and/or VPNs may comprise data processing devices such as personal computers, workstations and/or mainframe computers. In alternate embodiments, home agents and VPNs may also comprise portable data processing systems similar to those used to implement mobile nodes.
According to embodiment of the present invention, data processing devices may include various components capable of executing instructions to accomplish an embodiment of the present invention. For example, the data processing devices may include and/or be coupled to at least one machine-accessible medium. As used in this specification, a “machine” includes, but is not limited to, any data processing device with one or more processors. As used in this specification, a machine-accessible medium includes any mechanism that stores and/or transmits information in any form accessible by a data processing device, the machine-accessible medium including but not limited to, recordable/non-recordable media (such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media and flash memory devices), as well as electrical, optical, acoustical or other form of propagated signals (such as carrier waves, infrared signals and digital signals).
According to an embodiment, a data processing device may include various other well-known components such as one or more processors. The processor(s) and machine-accessible media may be communicatively coupled using a bridge/memory controller, and the processor may be capable of executing instructions stored in the machine-accessible media. The bridge/memory controller may be coupled to a graphics controller, and the graphics controller may control the output of display data on a display device. The bridge/memory controller may be coupled to one or more buses. A host bus host controller such as a Universal Serial Bus (“USB”) host controller may be coupled to the bus(es) and a plurality of devices may be coupled to the USB. For example, user input devices such as a keyboard and mouse may be included in the data processing device for providing input data.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be appreciated that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Number | Name | Date | Kind |
---|---|---|---|
6452920 | Comstock | Sep 2002 | B1 |
6496704 | Yuan | Dec 2002 | B2 |
6522880 | Verma et al. | Feb 2003 | B1 |
6950862 | Puthiyandyil et al. | Sep 2005 | B1 |
20020018456 | Kakemizu et al. | Feb 2002 | A1 |
Number | Date | Country | |
---|---|---|---|
20040120328 A1 | Jun 2004 | US |