Patent Application
20090106831
1. Field of the Invention
This invention relates to Internet Protocol (IP) networks, and more particularly, to methods and systems for establishing an Internet Protocol Security (IPsec) protected Generic Routing Encapsulation (GRE) tunnel in Simple IP networks.
2. Discussion of Related Technology
A wireless network, such as a WiMAX network based on IEEE802.16d/e standard, usually includes mobile stations and base stations. The mobile stations can be used while in motion or during halts at unspecified points, while the base stations provide connectivity, management, and control for the mobile stations. The wireless network may consist of an Access Service Network (ASN) and a Connectivity Service Network (CSN). An ASN is a set of network devices and protocols that provide radio access to mobile stations. A CSN is a set of network devices and protocols that provide IP connectivity services to mobile stations. More detailed discussion of various components in a WiMAX network can be found in WiMAX Forum Network Architecture (Stage 3: Detailed Protocols and Procedures), Jul. 11, 2007, Release 1.1.0, hereby incorporated by reference.
As illustrated in
The Mobile IP protocol was first introduced by the Internet Engineering Task Force (IETF). In a Mobile IP environment, the R3 data path establishes a MIP session, which enables MS global roaming without changing its IP address. The MS with MIP capability can roam into different networks without losing its original IP address which is assigned when it registers with the network for the first time. However, many MS's don't have MIP capability. In order to provide those MS's with the same mobility performance as the MS's with MIP capability, a Proxy MIP protocol (PMIP) has been developed that enables a network entity called a PMIP client to conduct Mobile IP operations on behalf of the MS.
To provide MIP or PMIP service, network entities such as Foreign Agent (FA), Home Agent (HA), Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) need to be installed in both ASN and CSN networks. These entities are expensive and have complicated state machines. There is a great interest from Service Providers to set up networks without these entities during initial network deployment. One type of such a network is a Simple IP network, which operates in accordance with the Simple IP protocol. In a Simple IP network, a mobile station obtains a new IP address (and loses its existing connections) every time it changes its anchor point where the IP address comes from. One perceived realization of a Simple IP network is to co-locate an ASN and a CSN together. If the ASN and CSN are located together, IP addresses can be assigned by simple DHCP relay using DHCP server method, as specified by RFC2131 and RFC2132. RFCs are formal Requests for Comments documents of the Internet Engineering Task Force (IETF), publicly available, for example, at http://www.ietf.org/rfc.html. In a split ASN-CSN architecture, however, a protocol is still needed to establish a tunnel between the ASN and CSN because IP addresses need to be anchored at the CSN. One possible implementation is to pre-configure this tunnel between the ASN and CSN, but this solution does not scale well. Another possible implementation is to establish a tunnel by setting up a private virtual network (VPN) in accordance with the Internet Protocol Security (IPsec), referred herein as “Client IPsec VPN.”
Internet Protocol Security (IPsec) is a protocol that provides security services at the IP layer. IPsec can be used to protect one or more paths between a pair of hosts, between a pair of secure gateways, or between a security gateway and a host. An example of an IPSec protocol is specified in RFC4301 and RFC4306.
The IPsec architecture uses the concept of a security association (SA) as the basis for building security functions into IP. An SA is simply a bundle of algorithms and parameters (such as keys) used to encrypt and authenticate a particular data flow in a particular direction. The protection offered by an SA is based on requirements defined by a Security Policy Database (SPD). The protection offered by the SA can also be fine-tuned by a set of selectors. Some of the commonly used selectors are Remote IP Address(es), Local IP Address(es), Next Layer Protocol (referred herein simply as the “protocol”), Local Port, and Remote Port. Specific IPsec implementation may choose to implement IP addresses only, IP addresses and protocol, or IP addresses, protocol and ports. Implementation of selectors without ports is coarse. If ports are implemented, they are negotiated with range, i.e., from “start port” to “end port” for both Local Port and Remote Port.
The IPSec protocol may be implemented in either tunnel mode or transport mode. In tunnel mode, the entire IP packet (data plus the message headers) is encrypted and/or authenticated. Tunnel mode can be used for network-to-network, host-to-network, and host-to-host communications over the Internet. In transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or authenticated. Transport mode is used for host-to-host communications.
Client IPsec VPN implementation is described by RFC3456.
If the MS is not IPsec capable, the ASN Gateway (ASN-GW) can function as an endpoint to establish a network based IPsec tunnel.
In a conventional network based IPsec VPN, both ends are stationary networks with stationary hosts, and each host is assigned an IP address in its local subnet. On the other hand, in
Since the IPsec tunnel between ASN-GW 311 and home SG 331 is now shared among many MS's 301 as opposed to a dedicated tunnel in a conventional client IPsec, there are many problems that need to be resolved in this network based IPsec VPN implementation in a wireless network. Specifically, the IPsec tunnel in this implementation is not able to route and differentiate concurrent DHCP sessions, because all DHCP broadcast messages have the same addresses: 0.0.0.0 and 255.255.255.255. It is also not able to route and encrypt multicast traffic because the Security Policy Database (SPD) entry cannot provide ANY to ANY selector as in a conventional client IPsec. Multicast routing in general will require Group Security Association (GSA) and multicast capable IPsec implementation. Furthermore, the IPsec tunnel in this implementation is not able to route and encrypt private IPv4 addresses because there are duplicate private IPv4 addresses in the same ASN.
Therefore, there is a need for improved methods and systems for establishing an IPsec tunnel for Simple IP networks in split ASN-CSN realization, in accordance with various embodiments of the invention.
A wireless network, such as a WiMAX network, usually includes an Access Service Network (ASN) for providing radio access to mobile stations, and a Connectivity Service Network (CSN) for providing IP connectivity service to mobile stations. In a Simple IP network that does not support either the MIP or PMIP protocol, a tunnel needs to be established between the ASN and CSN to transmit control information and IP packets.
Embodiments of the present invention are directed to methods and systems for establishing an Internet Protocol Security (IPsec) protected Generic Routing Encapsulation (GRE) tunnel in Simple IP networks. In one embodiment, a GRE layer is inserted between the user plane and the IP transport plane, and a GRE key is used to differentiate each user session. The IPsec protected GRE tunnel may be used to provide full DHCP configuration support. It may also used to provide broadcast/multicast support, as well as non-IP traffic support.
In a further embodiment, a method of asymmetric GRE key allocation is provided. The GRE key may consist of a first half key and a second half key; the first half key may be allocated by a first node, and the second half key may be allocated by a second node.
In the following description of exemplary embodiments, reference is made to the accompanying drawings which form a part hereof, and in which it is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.
Although embodiments of the present invention are described herein in terms of a WiMAX network, it should be understood that the present invention is not limited to this application, but is generally applicable to any wireless network.
Embodiments of the present invention are directed to methods and systems for establishing an IPsec protected Generic Routing Encapsulation (GRE) tunnel in Simple IP networks.
The GRE protocol is specified in RFC2890. A GRE packet is formed by adding a GRE header to the payload (the data that needs to be encapsulated and routed). The resulting GRE packet can be further processed and routed throughout the system with security. The GRE header may include a key field containing a four octet number which is inserted by the encapsulator. The key may be used by the receiver to authenticate the source of the packet.
The RFC2890 specification itself doesn't specify how the GRE key is allocated. In addition, a separate protocol such as MIP is generally needed to exchange the keys allocated by both ends. The GRE key assignment can be symmetric or asymmetric, but due to the limitation of the current IPsec implementation, the receiver side IPsec may not be able to negotiate a different GRE key in the other direction (asymmetric key assignment). Therefore, in one embodiment of the invention, only symmetric GRE key assignment (assigned by the initiator side) is used, and each initiator side, such as ASN-GW, may allocate GRE key in its own space. When the IPsec GRE tunnel is established between many ASN-GWs to many home SGs, the home SGs may use the source address (ASN-GW address) in addition to the GRE key field to identify a particular user session.
Because of the insertion of GRE layer between user plane and transport plane, IPsec tunnel mode can no longer be employed. IPsec in transport mode has to be used, with IP address selectors set to both endpoints of the security gateways, GRE as the “protocol” field and GRE key as the “port” fields. Using the GRE key as the “port” field is new to IPsec specifications (RFC4301, RFC4306). Thus, IPsec implementation may need to be extended to support using GRE as the “protocol” field and the 32 bit GRE key in the “port” selector fields. Each traffic selector port field is only 16 bit wide, so the 32 bit GRE key field may need to occupy both the “start port” and “end port” fields. The remote traffic selectors may be coded the same way in the case of symmetric GRE key allocation.
In step 501, MS performs network entry. During the authentication procedure, Security Gateway address is exchanged on both ends at ASN and CSN. Both ASN and CSN add a SPD entry to allow IPsec ESP transport mode protection. The selectors are set as following: “source address”=ASN-GW, “destination address”=CSN SG, “protocol”=GRE, “port”=ANY, “PFP”=1.
In step 502, MS sends DHCPDISCOVER packet to the ASN-GW. Before proceeding further, ASN-GW verifies that the client identifier in the DHCPDISCOVER message is the same as the Mobile Node's Network Access Identifier (MN_NAI) used during the network entry phase.
In step 503, ANS-GW allocates a GRE key for the MS, encapsulates the packet, finds out the destination address of the CSN SG, and sends the packet to local IPsec for processing.
In step 504, the local IPsec on ASN-GW finds the SPD entry for the GRE packet, and determines whether a corresponding SA exists. If no corresponding SA exists for the match, the IPsec will trigger an Internet Key Exchange (IKE) process to obtain an SA according to steps 505 and 506.
In step 505, the IKE first exchanges message with remote CSN SG to authenticate. The authentication is carried out based on node credential.
In step 506, during the authentication phase, an SA (CHILD_SA) is negotiated in IPsec ESP transport mode. The selectors are set as following: “protocol”=GRE, “port”=GRE key. CHILD_SA will be established successfully because both ends have the corresponding SPD entry.
In step 507, with the right SA in place, the ASN-GW sends out the GRE packet to the CSN SG with the negotiated SA.
In step 508, CSN SG decrypts the packet, verifies the traffic selector, and handovers the packet to GRE function for processing.
In step 509, the GRE function removes the GRE header, and recovers the DHCPDISCOVER packet.
In step 510, the CSN SG functions as a DHCP relay, appends a relay agent option (subscriber ID=MN_NAI) to the message, and relays it to the DHCP server.
In step 511, the DHCP server allocates an IP address for the MS, and sends DHCPOFFER message to the CSN SG. The CSN SG relays the message onto the corresponding GRE tunnel.
The reverse direction works in a similar way to the forward direction. In step 512, the CSN SG finds the right SA to protect this GRE packet and sends it to ASN-GW.
In step 513, after ASN-GW decrypts the packets and verifies the traffic selector, it relays the packet to the MS.
In step 514, one more round of DHCP exchange (DHCPREQUEST and DHCPACK) takes place, but this time the SA is already in place, so steps 505 and 506 are not repeated.
After the IP address has been configured successfully, normal traffic starts in step 515. CSN SG also adds a route entry in its local routing table for all MS traffic through the correct GRE tunnel. This will make sure that all packets destined for the MS will be routed correctly.
In accordance with this embodiment of the invention, the GRE key is allocated by the ASN-GW in its own space, and the same GRE key is used by both the ASN-GW and CSN-SG (symmetric GRE key assignment). The CSN-SG may use the source address (ASN-GW address) in addition to the GRE key field to identify a particular user session.
As discussed earlier and specified in RFC2890, the GRE header contains a 32 bit GRE key field. When used in an IPsec environment, the selector “port” fields may be used for the GRE key. As illustrated in
The method of using GRE key in accordance with this embodiment of the invention may be similar to TCP/UDP port usage, i.e., both source and destination ports identify a unique connection between two IP endpoints, with port locations swapped in forward and reverse directions. In accordance with this embodiment of the invention described herein, both source and destination GRE half keys identify a unique GRE connection between two IP endpoints and the GRE key field can be protected by IPsec in the same way as TCP/UDP ports can be protected by IPsec. However, this embodiment of the invention does not mandate how the 16 bit GRE half key is allocated within the node. The 16 bit GRE half key can be unique within the node irrespective of what destination it is communicating with, or the 16 bit GRE half key can be unique among all communications with a particular destination, or the 16 bit GRE half key can be unique among all communications with a particular destination and the GRE half key of the destination. As long as the allocation of key can unambiguously identify a unique GRE connection among all possible communications with other nodes, any allocation method will work. To differentiate this version of the GRE from earlier versions, this version of GRE can be set to 2, such that when GRE is protected by IPsec, the “port” selectors can be used to identify a particular GRE connection with unique GRE key.
In another embodiment of the invention, an IPsec protected GRE tunnel can be setup by the network to tunnel all types of user traffic between the MS and the CSN. It would allow IP broadcast/multicast traffics, Ethernet/PPP frames to be tunneled between the MS and the CSN. Additionally, it would also allow full and centralized DHCP support at the CSN, and simple configuration at the ASN.
The embodiments of the invention may also provide one or more of the following advantages: (1) Using GRE encapsulation to provide broadcast/multicast support, as well as non-IP traffic support between ASN and CSN; (2) Providing support for IP host configuration using both DHCP relay and DHCP server at CSN, without added functionality such as DHCP relay or DHCP proxy at ASN; and (3) Using IPsec ESP transport mode, as well as dynamic SA negotiation for the GRE tunnel establishment, without a separate signaling exchange protocol, such as MIP.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not of limitation. The invention is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, although the invention is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in some combination, to one or more of the other embodiments of the invention, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments.
Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as mean “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, a group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the disclosure may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated. The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.
This application claims benefit of priority under 35 U.S.C. § 119(e) to Provisional Application No. 60/981,090, entitled “IPsec GRE Tunnel in split ASN-CSN Scenario”, filed Oct. 18, 2007; and Provisional Application No. 60/984,701, entitled “IPsec GRE Tunnel in split ASN-CSN Scenario”, filed Nov. 1, 2007, each of which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60981090 | Oct 2007 | US | |
| 60984701 | Nov 2007 | US |
