On IP Radio Access Network (RAN) Security

Ram Gopal, Senthil Sengodan
Nokia Research Center
5 Wayside Road
Burlington, MA 01803, USA

Niina Karhuluoma, Roland Wolker
Nokia Networks
Keilalahdentie 4
Espoo, Finland

{ram.gopal, senthil.sengodan, niina.karhuluoma, roland.wolker}@nokia.com

With the support of the Internet Protocol (IP) by wireless devices and with the convergence of the wireless and Internet business models, there is a clear path to delivering Real-Time services, IP telephony and content delivery with dynamic service creation to mobile devices. This drives the need for a new IP transport solution for next generation cellular Radio Access Networks (RAN) that should support a multitude of IP addresses, a more secure transaction medium and various QoS levels. This paper discusses security aspects of IP based RAN.

Keywords: security, wireless, 3G, cellular, firewall, VPN

1 Introduction

A Radio Access Network (RAN) consists of physical entities that manage the radio resources and it provides the user with a mechanism to access the core network and packet switched network. Choosing IP technology in RAN raises some important issues - such as IPv6/IPv4 interworking, security in an IP RAN, use of IP mobility in IP RAN etc. - which affects many functions and layers. It is evident that when IP become a transport mechanism between physical entities in RAN, security issues are to be considered at network layer.

This paper is organized as follows. First, we describe the general overview of wireless network components associated with IP RAN from an architectural viewpoint. Security aspects are then considered separately for all type of flows in IP RAN, namely control, data and management. The next section describes different security concepts with existing approaches like IPSec, SSL/TLS, various types of firewalls, encryption standards etc. Finally, we conclude with issues involving multicasting and ongoing activities within other standardization bodies and industry consortiums.

2 IP RAN Overview

A wireless network system consists of several logical network elements, each of which has a well-defined functionality. Figure 1 shows the basic building blocks of a wireless network system - note that not all components are indicated. The figure gives an idea of the core functional entities and interfaces in such a system:

· The Radio Access Network (RAN) handles all radio related functionality.
· The Core Network (CN) is responsible for switching and routing calls, as well as for handling the data connection to external networks.
· The user’s Mobile Equipment (ME) interfaces to the network via the radio interface.

Figure 1: Wireless Network and Interfaces (High Level Block Diagram)

Figure 2 provides the logical architecture and interfaces of an IP RAN. It may be noted that this architecture is not frozen, and is still under development. The various functional entities are shown in the figure:

· Common Resource Management Server (CRMS ) provides RAN wide resource management and provides basic policy management functions for access to the cells and the radio bearer resources within RAN; handles intercell layer functions
· Operation and Administration Server (O&M Server) includes functions like performance monitoring, configuration management and fault management for RAN network and also interfaces with OSS
· Servicing Mobile Location Center (SMLC) manages the overall coordination and scheduling of resources required to perform positioning of a mobile.
· Radio Network Access Server (RNAS) : provides paging server functions, anchor point for micro mobility and radio network gateway control functions
· RAN Gateway (RNGW) is to support micro mobility, i.e. the U-plane switching during the BTS Relocation/handover.
· IP BTS implements the base station functionality of IP RAN, e.g. air interface related protocols

The different interfaces between these various functional entities, as indicated in Figure 2, may be grouped into groups as telecom interfaces control and user plane, OAM interfaces and LCS interfaces.

Figure 2: IP RAN Logical Architecture and Interfaces

3 Security Issues in IP RAN

We now examine the security requirements for the various IP RAN interfaces and possible solutions that may be used to achieve this.

Control plane

Control plane signaling may be one of two kinds - (1) that between a pair of Network Elements (NE) and (2) that between a mobile user or User Element (UE) and a NE.

The IP RAN control plane traffic between a pair of NEs needs to be integrity protected, authenticated and encrypted as well. The choice of IPSec, as a mechanism to achieve each of these security services, is relatively straightforward in this case. IPSec was designed to off-load the security responsibility to a common IP stack, instead of re-designing it at the application layer for each application. Consequently, whenever possible the usage of IPSec is recommended. Since IPSec is mandatory with IPv6, it also provides a clean migratory path in the transition from IPv4 to IPv6.

The IP RAN control plane traffic between UE and NE needs to be integrity protected, authenticated and encrypted. Although use of encryption adds to the delay, the confidentiality service that it provides makes it necessary. The specific mechanism/algorithm that is used for encryption between UE and NE needs to be carefully planned, in order to obtain a good trade-off between security and performance requirements. Mobile devices set different kind of requirements compared to NEs regarding power and memory consumption, error sensitivity and processor performance. The issue of using IPSec at the UE needs to be carefully evaluated for performance considerations. Any interactions that the use of IPSec at the UE may have on other protocols that are used at the UE - such as header compression, private addressing etc. - needs to be carefully investigated. Current proposals within 3GPP for protecting the IP RAN control plane traffic between UE and NE define mechanisms/algorithms at the application layer rather than rely on network layer security.

User plane

The user plane sets heavy requirements for encryption since confidentiality is probably the most important security service from a user perspective. The user plane traffic flowing from the UE is encrypted at the UE. It then traverses the air interface encrypted, and is decrypted by the IP RAN. User plane traffic traversing the air interface has always been encrypted, including within legacy (non IP RAN) mobile systems.

In addition to encrypting the user plane traffic across the air interface, access control by means of suitable packet filtering may also be needed. For user plane traffic flowing from the UE, the General GPRS Support Node (GGSN) is the likely entity housing the packet filtering functionality. A GGSN is a more natural choice than say IP BTS, RNGW, or SGSN since the latter entities essentially just tunnel the IP packets. In addition to simple packet filtering functionality, the GGSN may also incorporate more complex firewall functionality.

Management plane

The Operation and Management Server (OMS) has IP based interfaces to every network element. Consequently, the traffic flowing between the OMS and the NEs can be protected using IPSec. Typical security services in this case are authentication, integrity protection and encryption. In addition, non-repudiation may be needed as well.

The operator may want to use management applications from any place in the world via Internet. Typically, HTTP may be used, whereby the operator uses a HTTP client (browser) while the OMS server hosts an HTTP server. Security mechanisms provided by HTTP - such as basic and digest authentication - or SSL/TLS may be used for this purpose.

4 Applicability of Security Technology/Protocols in IP RAN

Many security technologies exist today for securing network access and data transportation, whose fundamental goal is to ensure users identity, provide data integrity and confidentiality. In this section, we describe some of the commonly used security protocols/mechanisms/algorithms that are likely candidates for use within IP RAN. A brief description of potential usage within IP RAN is also made.

4.1 IPSec Protocol Suite

The IP Security (IPSec) protocol suite consists of a set of protocol standard that may be used to provide privacy and authentication service at IP layer. Other security services such as replay prevention, message integrity and non-repudiation may be provided as well. The IPSec protocol suite comprises three main protocols - Authentication Header (AH), Encapsulating Security Payload (ESP) and the Internet Key Exchange (IKE) protocol.

AH: Authentication Header (AH) provides authenticity guarantee for packets, by attaching strong cryptographic checksum to packets at the transmitter. Such a checksum is usually computed using HMAC-SHA1 or HMAC-MD5. When the receiver receives the packer, it re-computes the checksum, and if there is a match, data origin authenticity (as well as message integrity) is assured. AH covers the whole IP datagram, from the IP header to the end of the packet.

ESP: Encapsulating Security Payload (ESP) provides confidentiality for packets, by encrypting packets with encryption algorithms. After successful decryption of the packet, the receiver can be sure that the packet was not wiretapped in the middle, if receiver and sender share a secret key, and no other party knows the key. Alternatively, public key mechanisms may be used as well.

IKE: IPSec uses cryptographic keys for authentication/integrity and encryption services. Both manual and automatic distribution of keys is supported. IKE is a mixture of following protocols :

· ISAKMP (Internet Security Association and Key Management Protocol) - provides a framework for authentication and key exchange
· OAKLEY - support a series of key exchanges
· SKEME (Secure Key Exchange Mechanism for Internet) - provides key exchange techniques to support anonymity, non-repudiation and quick key refreshment.

As mentioned in the previous section, the use of IPSec is preferred, whenever feasible within IP RAN. For instance, when IPSec is used to provide security services between NEs, IKE can be used to establish the Security Association (SA). Using this established SA, IPSec AH and/or ESP can provide security services such as message integrity, authentication, confidentiality, replay protection and non-repudiation for the user/control/management plane traffic between the appropriate entity pair.

4.2 SSL

Secured Socket Layer (SSL) provides authentication, encryption and message integrity and also cryptographic client authentication. SSL is divided in two phases - handshake and data transfer phase. Handshake takes place as follows:

1. Client sends the server version number, time, cipher suites, compression values and a random value for key generation purpose.
2. Server evaluates the parameters and chooses a cipher out of the list. It sends back the chosen cipher to the client along with the server certificate containing the server’s public key. Server supplies a random number, which is used as part of the key generation process.
3. Client verifies Server’s identity, and then extracts the random secret key and encrypts it using Server’s public key and forwards it to the Server.
4. Client and Server independently compute the Message Authentication Code (MAC).
5. Client and Server then exchange MAC of all handshake messages to each other.

SSL is the most widely used security protocol within the Internet. Most secure HTTP client-server communication uses SSL for its security. Consequently, the use of SSL within IP RAN is most suitable when an operator wishes to access the management application from a remote location using a Web browser. SSL may also substitute IPSec when the packets that are being protected are TCP packets, as against UDP packets.

4.3 Multicast Security

For unicast communication IPSec works well, whereas for multicast application IPSec is not as straightforward. Specifically, IPSec per se works transparently with unicast or multicast, but the key exchange and Security Association (SA) establishment is trickier in the case of multicast. Multicast technologies can be used within IP RAN for several purposes - one example, being paging. Consequently, multicast security is of interest within the IP RAN context.

Following are the few common security concerns in multicast:

· How to authenticate potential group members , and distribution of group keys ?
· How to revoke membership of leaving members and how to prevent joining members from access to past group communication and how to periodically refresh the group keys and other issues related to group security.

4.4 Virtual Private Network

Virtual Private Network (VPN) is a private network built on top of a public network. Hosts within the private network use encryption to talk to other hosts. VPN comes in four different areas namely Intranet, Remote Access, Extranet and Intra-company VPN. For instance, a VPN can be created between a pair of IP RAN NEs separated by an insecure network, by using IPSec ESP in tunnel mode.

4.5 Encryption and Authentication Algorithms

4.5.1 Encryption Algorithms

In order to provide confidentiality to the user data, the encryption algorithms are employed within the protocols. Most of these protocols are algorithm independent, and they negotiate the type of algorithm and encryption method as part of initial security association establishment. Thus, if one of the algorithms gets broken there is no change needed to the protocol. Encryption algorithms are of one of two kinds - block ciphers and stream ciphers. Block ciphers, which include e.g. DES, 3-DES, Blowfish, Rijndael (AES), RC2 and RC5, operate on input blocks of certain sizes to produce ciphertext (encrypted text) of the same size.

Rijndael is similar to Kasumi (owned by 3GPP), which is widely used in telecommunication networks. Rijndael is nowadays used as an example algorithm in 3GPP. The size of the block depends on the encryption algorithm (i.e., cipher) used. Block size of 64, 128, 196, 256 bits etc. is typical.

Data Encryption Standard

The Data Encryption Standard (DES) is the most widely used encryption algorithm to date and was standardized in the United States by the National Institute of Standards and Technology (NIST). DES is a symmetric block cipher, which implies that the same key is used for encryption and decryption. Generally speaking, symmetric ciphers are considerably faster than asymmetric ciphers (which use a different key for encryption and decryption), and hence are widely used for media stream and other bulk encryption.

DES takes a block input of 64-bit length, and using a 56-bit key, outputs a block of 64-bits. The key length specified is actually 64-bits, although every eighth bit is used for parity purposes, thereby making the actual key length 56-bits. Because DES has shorter key length currently most of the system uses “super encryption” namely 3DES. It has been proven that double DES provides same security as of single DES (when meet-in-the middle attack is made).

The most popular 3DES is Encryption-Decryption-Encryption (EDE) mode, i.e., to first encrypt using Key1(k1) then decrypt with Key 2(k2) and finally encrypt with Key 3(k3). The main advantage is that it can easily interoperate with existing systems where single DES is supported (by choosing k1=k2= k3).

Advanced Encryption Standard

AES is a successor to DES. NIST has chosen the Rijndael block cipher as its AES in October 2000. AES is a symmetric block cipher that can operate on blocks of size 128, 196 or 256-bits. Independent of the block size, the key size may also be either 128, 196 or 256-bits long.

RSA Algorithm

Rivest, Shamir, Adleman (RSA) algorithm, which has been named after its three inventors, is the most popular asymmetric cipher. Asymmetric ciphers, also known as public key algorithms, use the public key of the recipient for encryption, and the recipient uses his private key for decryption. The patent for the RSA algorithm expired in September 2000, and it is likely to see an increase in use because of this. Since RSA is a public key algorithm, it is considerably slower than symmetric algorithms like DES, 3-DES etc. Consequently, it is not used for media stream encryption, but is usually used for operations such as key exchange. The algorithm is straightforward, and is as follows:

C = Pe mod n, is the encryption algorithm
P = Cd mod n, is the decryption algorithm

where P is the binary representation of the plaintext, and C is the corresponding ciphertext. The private key is the 2-tuple (d,n), and the public key is the 2-tuple (e,n). The strength of the algorithm lies in the difficulty in factoring a product of two large prime numbers.

4.5.2 Hash and Signature Algorithms

One-way hash functions (commonly referred to simply as hash functions) are the core of authentication and integrity services. A hash function takes an input of arbitrary size, and creates an output of fixed size called the message digest. The one-way nature of hash functions implies that it is extremely unlikely to determine the input, given the output of the hash function. Hash functions may be used in several ways to provide authentication/integrity services. For instance, in conjunction with a secret key, they are used to generate Message Authentication Codes (MAC). Two popular mechanisms exist for this purpose - keyed MAC and Hashed MAC (HMAC). When used in conjunction with a private key, they are used to generate digital signatures. Two popular digital signature algorithms are the RSA algorithm and the Digital Signature Algorithm (DSA).

When the output of a hash function along with a user’s private key is input to a suitable signing algorithm, a digital signature is obtained. This digital signature may be used for authentication, integrity and non-repudiation purposes. Authentication is provided because only the holder of the private key could have produced the digital signature. Non-repudiation is provided for a similar reason, and because the recipient does not possess the private key. Message integrity is provided because any alteration of the message in transit would result in a mismatch between the included and computed message digest at the receiver.

Message Digest 5 (MD5)

Message Digest 5 (MD5) is probably the most widely used hash function. MD5 takes an input of arbitrary size, and produces a message digest of 128-bits. The MD5 algorithm internally operates with inputs of size 512 bits, but the algorithm itself (or this may also be viewed as a wrapper to the core algorithm) has functionality to break an arbitrary input into 512-bit blocks. Padding and length indication functionality is also included within the algorithm specification. Recently, certain security attacks (brute force and other forms of cryptanalysis) have been mounted successfully upon the MD5 algorithm, due to which its use in certain applications is being replaced by the SHA-1 hash function.

Secure Hash Algorithm 1 (SHA-1)

The Secure Hash Algorithm 1 (SHA-1) was standardized by the National Institute of Standards and Technology (NIST) in 1995. SHA-1 takes inputs of arbitrary length and creates a message digest of 160 bits. As with MD5, SHA-1 internally takes inputs of block 512-bits. As with MD5, SHA-1 itself has functionality to break an arbitrary sized input to blocks of 512-bits, to append any padding and length fields etc. Compared to MD5, SHA-1 is more resistant to brute-force and other forms of cryptanalysis.

RSA and DSA Algorithm

The RSA algorithm may be used to compute a digital signature. The hash of the original message is signed using the sender’s RSA private key to create the digital signature. The digital signature is concatenated with the original message and sent to the recipient. The recipient re-computes the hash from the message, and compares this with the output that is obtained when the digital signature is processed using the sender’s RSA public key. If these two match, then the integrity of the message is intact.

The Digital Signature Algorithm (DSA) was standardized by NIST the key difference between DSS and RSA digital signatures is how the signature verification process takes place. With RSA, one recovers the message digest from the signature and compares it to the computed message digest. DSS requires to perform a computation based on the message digest and the signature returns YES/NO answer. There is no way to recover the sender’s calculated message digest using DSS. This has led to confusion in converting RSA based protocols and implementation to DSS and hence problem of interoperability/migration.

5 Firewalls in IP RAN

The term firewall is sometimes used loosely, and needs a more precise definition for our purposes. Generally, firewall is one that is responsible for determining access control, i.e., whether a packet is allowed to traverse the firewall or not. We broadly classify the means for such access control into two kinds:

· No information is directly sent to the firewall, and the firewall merely inspects packets that pass through it. This is the case with packet filters.
· Some information (e.g., authenticating information) is sent directly to the firewall, which facilitates packet traversal through the firewall. This is the case with SOCKS and IPSec AH tunnel mode type of firewalls.

Firewall generally consists of one or more of three functional components - packet filters, circuit gateways (such as SOCKS) and application level gateways (ALG, also known as proxies).

Packet filters

Packet filters use a set of selectors, which are usually fields in the header of the traversing packet along with possibly some state stored at the firewall. Their main function is to determine whether the packet may be allowed to pass or not. One may classify packet filters into two broad classes - static packet filters and stateful packet filters. Static packet filters have a static configuration based on which packets are, on an individual packet-by-packet basis, either allowed or denied access through the filter. Stateful packet filters, on the other hand, maintain state about a flow and utilize this state along with the packet headers to determine packet access/denial.

Circuit Gateways (SOCKS)

With circuit gateway type firewalls, a TCP connection (i.e., circuit) is established between the client entity within the domain of the circuit gateway and the circuit gateway. Client application sends a request to the SOCKS server with the destination server IP address. Instead of directly starting a session with the destination server, the client initiates a session to the SOCKS server on the firewall. The SOCKS server then validates that the source address and user ID are permitted to establish onward connection into the unsecured network, and then creates the second session. Compared to packet filters, SOCKS is more complex, but also more secure. SOCKS may also be suitable for certain UDP datagram traversal, where the UDP datagram is sent within the virtual circuit that is established. One of the disadvantages of SOCKS is that the client needs to be aware of the presence and location (IP address) of the SOCKS server. Although some mechanisms for automatic discovery of such gateways exist, none is mature.

Application Level Gateways (ALG) or Proxies

Application Level Gateways (ALGs), also known as proxies, function at the application layer. This is in contrast to packet filters and circuit-level gateways that operate at lower layers of the protocol stack. A proxy is, thus, specific to a particular application, while packet filters and circuit-level gateways are more generic in nature.

Some of the advantages of proxies are:

· They are generally more secure than packet filters
· Compared to packet filters and circuit gateways, in the presence of Network Address Translators (NAT), only a proxy based solution works when the transport address is also carried in the application fields.

Some of the disadvantages of proxies are:

· They create a process for each connection that they manage, and hence suffer from a scalability problem.
· They are slow compared to packet filters.
· In the presence of end-to-end encryption, using say IPSec or TLS, a proxy is rendered ineffective. This is because all application layer fields are encrypted and hence unavailable to the proxy, which may not be able to change required fields.

Use of Firewalls in IP RAN

Firewall functionality needs to be incorporated into those IP RAN entities, where access control of flows needs to occur. This occurs at trust boundaries, which are boundaries where a flow takes place between two entities that don’t necessarily trust each other. Looking at the IP RAN architecture in Figure 2, the most likely scenario of deployment is one in which an entire IP RAN is owned and operated by a single operator. In other words, all the entities within the IP RAN may trust one another. A “trusted entity” is different from a “secure domain”. It is possible that several entities may trust one another, but that the interfaces between these trusted entities are insecure. In other words, there may be untrusted routers between these trusted entities, and the data traversing these trusted entities may have to flow through these untrusted routers. This is a case where we have trusted entities that communicate through an insecure domain.
Figure 3 illustrates the concept of trusted entities within an insecure domain. The Untrusted Routers (UR) are shown in the figure at those interfaces where their presence is possible/likely. It is seen that the interfaces within the IP BTS (e.g., BTS-Cell control function, Cell Bearer gateway, user radio gateway etc.) are within a secure domain, i.e., they do not traverse insecure routers, and hence, no UR is seen on those interfaces within the last mile.

Figure 3: Depicting Untrusted Routers (UR) at interfaces of IP RAN Architecture

With this likely deployment scenario of a single operator owning the entire IP RAN, but where untrusted routers may be present at several interfaces, an attacker may be able to monitor, modify or inject messages by accessing any of these untrusted routers. Access control functionality at the edges of the IP RAN would be irrelevant if an attacker were able to access an UR that is present within the IP RAN, and inject messages that would have been denied access a the edges of the IP RAN.

In spite of this, there are some scenarios in which firewalls are useful within IP RANs:

1. If the bulk of the attacks come from outside the IP RAN, rather than from the Untrusted Routers (UR) within the IP RAN, then the use of firewalls at the edges of the IP RAN would be useful. This assumption that the bulk of the attacks comes from outside the IP RAN, is also probably a reasonable one.
2. One of the major functions of firewalls is policy based access control. In other words, certain (class of) users may be allowed to access certain services, while certain others may not. While the profile is stored in the HSS (Home Subscriber Server), based on this profile, a firewall at the edges of the IP RAN may be configured to provide access control. Such access control is most optimal when it is closest to the source. For mobile originated calls, this would then be the BTS, while for mobile terminated calls this would be the RNAS/RNGW. The interactions with Radio Access Control need further investigation in this regard.

Due to the usefulness of the above two scenarios, it may be worthwhile to introduce some firewall functionality at the RNAS/RNGW and BTS. Figure 4 shows the firewall placement at these entities.

Figure 4: Illustrating Firewall (FW) being present at BTS, RNGW, and RNAS

Depending on the policy that needs to be enforced within an IP RAN, various rules for packet access may be configured at the RNGW/RNAS or BTS. Since no application level processing is done (or needs to be done) at the RNGW or RNAS, the need for a proxy does not arise. For packets flowing from the CN into the RAN, a static or stateful packet filter may be most suitable. For packets flowing out of the RAN into the CN, either packet filters or SOCKS may be appropriate.

Firewalls need to be placed such that packet traversal cannot circumvent the firewall. In the case of IP RANs, since the interfaces at the edge of the IP RAN are clearly defined, the packets will traverse the interface, and hence will go through the firewall. It is unlikely that multiple RNGW or RNAS will be present for load sharing purposes. In case there are multiple RNGWs, then the firewall needs to be present at each RNGW and the firewall configuration needs to be synchronized between the various RNGWs. Figure 4 shows the positioning of firewalls at the edge of the IP RAN.

6 Standardization Bodies

IETF

The Internet Engineering Task Force (IETF) (www.ietf.org) is an open organization in which any individual may participate. The IETF is organized into nine areas - Application, General, Internet, Operations & Management, Routing, Sub IP, Security, Transport, User Services - each of which has several working groups (WGs). Several aspects pertinent to IP RANs are being standardized within various WGs of the IETF. For instance, Multicast Security related issues are being carried out in msec working group. The main aim of this group is to come up with a solution where only authorized users will be able to access and join the group, as well as to authenticate the source.

MWIF

Mobile Wireless Internet Forum (MWIF) is working towards a single mobile wireless and internet architecture that is independent of the access technology. They have different work groups, the IP RAN group considers how IP networks and protocols can be applied as a transport option for Radio Access Networks (RAN) for 3rd Generation mobile systems. They are considering IP only in RAN internal interfaces and keeping the existing interfaces to core network and radio control protocols the same. From the security viewpoint they are trying to define issues related to the placement of firewalls, authentication and authorization mechanisms, and security threats.

3GPP

3G Partnership project (3GPP) aims to provide globally applicable Technical Specifications for a 3rd Generation Mobile System based on the evolved GSM core network, and the Universal Terrestrial Radio Access (UTRA), to be transposed by relevant standardization bodies (Organizational Partners) into appropriate deliverables (e.g., standards). 3GPP has different project coordinated work groups namely RAN, Core Network, Terminals, System and Services. The security related aspects are being worked under Systems and Services group and are defining a set of standards encompassing Security Principles, requirements, architecture which are applicable to wireless mobile system.

7 Conclusion

In this paper, we discussed several aspects dealing with security in IP RANs. Based on an IP RAN architecture, we discussed issues such as the applicability of relevant security protocols, and the placement of firewalls. Significant work is currently ongoing within standardization bodies - specifically IETF, 3GPP, and MWIF - in this regard.

8 References

R. Rivest, “MD5 Digest Algorithm,” RFC-1321, April 1992.
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 (http://csrc.nist.gov/fips/fip180-1.ps)
NIST, FIPS PUB 81: DES Modes of Operation, December 1980 http://www.itl.nist.gov/div897/pubs/fip81.htm
TS 101 323 v1.2.3, “Interoperable security profiles,” ETSI Specification, July 1999.
Bruce Schneier, “Applied Cryptography”, 2nd Edition, John Wiley & Sons.
www.ietf.org
T. Dierks, C. Allen, “The TLS Protocol Version 1.0,” Internet Draft, Work in Progress, November 1998.
S. Kent, R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401, November 1998.
R. Thayer, N. Doraswamy, R. Glenn, “IP Security Document Roadmap,” RFC 2411, November 1998.
Stephen Kent, Randall Atkinson, “IP Authentication Header,” RFC2402.
Stephen Kent, Randall Atkinson, “IP Encapsulating Security Payload,” RFC 2406.
Harri Holma and Antti Toskala , WCDMA for UMTS, John Wiley & Sons
Ron Rivest, “A Description of the RC2® Encryption Algorithm,” RFC-2268, March 1998.
H. Krawczyk, M. Bellare, R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC-2104, February 1997.
IP in the RAN as a Transport Option in 3rd Generation Mobile Systems Technical Report MTR-006 , Release v1.0.0 (8th December 2000) - http://www.mwif.org
3GPP TSG SA WG 3 Security, TS 33.102. “Security Architecture (Release 1999). v3.5.0,” July, 2000. - http://www.3gpp.org