Use of RSIP within GPRS Networks

Senthil Sengodan, Raj Bansal

Nokia Research Center

5 Wayside Road

Burlington, MA 01803, USA

{senthil.sengodan,raj.bansal}@nokia.com

Abstract

Realm Specific IP (RSIP) is a mechanism that has been proposed within the Internet Engineering Task Force (IETF) in order to tackle the limited IPv4 address space, while overcoming the drawbacks of Network Address Translators (NAT). In this paper, we investigate the application of RSIP to GSM Packet Radio System (GPRS) networks.

Key words: RSIP, GPRS, end-to-end security

1 Introduction

The lack of sufficient IPv4 address space has been dealt with using one of two approaches: (1) traditionally using Network Address Translators (NATs), and (2) more recently using Realm Specific IP (RSIP), as proposed within the IETF. One of the main advantages of using RSIP over NAT is that end-to-end security can be preserved. At the same time, work is ongoing within the cellular network industry to handle packet data within cellular networks. The GSM Packet Radio System (GPRS) is an enhancement to the GSM network to handle packet data. In a GPRS network, an IP address (called a PDP address) is assigned to a mobile by the General GPRS Support Node (GGSN). In addition, the network between the Serving GPRS Support Node (SGSN) and the GGSN is also an IP network. Hence, the issue of IP address assignment and the impact of private addressing is critical to GPRS networks as well.

In this paper, we discuss the applicability of RSIP to GPRS networks. Specifically, we investigate two different approaches:

  1. Use of the RSIP protocol within GPRS networks. We describe the GPRS functional entities where the RSIP client and the RSIP server need to be implemented. Scenarios of operation, both in the presence of session mobility and without mobility, are considered.
  2. Use of the existing GPRS address assignment mechanism (i.e., PDP context activation procedure) with minor modifications, so that a functionality similar to RSIP is achieved. Specifically, we propose the use of the Access Point Name (APN) field within the Activate PDP Context Request message to convey to the GGSN, whether a private or public IP address needs to be assigned to the MS.

With the suitable use of RSIP within GPRS networks, end-to-end security can be preserved for GPRS networks as well.

2 Overview of NAT and RSIP

IPv4 is the version of IP (Internet Protocol) that is deployed in today’s networks – both enterprise networks as well as the public Internet. One of the limitations of IPv4 is its limited address space. In order to conserve addresses, enterprises and other administrative domains have resorted to the use of private addresses. Private addresses are those where the IP address falls in the range: [10.0.0.0 – 10.255.255.255], or [172.16.0.0. – 172.31.255.255], or [192.168.0.0. – 192.168.255.255]. Private addresses that are assigned by an administrative entity within an administrative domain (AD) have relevance only within the AD, and such addresses must not be visible outside the AD. The advantage of this approach is that different ADs may assign the same private IP address to hosts within their respective ADs, without any concern of conflict. When a host that is assigned a private address wishes to communicate with a host that is outside its AD, the use of a Network Address Translator (NAT) is warranted. A NAT transforms the private IP address (and possibly certain other fields) to a public IP address, prior to sending the IP datagram outside its domain.

This approach of using private addresses within ADs, and the use of NATs at the edges of the ADs, has been widely adopted and deployed within enterprises. However, there are two major drawbacks that such an approach faces:

  1. Such an approach breaks the end-to-end security model, and
  2. Certain applications cannot work in the presence of a NAT, unless remedial measures - such as the inclusion of an application gateway (proxy) - are taken.

Figure 1 illustrates a typical scenario involving NATs.

Figure 1: Illustrating NATs

 

In order to overcome the disadvantages that face NATs, a mechanism termed Realm Specific IP (RSIP). RSIP has been proposed within the IETF and has gained significant support. In RSIP, a host (RSIP client) that needs to be assigned an IP address indicates to the server (RSIP server) that is responsible for assigning IP address, whether the IP address is needed to communicate with hosts within the AD or outside the AD. Based on this information, the RSIP server assigns either a private IP address or a public IP address to the host. It is seen that when a private IP address is assigned to a host, the IP datagram does not leave the AD. When an IP datagram does leave an AD, the address that is assigned to the transmitting host is a public IP address. Thus, the RSIP protocol makes the use of NATs unnecessary, thereby avoiding the drawbacks involving NATs. Figure 2 illustrates the usage of RSIP.

To summarize the discussion thus far, there are generally two broad approaches taken regarding the assignment of IP addresses to hosts within an AD:

  1. Assign private addresses to hosts, and when the host needs to communicate with another host that is outside the private domain, make use of Network Address Translators (NATs).
  2. Determine whether the host needs to communicate with another host within the same AD or outside the AD, prior to assigning an IP address to it. Assign a private address to a host when it communicates with another host within the same AD. Otherwise, assign a public address to the host. The protocol between the host and the address assigning server is the RSIP protocol.

 

Figure 2: Illustrating RSIP

 

 

 

 

3 IP Address Assignment in GPRS

In the case of GPRS networks, a Mobile Station (MS) is assigned an IP address by the General GPRS Support Node (GGSN). Today, such an IP address is an IPv4 address. The protocol that is used for address assignment is specific to GPRS networks, and is termed PDP Context Activation. PDP (Packet Data Protocol) is a term that is used within GPRS networks to refer to IP addresses, X.25 addresses etc. Since we are concerned about IPv4 addresses, the term PDP is synonymous with IPv4 address for this discussion. Figure 3 shows a generic GPRS protocol stack, where the IP address on the MS may be seen. Figure 4 illustrates the PDP context activation procedure within GPRS networks. An Administrative Domain (AD) within GPRS networks (and cellular networks in general) is termed a PLMN (Public Land Mobile Network).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 3: GPRS Protocol Stack

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 4: PDP Context Activation

 

 

 

 

4 Proposed Approach

When IPv4 addresses are assigned to MSs in a GPRS network, one needs to be concerned about conserving such addresses, while maintaining end-to-end security and application friendliness at the same time. To date, we know of no clear mechanism/procedure for IPv4 address assignment to a MS by a GGSN within GPRS networks, which has the benefits of conserving IPv4 addresses while at the same time maintaining end-to-end security and being application friendly. In order to achieve this, we propose two methods:

  1. Use of the RSIP protocol within GPRS networks. We describe the GPRS functional entities where the RSIP client and the RSIP server need to be implemented.
  2. Use of the existing GPRS address assignment mechanism (i.e., PDP context activation procedure) with minor modifications, so that a functionality similar to RSIP is achieved. Specifically, we propose the use of the Access Point Name (APN) field within the Activate PDP Context Request message to convey to the GGSN, whether a private or public IP address needs to be assigned to the MS.

Proposal 1

Figure 5 shows the location of the RSIP client and RSIP server functionalities within the GPRS functional elements, so that the RSIP protocol may be used for IPv4 address assignment. As seen in the figure, RSIP client functionality is needed at SGSNs and GGSNs, but is not needed either at the MS or at BGs. Similarly, RSIP server functionality is needed at GGSNs and BGs, but is not needed either at the MS or at SGSNs.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 5: RSIP Client and Server Locations

Proposal 2

As seen in Figure 4, during PDP context activation (which is the procedure for IPv4 address assignment for the MS), one of the fields in the Activate PDP Context Request message sent from the MS to the SGSN is the Access Point Name (APN) field. The APN field is used by the MS to indicate a preference of access points or networks for data transfer. The SGSN uses the APN field to choose a suitable GGSN to send the Create PDP Context Request message. The Create PDP Context Request message sent from the SGSN to the GGSN transparently contains the APN field that was used within the Activate PDP Context Request message sent from the MS to the SGSN.

This is illustrated in Figure 6, which shows three GGSNs connected to the Core Network associated with an SGSN. Depending on the value of the APN field in the Activate PDP Context Request message sent from the MS to the SGSN, the SGSN chooses a suitable GGSN (one of GGSN1, GGSN2 or GGSN3). The Create PDP Context Request message is then sent from the SGSN to the chosen GGSN.

To summarize, Proposal 2 in this document is that the MS indicates its preference of a private or a public address known to the GGSN via the APN field. The GGSN uses this APN field to assign either a private address or a public address to the MS.

 

 

 

 

 

 

 

 

 

 

 

 

Figure 6: Illustrating the use of APN to choose GGSNs

 

5 Mobility Issues

The case of terminal mobility needs to be investigated further, although some description has been provided below. The issue here is that when a session is in progress, mobility of one/both terminals could result in the terminals moving in/out of the other party’s domain. For instance, when the session is first established, both terminals could be in the same domain, thereby resulting in RSIP server assigning a private IPv4 address. However, due to terminal mobility, one/both communicating endpoints could move out of the private domain, which implies that the original assigned private IPv4 address will not suffice.

Scenarios without Mobility

Consider the case of the outer IP header between an SGSN and GGSN of the same PLMN, for instance, that in PLMN A of Figure 5. In this case, private addresses can be used always, and hence, for this scenario, we do not need RSIP client or server functionality within any GPRS element.

Consider the case of the outer IP header between an SGSN and GGSN, where the SGSN and GGSN belong to different PLMNs. For instance, consider the case in Figure 5, where the SGSN belongs to PLMN A while the GGSN belongs to PLMN B. In this case, two pairs of RSIP client server functionality come into play: (1) RSIP client at SGSN A and RSIP server at BG A, and (2) RSIP client at GGSN B and RSIP server at BG B.

For the case of the inner IP header, the RSIP client is at the SGSN while the RSIP server is at the GGSN. This is irrespective of the case whether the GGSN and the SGSN are within the same PLMN or in different PLMNs.

Scenarios with Mobility

Consider the case where a MS that is associated with SGSN B moves to a different location that is associated with SGSN A. Let the GGSN be GGSN B, and let us discuss the outer IP header. In this case, two pairs of RSIP client-server functionality come into play: (1) RSIP client at SGSN A and RSIP server at BG A, and (2) RSIP client at GGSN B and RSIP server at BG B. This is identical to the case without mobility since the outer IP header is being discussed.

For this same scenario, let us now discuss the inner IP header. In this case, three pairs of RSIP client/server functionalities come into play: (1) RSIP client at SGSN B and RSIP server at GGSN B (2) RSIP client at GGSN B and RSIP server at BG B, and (3) RSIP client at SGSN A and RSIP server at GGSN A.

Hence, we see that for all the scenarios discussed, the presence of RSIP client and server functionalities as illustrated in Figure 5 serves the purpose.

6 Conclusion

In this paper, we described the applicability of RSIP within GPRS networks. Since GPRS networks predominantly use IPv4 addresses today, one either needs to rely on a NAT or RSIP based solution, in order to conserve IPv4 addresses. Since the NAT based solution breaks the end-to-end security model, the use of an RSIP based solution is preferred. Specifically, we proposed two solutions: (1) the direct use of the RSIP protocol between relevant GPRS functional entities, and (2) the incorporation of RSIP-like functionality using existing GPRS messages.

References

1.

M. Borella, J. Lo, (Editors) "Realm Specific IP: Framework," Internet-Draft, work in progress, July 2000.

2.

M. Borella, D. Grabelsky, "Realm Specific IP: Protocol Specification," Internet-Draft, work in progress, July 2000.

3.

P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations," RFC 2663, August 1999.

4.

EN 301 344, "General Packet Radio Service (GPRS): Service description," ETSI Specification, July 1998.

5.

S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol," RFC-2401, IETF, Nov. 1998.