Tài liệu IP security pdf

NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 1
IP security
Madalina Baltatu Antonio Lioy
Dip. Automatica e Informatica
Politecnico di Torino
Torino, Italy
Abstract—This paper presents the network level security
services currently available for the Internet infrastructure.
Since IPsec is likely to become the largely accepted standard
as far as IP level security is concerned, the paper describes
the IPsec architecture including its defined security formats
and the related key management procedures. Finally, com-
mon IPsec applications are presented and the future direc-
tions are outlined.
Keywords— network level security, authentication, in-
tegrity, confidentiality, anti-replay
I. INTRODUCTION
TCP/IP networks are plagued with security problems
because they have been designed to work in a friendly
environment, with physically secure connections. When
these assumptions are no more valid - as it is nowadays -
the many security weaknesses of TCP/IP become manifest
and can be easily exploited. In general, IP communications
are exposed to several types of attack:
• packet sniffing: due to network topology, IP packets sent
from a source to a specific destination can also be read by
other nodes that can then get hold of the payload, which
may contain passwords or other private information;
• IP spoofing: IP addresses can be very easily spoofed
both to attack those services whose authentication is based
on the sender’s address (as the rlogin service or several

WWW servers) and to supply wrong information to sub-
vert the logical organization of the network (for example,
by forging false ICMP messages of the type ”destination
unreachable” or ”redirect”);
• connection hijacking: whole IP packets can be forged to
appear as legal packets coming from one of the two com-
municating parties, the goal of the attack being to insert
wrong data in an existing channel.
Effective solutions to these and other attacks are not al-
ways available. When countermeasures do exist, they are
usually placed at the application level. As a consequence,
solutions are not always interoperable. Moreover, several
functions are duplicated inside different applications.
The IP Security architecture (IPsec) [1] defines basic se-
curity mechanisms at the network level, so that they can be
available to all the layered applications. The security tech-
niques adopted in IPsec have been designed to be easily
inserted in both IPv4 and IPv6, as detailed in [1].
Somebody can question if it is right to locate the secu-
rity functions at the network level. Quite obviously there
is not a definitive answer, because in general the security
of a system is not based on a single element, rather it is
the result of a combination of several ones. The IP level
is surely the right one to block many low-level attacks, as
those mentioned at the beginning of this section, that ac-
count for a large percentage of all the network attacks due
to their simple implementation. On the other hand, IPsec
is not a complete solution when the applications to be pro-
tected are user-oriented (as in the case of electronic mail)
rather than network-oriented.

II. IPSEC FEATURES
IPsec security services are offered by means of two ded-
icated extension headers, the Authentication Header (AH)
[2] and the Encapsulating Security Payload (ESP) [3], and
through the use of cryptographic key management proce-
dures and protocols.
The AH header was designed to ensure authenticity and
integrity of the IP packet. It also provides an optional anti-
replay service. Its presence guards against illegal modifi-
cation of the IP fixed fields, packet spoofing and, option-
ally, against replayed packets. On the other hand, the ESP
header provides data encapsulation with encryption to en-
sure that only the destination node can read the payload
conveyed by the IP packet. ESP may also provide packet
integrity and authenticity, and an anti-reply service. The
two headers can be used separately or they can be com-
bined to provide the desired security features for IP traffic.
Each header can be used in one of the two defined
modalities: transport mode and tunnel mode. While in
transport mode the security headers provide protection pri-
marily for upper layer protocols, in tunnel mode the head-
ers are applied to tunneled IP packets, thus providing pro-
tection to all fields of the original IP header.
Both AH and ESP exploit the concept of ”security asso-
ciation” (SA) to agree upon the security algorithms, trans-
forms and parameters shared by the sender and the receiver
of a protected traffic flow. Each IP node manages a set of
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 2
TRANSPORT-MODE AH
IP header

(end-to-end)
AH
TCP/UDP header
+ data
TUNNEL-MODE AH
IP header
(tunnel)
AH
IP header
(end-to-end)
TCP/UDP header
+ data
Figure 1. Examples of use of the AH header.
SAs, at least one SA for each secure communication. The
SAs currently active are stored inside a database, known
as the Security Association Database (SAD). An entry in
the SAD (i.e., a security association) is uniquely identified
by a triple consisting of a Security Parameter Index (SPI),
an IP Destination Address, and a security protocol (AH
or ESP) identifier. The Security Parameter Index (SPI) is
transmitted inside both the AH and ESP headers, since it
used to choose the right SA to be applied for decrypting
and/or authenticating the packet. In unicast transmissions,
the SPI is normally chosen by the destination node and
sent back to the sender when the communication is set up.
In multicast transmissions, the SPI must be common to all
the members of the multicast group. Each node must be
able to correctly identify the right SA by combining the
SPI with the multicast address. The negotiation of a SA
(and the related SPI) is an integral part of the protocol for

the exchange of security keys.
Specific security requirements are defined at each node
usually by means of an ordered list of admission rules (or
policies), which form the node’s Security Policy Database
(SPD) [1]. The protection provided to each incom-
ing/outgoing traffic flow is verified/decided by consulting
the SPD. In general, packets are selected for one of three
processing modes based on IP and transport layer header
information matched against entries in SPD. Each packet
is either afforded IPsec security services, discarded, or al-
lowed to bypass IPsec, based on the applicable policies
found in the database.
A. Authentication
The IP Authentication Header [2] is identified by the
value 51 in the Protocol field of the IP header. Normally,
it is inserted between the IP header and the upper level
payload, as shown in Figure 1.
The format of the AH header (depicted in Figure 2) is
very simple as it is composed of a 96-bit fixed part fol-
lowed by a variable number of 32-bit blocks. The fixed
part contains:
• the value of the next type of payload (8 bits);
Next Header
Length
reserved
Security Parameters Index (SPI)
Sequence Number
Integrity Check Value (ICV)
Figure 2. Structure of the AH header.
• the Payload Length, which is the total length of the au-

thentication data expressed as a multiple of 32-bit words
(8 bits);
• a reserved field (16 bits);
• the SPI used by this header (32 bits);
• the sequence number for this header, contains a mono-
tonically increasing counter value (32 bits).
The variable part of the AH header is composed of a
variable number of 32-bit blocks, containing the actual au-
thentication data. Since the Payload Length is expressed
as an 8-bit number, a maximum of 255 32-bit blocks can
be used, that is 1020 bytes. As a consequence, the exact
length of this header depends on the authentication algo-
rithm selected.
The source node of a particular AH SA computes the
authentication data (ICV) over:
• all the IP header fields that are either immutable in transit
or predictable in value upon arrival at the other end-point
of the SA;
• the AH header: Next Header, Payload Length, Re-
served, SPI, Sequence Number, and the Authentication
Data (which is set to zero for this computation);
• the upper level protocol data, which is assumed to be
immutable in transit.
When the destination node receives a packet with an
AH header, the packet’s authenticity and integrity can be
checked by using the procedure detailed in Figure 3. As a
preliminary step, care should be taken in normalizing the
received packet, to eliminate all the variable parts and cor-
rectly compute the authentication value only on the fixed
ones.

B. Authentication techniques
Data integrity in telecommunication systems is nor-
mally ensured by computing and checking the value of a
suitable cryptographic function of the data, often called
Message Digest (MD). Among the most frequently used
algorithms are CRC-16 and CRC-32 (see [4]). These func-
tions effectively perform their task when data modifica-
tions are due to random errors, but they are completely
inadequate to protect the packets against deliberate modifi-
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 3
Figure 3. Procedure to verify the authenticity of a packet protected by the AH header.
cations. In this case, a reasonable degree of protection can
be ensured only by better digest algorithms, such as MD5
[5] or SHA [6]. It is important to note that data integrity
without origin authentication is completely useless. There-
fore, digest algorithms are normally applied in a way to in-
clude some parameters useful to simultaneously provide a
proof of the sender’s identity. Quite often this is achieved
by using public-key encryption algorithms. Unfortunately,
they are computationally much heavier than digest algo-
rithms. Since speed is a premium in computer networks,
the default authentication techniques chosen for IPsec are
keyed authentication algorithms. They are based on the
use of the HMAC authentication algorithm in conjunction
with the hash function corresponding to a message digest
algorithm, such as MD5 or SHA-1. HMAC [7] is a mecha-
nism for message authentication which uses cryptographic
hash functions. Any iterative cryptographic hash function
can be used in combination with a shared secret key. It
is important to mention that the cryptographic strength of

HMAC depends on the properties of the underlying hash
function. The SHA [6] message digest algorithm exhibits
better security properties than MD5 because it produces a
160-bit digest rather than a 128-bit one. For use with ei-
ther AH or ESP, a truncated value using the first 96 bits
is supplied. HMAC-MD5-96 [8] and HMAC-SHA-1-96
[9] must be supported by all IPsec-compliant implementa-
tions.
C. Encapsulating Security Payload
The Encapsulating Security Payload [3] is identified by
the value 52 in the Protocol field of the IP header. When
used, this block must always be the last header because it
completely hides both the upper level payload and all the
next headers (see Figure 4).
The ESP header itself is only partly in clear (see Fig-
ure 5): it consists of an integer number of 32-bit blocks,
with the first one containing the SPI to select the SA to be
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 4
TRANSPORT-MODE ESP
IP header
(end-to-end)
ESP header
TCP/UDP header
+ data
ESP trailer
. . . . . . . .encrypted portion . . . . . . . . .
TUNNEL-MODE ESP
IP header
(end-to-end)
ESP header

IP header
(tunnel)
TCP/UDP header
+ data
ESP trailer
. . . . . . . . . . . . encrypted portion . . . . . . . . . . . . . . . . . . .
Figure 4. Examples of the use of ESP.
used in decrypting all other blocks in the packet, and the
second one containing the sequence number.
The exact format of the encrypted part depends upon the
encryption algorithm used. The default encryption tech-
nique is DES-CBC [10], that is the DES algorithm applied
in CBC (Cipher Block Chaining) mode. DES is a private
key encryption algorithm which is normally applied to 64-
bit data blocks with a 56-bit key (extended to 64 bits by
adding one parity bit for each 7 bits of the key). Various
techniques have been proposed to apply the DES trans-
formation to blocks bigger than 64 bits. The CBC mode
divides the data stream into a sequence of 64-bit blocks
and each block is EX-ORed with the result of the previous
encryption before being encrypted itself. Let E(d,k) be the
encryption operation applied to the data block d with key
k; then the CBC mode may be described by the following
transform to generate the i-th encrypted block:
c
i
= E(d
i
⊕ c
i−1

, k)
Obviously, the encryption of the first data block d
1
requires
an initial value c
0
commonly called Initialization Vector
(IV). The initialization vector must not be null and must
be carefully chosen to insert a random factor in the encryp-
tion process. This is needed to avoid those cryptographic
attacks based on partial knowledge of the data being en-
crypted, such as the known-plaintext attacks that can be
led against the fixed header of some common files (e.g., the
data files of various office automation tools). Normally the
IV value is either a 64-bit number generated by a pseudo-
Security Parameters Index (SPI)
Sequence Number

encrypted data .

Figure 5. Structure of ESP.
random number generator, or it is a 32-bit number gener-
ated in a similar way which is then extended to 64 bits by
concatenating it to its complement.
In the DES-CBC mode, the encrypted portion of the
ESP header (Figure 6) begins with an initialization vec-
tor composed of an integer number of 32-bit words. The
IV is followed by the encrypted payload which is padded
with blocks to ensure that the total dimension of the ESP
header be a multiple of 64 bits. The byte before the last

one in the ESP header contains the padding length (ex-
pressed in bytes) while the last byte contains the payload
type. The minimum length of the padding varies between
0 and 7 bytes, but it is legal to use a longer padding (up to
255 bytes) to hide the real length of the encrypted data.
The DES-CBC algorithm must be supported by all IPsec
standard implementations. Since the DES algorithm can
be regarded at best as a moderately difficult algorithm to
be broken, it is very likely that in the near future other algo-
rithms be standardized for use in IPsec. For example, the
3DES-CBC algorithm was proposed in [11] and is already
provided in many IPsec distributions. This technique is
based on the repeated application of the DES transforma-
tion to the same data block with three different keys, and it
is cryptographically stronger than plain DES because it is
equivalent to an encryption algorithm which uses a 112-bit
key (rather than the 56-bit key used by DES). The authen-
tication data (see Figure 6) included in the ESP payload is
a variable-length field containing an ICV computed over
the ESP packet minus the authentication data field itself.
The length of the field is specified by the authentication
function selected. This field is optional, and is included
only if the authentication service has been selected for the
ESP SA in question.
III. KEY MANAGEMENT
Correct application of both AH and ESP requires that
all the communicating parties agree on a common key
to be used in computing and checking the security head-
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 5
Security Parameters Index (SPI)

Sequence Number

Initialization Vector (IV)


Payload

Padding

Padding Length Payload Type

Integrity Check Value (ICV)

Figure 6. Structure of ESP with DES-CBC.
ers. IPsec allows for key management to occur either out-
of-band or with specifically crafted protocols. There are
several groups within the Internet community which have
proposed different key management mechanisms, all of
them stressing different requirements, such as: fast key ex-
change, strong authentication, lightweight protocols, and
others. Even if no general agreement has yet been reached,
the current work in this area is likely to converge toward
the Internet Key Exchange (IKE), which is a combination
of the following protocols: the Internet Security Associ-
ation and Key Management Protocol (ISAKMP), and the
key exchange protocols Oakley and SKEME.
A. Manual key management
IPsec requires every implementation to allow for man-
ual setting of the security keys, in case no in-line key man-
agement technique is adopted or human-based security is

desired. Obviously manual keying is possible only if the
security operators have separately agreed out-of-band on
the keys to be used, for example at a reserved meeting.
This solution exhibits high personnel costs and does not
scale well, because it requires personal action of an op-
erator on each network device taking part to the secure
channel. Additionally, it can generate a false sense of se-
curity: it is worthwhile reminding the reader that human
intervention does not automatically ensure a higher level
of security, due to untrusted operators and residual prob-
lems related to hardware and software integrity of the de-
vice where the key is set. However, in spite of these dis-
advantages, manual key management finds application in
restricted environments, with a small number of devices
physically secured that, according to the security policy,
can operate only when explicitly enabled by human inter-
vention.
B. Automated key management
An automated key management mechanism is required
to allow the widespread deployment of IPsec. Such sup-
port is essential for the use of the anti-replay features of
AH and ESP, and to accommodate on-demand creation of
SAs (e.g., for user and session-oriented keying). The de-
fault automated key management protocol selected for use
with IPsec is IKE [12] under the IPsec Domain of Interpre-
tation (IPsec DOI) [13]. Other automated key management
protocols are also permitted.
IKE is a hybrid protocol which uses part of Oakley [14]
and part of SKEME [15] in combination with ISAKMP
[16] to provide authenticated keys for use with ISAKMP

itself, AH and ESP. ISAKMP defines a generic architec-
ture for authenticated SA set-up and key exchange, with-
out specifying the actual algorithms to be used. There-
fore, ISAKMP can support a large variety of key exchange
techniques. Oakley is a key-exchange protocol based on
a modified version of the Diffie-Hellman algorithm. Ba-
sically, Oakley describes a set of key exchange methods,
and the security services provided by each method (i.e.,
perfect forward secrecy for keys, identity protection for
the negotiating parties, and authentication). Oakley is one
of the natural partners for ISAKMP. IKE is also using
parts of the flexible key exchange technique described by
SKEME, which provides valuable security features, such
as: anonymity, non-repudiation, and quick key refresh-
ment.
ISAKMP operates at the application layer, and is inde-
pendent of the lower layer protocols. Moreover, ISAKMP
is not bound to a particular security protocol. It is meant as
a generic SA and key management protocol for the Internet
community. As such, it can negotiate authenticated keying
material for any security protocol (AH, ESP, TLS, OSPFv2
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 6
Figure 7. Key management API: PF KEY.
and any application layer security protocol). A generic
key management API (PF KEY) [19] that can be used by
any of the mentioned security protocols has already been
standardized (RFC 2367) and is freely distributed with the
most recent BSD and Linux OSs. PF KEY is a new socket
protocol family used by privileged key management ap-
plications to communicate with an operating system’s SA

databases. The conceptual model is presented in Figure 7.
IKE instantiates ISAKMP for use with IPsec protocols,
i.e., under the specific IPsec DOI. A DOI defines the spe-
cific protocols, cryptographic algorithms and transforms
identifiers, the SA attributes to be negotiated, specific
ISAKMP payload contents, and (if needed) additional key
exchange types.
ISAKMP [16] defines two ”phases” of negotiation. In
the first phase, two entities (key management servers)
agree on how to protect further negotiation traffic between
themselves. The result of this phase is the establishment
of an ISAKMP SA. This security association is then used
to protect the negotiation for the required security protocol
SA (for the IPsec DOI, an AH or an ESP SA).
ISAKMP also defines several types of payloads, which
are used to transfer security association and key exchange
data in formats that are defined by the specific DOI. The
number, the types and the ordering of these payloads dur-
ing a particular ISAKMP negotiation is specified by the
ISAKMP exchange type. Currently, there are seven types
of exchanges defined, each of which is designed to provide
a particular set of security services.
IKE defines two basic methods for generating authen-
ticated keys: main mode and aggressive mode. The for-
mer is mandatory for a compliant IPsec-IKE implementa-
tion. In addition, the quick mode has to be implemented
is mandatory as a mechanism to negotiate non-ISAKMP
SAs and to generate fresh keying material.
Basically, IKE defines four methods for the phase 1 au-
thentication:

• pre-shared keys
• digital signatures
• public key encryption
• revised public key encryption.
The selection of a particular authentication method de-
pends on the security requirements of the specific appli-
cation using IPsec with IKE as the key management pro-
tocol. Authentication via pre-shared keys is mandatory for
any implementation.
As far as the public key cryptography is concerned,
IKE imposes neither the use of a particular digital signa-
ture algorithm, nor a particular key distribution method.
ISAKMP, which defines a certificate payload as a means
to transport certificates via ISAKMP, mandates support for
the following standards:
• PKCS #7 wrapped X.509 certificate
• PGP certificate
• DNS signed key
• X.509 certificate (both for signature and key exchange)
• Kerberos Tokens
• SPKI certificate
• X.509 attribute certificate.
In addition to IKE, several different solutions are be-
ing proposed. Currently, the major competitor is SKIP
(Simple Key-management for Internet Protocols) [17]
which bases its operations on the Diffie-Hellman algo-
rithm. SKIP is simple and addresses several problems of
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 7
Figure 8. Tunnel between two firewalls.
key management in high-speed networks, such as zero-

message key set-up and update which permit fast dynamic
re-keying (i.e. frequent in-line change of the security keys
to avoid analytic attacks based on accumulation of cypher-
text encrypted with the same key).
IV. APPLICATION OF IP SECURITY FEATURES
The AH and ESP headers can be used in different ways
to protect IP communications. This section briefly reviews
some of the most interesting applications, with reference
to the corresponding weaknesses in IP.
A. Virtual Private Networks
Nowadays, technical and economical reasons are push-
ing implementation of corporate wide-area networks to
migrate from dedicated links and proprietary network
technologies to solutions based on public shared links and
open network architectures. This achieves several advan-
tages but currently exhibits a serious drawback: there is
a drastic reduction in intrinsic system security, due to the
use of shared channels and devices. To regain the same
previous level of network security while maintaining the
economical advantages offered by public networks, one
has to succeed in separating and protecting his own data
packets within the crowd of packets travelling across the
public links. Usually, this is achieved by establishing a
Virtual Private Network (VPN). This is commonly done
by the IP tunneling technique: IP packets to be protected
are wrapped in a security envelope and encapsulated inside
normal IP packets that are used just to transport the orig-
inal packets across the public network to their final des-
tination. Often, the endpoints of an IP tunnel are not the
hosts wishing to exchange the data, rather two firewalls

which protect the LANs from external attacks. This set-up
is shown in Figure 8.
VPNs can be created either by using one of the AH and
ESP headers, or both. As an example, with reference to
Figure 8, let us suppose that a TCP channel between a host
H1 in the network N1 and a host H2 in the network N2 has
to be protected only against data manipulation and origin
falsification, while data privacy is not required. In this case
the AH header can be used in the following way. Firewall
FW1 gets the original packet and modifies it by adding the
authentication header before sending it to the other end-
point of the secure channel (FW2), as shown in Figure 8.
When this packet reaches FW2, the firewall checks it for
integrity and origin authentication using the data in the AH
header. If the check is successful, then the IP header and
the AH one are removed and the remaining data (i.e. the
original packet) is sent to the final destination. The differ-
ent formats the IP packet has while travelling from H1 to
H2 is shown in Figure 9.
If the VPN is implemented only wth the AH header, then
the attackers can neither alter the transmitted packets nor
insert forged packets in the channel. However they can
still read the content of the packets. To prevent disclosure
of the payload, the ESP header has to be used too. Sim-
ple use of AH and ESP does not completely protect the
traffic: packets can be deleted by intermediate nodes or
recorded and later replayed. These attacks cannot be eas-
ily hindered at the IP level: appropriate defenses (such as
the use of unique packet identifiers and the generation of
heartbeat packets) are usually placed at some upper level

in the network stack. A partial solution at the IP level is
offered by using the optional anti-replay service provided
by both AH and ESP. The sequence number generated by
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 8
IP PACKET FROM H1 TO FW1
IP header (src=H1,dst=H2,Protocol=TCP)
TCP payload
AH-PROTECTED IP PACKET FROM FW1 TO FW2
IP tunnel header (src=FW1, dst=FW2, Protocol=AH)
AH header (Next header=IP)
IP header (src=H1,dst=H2,Protocol=TCP)
TCP payload
IP PACKET FROM FW2 TO H2
IP header (src=H1,dst=H2,Protocol=TCP)
TCP payload
Figure 9. Format of IP packet travelling from H1 to H2.
the sender has to be carefully checked by the receiver.
This method of creating VPNs, like any other tech-
nique based on IP encapsulation, brings some fragmenta-
tion problems. If the packet to be transmitted already has
the maximum dimension allowed for an IP packet, then
it will not be possible to encapsulate it inside another IP
packet: fragmentation and reassembling will necessarily
take place at the two endpoints of the tunnel. As a conse-
quence, the performance of the virtual channel can degrade
down to 50% of the normal throughput. The worst case
takes place for larger packets, which are typically used in
transferring large data sets that - by contrast - would need
no fragmentation to achieve maximum speed. On the con-
trary, the best case occurs for small packets, such as those

used in interactive applications which - ironically - would
better accept even a larger performance penalty, as long as
the total throughput remains compatible with the reaction
time of the human operator.
Last but not least, it is interesting to realize that this
VPN technique can be adopted even between a firewall and
a single external host (Figure 10). This case is of partic-
ular relevance to guarantee security when a mobile host
is used outside the protected network perimeter. The fire-
wall would act as home agent for HM in the procedure of
neighbour discovery. HM will be assigned two different
IP addresses, one when it is connected inside the security
perimeter, and the other when it is outside of it. In this
last case, the firewall would also act as a relay, by redirect-
ing the packets coming from inside the corporate network
to the external address, after adding the required headers
(AH only, or AH plus ESP).
B. Application level security
Networked applications executing on top of an IP stack
including IPsec may require usage of a communication
channel with specific features. In order to avoid dupli-
cation of functionality (and hence performance degrada-
tion), it is useful to be able to specify at the transport layer
the security attributes of the channel being created. In
the first BSD-UNIX implementations of IPsec, this effect
can be obtained by properly using the setsocketoption()
system call. Anyway, this is not a complete solution for
application-level security because only a partial protection
is obtained: AH provides host-based authentication only,
while applications usually require user-based authentica-

tion. Moreover, AH and ESP protect the data only during
their transmission along the channel. Once the data have
been received, they are no longer protected in any way.
This fact may not be relevant if the receiving host is a se-
cure one, but there is the additional implication that ori-
gin authentication and data integrity properties are lost as
well, so that formal non-repudiation cannot occur after the
data have been extracted from the secure channel. We can
therefore draw the conclusion that the security features of
IPsec do not eliminate the need for other security mecha-
nisms, that will probably be better placed at the application
level.
C. Routing security
With the increasing use of Internet for commercial ap-
plications, the need for a reliable and secure network in-
frastructure has become higher than ever. Since IPsec
offers different network level security services through a
proper combination of AH and ESP headers, it is highly
desirable that they be applied to the messages exchanged
by routers. IPsec protection for routing protocols prevents
attacks aiming to subvert the logical architecture of the net-
work. As an example, in IPv6 intra-domain routing proto-
cols rely on the security provided by the default AH and
ESP support of IPv6 routers. The following types of mes-
sages are protected:
• router advertisements, to ensure that they are originated
by an authorized router;
• neighbour advertisements, to ensure that they come from
authorized hosts and to avoid the risk of somebody attach-
ing a new host to the network without proper authorization.

The ICMP messages related to an unreachable host or net-
work (”destination unreachable”) or the one that indicates
a better route (”redirect”) should also be at least authen-
ticated to ensure that these messages come from hosts or
routers that were on the original path of the packets.
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 9
Figure 10. Tunnel between a firewall and a mobile host.
Securing these types of messages is surely not trivial.
For example, the routing advertisements are sent to a mul-
ticast group and therefore all the routers in the group must
know the (common) secret key to be used to verify and/or
decrypt the messages; but in turn this fact implies they can
forge messages and impersonate any router in the group!
These and more others are common aspects that a reliable
security mechanism for the routing infrastructure has to
address. Protection of the neighbor advertisements poses
a serious problem: these messages can be protected only
after a SA has been created between the host and the ad-
dress distribution center. On the other hand, this SA can
be created only after an address has been assigned to the
host, so we conclude that this is the typical chicken-and-
egg problem which has no correct way to be solved. To
break the loop, partial solutions are possible: for example,
priority can be given to the address assignment phase and
SA setup can be permitted only subsequently, but in this
way the address assignment phase is not protected. Al-
ternatively, public-key authentication can be used: host is
assigned a key pair (private and public key) and has to be
pre-configured with the public key of the authority which
signs the certificates of the routers and the address distribu-

tion centers. The last alternative is to configure routers so
that they do not advertise local prefixes; by this way, each
host is forced to contact a router first. Protection against
false ICMP messages requires that they use the authenti-
cation header, but it has the drawback to require the estab-
lishment of a SA with each router and host on the path be-
tween the source and the destination of the packets. With
respect to the security of the messages used by the vari-
ous routing protocols, they should always be exchanged
only within the frame of a SA and be protected by AH.
For sake of generality, this solution is highly preferable to
using authentication mechanisms specific for each routing
protocol.
V. FUTURE DIRECTIONS
Security is one of the fastest moving areas in com-
puter networks, as it is vital to protect data and computer
resources and to enable economical exploitation through
electronic commerce. IP security is not the exception to
the rule: new extensions to IKE and ISAKMP authenti-
cation modes have recently been defined, addressing the
secure remote access problem and trying to introduce in
IPsec some user level authentication techniques [18], [20].
At the same time, IPsec is moving toward the integration
with policy-based networks. A conceptual model for a se-
curity policy-based networking environment is being de-
fined for IPsec [21], together with a protocol [22] which
aims to provide policy discovery and policy resolution to
IPsec nodes. Till now, IPsec has found applicability in
static network configurations and, in general, networks
that are under a common administration (VPNs and in-

tranets). The new mechanisms addressing policy man-
agement issues make IPsec scalable in general cases and
could contribute to the widespread deployment of this se-
curity technology in Internet. The net benefit will be that
more security will be already available at the network level
and hence applications will be able to concentrate on dif-
ferent security aspects, such as authorizations and non-
repudiation.
NATO workshop on Advanced Security Technologies in Networking (Portoroz, May 29 - June 2, 2000) 10
REFERENCES
[1] S. Kent, R. Atkinson, Security Architecture for the Internet Pro-
tocol, RFC 2401, November 1998
[2] S. Kent, R. Atkinson, IP Authentication Header, RFC 2402,
November 1998
[3] S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP),
RFC 2406, November 1998
[4] B. Schneier, Applied Cryptography, John Wiley & Sons, New
York, 1996.
[5] R. Rivest, The MD5 Message-Digest Algorithm, RFC 1321, April
1992
[6] National Institute of Standards and Technology, U.S. Department
of Commerce, Secure Hash Standard, document FIPS-180-1,
April 1995
[7] H. Krawczyk, M. Bellare, R. Canetti HMAC: Keyed-Hashing for
Message Authentication, RFC 2104,February 1997
[8] C. Madson, R. Glenn, The Use of HMAC-MD5-96 within ESP
and AH, RFC 2403, November 1998
[9] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP
and AH, RFC 2404, November 1998.
[10] C. Madson, N. Doraswamy, The ESP DES-CBC Cipher Algo-

rithm with Explicit IV, RFC 2405, November 1998
[11] P. Karn, P. Metzger, W. Simpson, The ESP Triple DES Transform,
RFC 1851, September 1995
[12] D. Harkins, D. Carrel, The Internet Key Exchange, RFC 2409,
November 1998
[13] D. Piper, The Internet IP Security Domain of Interpretation for
ISAKMP, RFC 2407 November 1998
[14] H. Orman, The Oakley Key Determination Protocol, RFC 2412,
November 1998
[15] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mech-
anism for Internet, from IEEE Proceedings of the 1996 Sympo-
sium on Network and Distributed Systems Security
[16] D. Maughan, M. Schertler, M. Schneider, J. Turner, Internet Secu-
rity Association and Key Management Protocol (ISAKMP), RFC
2408, November 1998
[17] A. Aziz, T. Markson, H. Prafullchandra, Simple Key-Management
for Internet Protocols (SKIP), Internet Draft (draft-aziz-skip-
*.txt)
[18] Y. Dayan, S. Bitan, IKE Base Mode, Internet Draft, October 1999
[19] D. McDonald, C. Metz, B. Phan, PF
KEY Key Management API,
Version 2, RFC 2367, July 1998
[20] R. Pereira, The ISAKMP Configuration Method, Internet Draft,
1999
[21] L.A. Sanchez, M.N. Condell, Security Policy System, Internet
Draft, November 1998
[22] L.A. Sanchez, M.N. Condell, Security Policy Protocol, Internet
Draft, July 1999
[23] Niels Ferguson, Bruce Schneier, A Cryptographic Evalu-
ation of IPsec Counterpane Internet Security, Inc., 2000,

BIOGRAPHIES
Madalina Baltatu holds a Dr. Electronic Engineering
from Politehnica University of Bucharest (Romania). She
is currently a Ph.D. candidate in the field of network secu-
rity at Politecnico di Torino. Dr. Baltatu can be reached as

Antonio Lioy holds a “laurea” in Electronic Engineering
and a Ph.D. in Computer Engineering. He is currently a
Professor of Distributed Computing Systems at Politec-
nico di Torino, where he leads a research group active in
computer and network security. Prof. Lioy can be reached
as