. 50
( 132 .)


• Scenario 1 “ using AH: the host on a secure LAN digitally signs the packet to authen-
ticate it. The receiving host will check the signature and either accept or reject the
packet. If the packet has been altered during its journey, then the digital signature
will not concur with the packet contents. The contents are not encrypted as the packet
travels across the Internet.
• Scenario 2 “ using ESP: the host on a secure LAN may encrypt the packet for its jour-
ney across the Internet. Anybody that happens to listening to packets using a network
analyser will be able to receive the packet but will not be able to decipher its contents.
The receiver, however, will have the correct key to unlock the encrypted data.

In IPv4, the transport mode security protocol header appears immediately after the IP
header and any options, but before any higher-layer protocols (e.g. TCP or UDP), as
shown in Figure 5.48.
In IPv6, the security protocol header appears after the standard IP header and extensions,
with the exception of the destination options extension, which may appear before or after

Before applying AH or ESP

IP Header with Options TCP Header Data Extra fields
required for ESP

After applying AH or ESP

IP Header with Options AH or ESP TCP Header Data ESP trailer ESP auth.

Figure 5.48 Transport mode IPSec protocol header (IPv4)

Before applying AH or ESP

IP Header Extensions TCP Header Data

Extra fields required
for ESP
After applying AH or ESP

IP Header Extensions AH or ESP options TCP Header Data ESP trailer ESP auth.

Hop by hop, Routing, Fragmentation

Figure 5.49 Inclusion of IPSec header (IPv6)

the security protocol header (Figure 5.49). In the case of AH, the protection includes
higher-layer protocols and selected portions of the IP header, selected portions of extension
headers and selected options (contained in the IPv4 header, IPv6 hop-by-hop extension
header, or IPv6 destination extension headers). In the case of ESP, a transport mode SA
provides security services only for higher-layer protocols, not for the IP header or any
extension headers preceding the ESP header.

Tunnel mode (VPN mode)
A tunnel mode security association can be between two host machines, two gateways or a
gateway and a host, as shown in Figure 5.50. Here the secure gateway receives a packet
from the secure LAN. This packet is then encapsulated within another IP packet to be sent
to the destination. The destination in this example happens to be another secure gateway
(it could have been the receiving host). This device will decapsulate the packet for its

IP Hdr IP Hdr AH or ESP Data
Secure Data

IP Hdr Data IP Hdr Data

Secure Gateway Secure Gateway

Host Station Host Station
Local Area Network Local Area Network

Figure 5.50 Tunnel mode

onward journey. During its time on the insecure Internet all details about the original
packet will remain secure. If AH is used this means that the receiver will be able to
check for any inconsistencies, and if ESP is used then this could mean (if encryption
was selected) that it was encrypted throughout this leg of the journey. A tunnel provides
a VPN service between two networks (if secure gateways encrypt the data). If IPSec
encryption is executed at the host this can be used to provide secure remote access via
the VPN to the network for a remote client.
Whenever either end of a security association is a security gateway, the SA must be in
tunnel mode and not transport mode. An SA between two security gateways is therefore
always a tunnel mode, as is an SA between a host and a security gateway.
For a tunnel-mode SA, there are two IP headers:

• an outer IP header that speci¬es the IPSec processing destination;
• an inner IP header that speci¬es the ultimate destination for the packet.

The security protocol header is placed after the outer IP header and before the inner
IP header. If AH is employed in the tunnel mode, portions of the outer IP header are
provided protection, in addition to the entire tunnelled IP packet (i.e. all of the inner IP
header is protected, as are the higher-layer protocols), as shown in Figure 5.51.
If ESP is employed, protection is only supplied to the tunnelled packet, not to the outer
header, as shown in Figure 5.52. Establishing security associations
The setting up of a security association between two entities on the network is not de¬ned
within IPSec and can be performed in a number of different ways. Essentially there are
two types of establishment:

New IP Header AH Hdr Original IP Header TCP Header Data

Full Authentication Coverage
Part Authentication

Figure 5.51 AH tunnelled IP packet

New IP Header ESP Hdr Original IP Header TCP Hdr Data ESP auth.

Encryption Coverage
Authentication Coverage

Figure 5.52 ESP tunnelled IP packet

• Manual: where both machines are con¬gured ˜by hand™, including the key distribution,
encryption and authentication algorithms.
• Dynamic: the key exchange and algorithm negotiation is carried out using a key
exchange protocol.

The ¬rst option is realistic in cases where there are not too many different secure
connections that are required to be made, the set-up is relatively static and travel between
sites feasible. For all other cases some form of key exchange protocol is required.

5.9.3 Internet key exchange (IKE)
This mechanism speci¬es a particular public-key-based approach called the Internet key
exchange (IKE), which is de¬ned in RFC 2409, for automatic key management. However,
other automated key distribution techniques such as Kerberos and SKIP may be used. IKE
is the amalgamation of the IP security association key management protocol (ISAKMP),
de¬ned under RFC 2408, and Oakley (RFC 2412), a key determination protocol. IKE
manages the key exchanges between the sender and recipient through the Dif¬e“Hellman
key exchange protocol.
Authentication can be done through pre-shared secrets or digital certi¬cates issued
through a certi¬cate authority (CA). Using this system it is possible to control the level
of trust since there are a number of algorithms that can be used within IPSec. Thus for
example if a high level of security is required then Triple DES could be used with a new
key being negotiated every 5 minutes.

5.9.4 Security and GPRS
GPRS provides IP transport as an end-to-end solution, that is, all the way from a mobile
device to another IP host on the Internet or private IP network. This means that the IP
security services such as authentication and privacy can be provided end-to-end using
mechanisms such as encryption and digital signatures. This is in fact the preferred model
for securing transmissions, encrypting them as they leave the original source host and
only decrypting them on arrival at their ¬nal destination. GPRS does in fact provide
encryption for transmissions as they are carried from the mobile device to the SGSN via
the LLC protocol. However, this cannot be consider secure as the data is transported in
plain text across the GPRS core network and on to the Internet. Figure 5.53 shows how
IPSec could be used in tunnel mode to provide VPN services to a mobile user. The user
data in this case is encrypted all the way from the mobile device as far as the enterprise
¬rewall. This con¬guration will also allow external users to be authenticated, blocking
out unauthorized access to the enterprise network. Note that the operator™s network is not
involved in providing the security but merely a service providing data transport.
For users requiring secure access to a server then it is likely that TLS end-to-end will
be the preferred solution. In this case the server usually has to provide authentication but

IPSec ESP tunnel

UTRAN Packet Core
with IPSec IP
software Backbone
RNC Router Firewall
with IPSec

Enterprise Network

Figure 5.53 GRPS VPN solution

TLS Session

UTRAN Packet Core

with TLS IP
software Backbone
SGSN GGSN Web Server

Figure 5.54 TLS with GPRS

not usually the client. After keys are exchanged all the traf¬c is protected using strong
encryption (usually RC4). This con¬guration is shown in Figure 5.54.


The TCP/IP protocol suite was originally designed over 25 years ago to connect the US
government™s vast array of computers. Today, as IP version 4, it is used as the Internet
protocol to connect thousands of routers and millions of users around the world. This
explosive growth was never expected or anticipated. The protocol has been constantly
evolving with new protocols being introduced through the IETF™s RFCs. For example,
in the case of the UDP protocol, it is now used to transfer speech and video. However,
although additional protocols have been introduced, the core protocols have not changed
a great deal since their inception, as this would have a major impact on the thousands of
routers and millions of users. One of the main reasons for the change to IP version 6, or
IP next generation, as it was also known, is the insuf¬cient number of available addresses
in IP version 4. IP version 4 has a 4-byte addressing range giving a combination of
232 = 4 294 967 296 unique addresses. On the surface this seems like plenty of addresses,
but the address classi¬cations are very inef¬cient. Organizations which require more than
the 256 addresses available with class C have historically been given a class B address,
which allows them to have 65 536 addresses, clearly far too many. Recent stop gaps such
as DHCP and CIDR have allowed IP version 4 to continue for some time but this is not

seen as a permanent solution but rather a way of delaying the inevitable. While not part
of the UMTS speci¬cation, at the application layer, it is expected that devices should be
able to support both IPv4 and IPv6.
The key capabilities of IPv6, in comparison to IPv4, are:

• Expanded addressing and routing: increasing the IP address ¬eld from 32 to 128 bits
in length and incorporation of address hierarchy.
• Simpli¬ed header format: eliminating or making optional some of the IPv4 header
¬elds to reduce the packet handling overhead. Even with the addresses, which are four
times as long, the IPv6 header is only 40 octets in length, compared with 20 octets for
IPv4. An example is fragmentation, which has been removed from the core header and
placed in an extension header.
• Extension headers and options: IPv6 options are placed in separate headers located
after the core IPv6 header information, such that processing at every intermediate stop
between source and destination may not be required.
• Authentication and privacy: required support in all implementations of IPv6 to authen-
ticate the sender of a packet and to encrypt the contents of that packet, as required.
• Autorecon¬guration: support from node address assignments up to the use of DHCP.
• Incremental upgrade: allowing existing IPv4 hosts to be upgraded at any time without


. 50
( 132 .)