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
Trang 1IP 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
Trang 2NATO 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
Trang 3modifi-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
Trang 4NATO 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-64-bit key (extended to 64 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:
ci = E(di⊕ ci−1, k) Obviously, the encryption of the first data block d1requires
an initial value c0 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
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 KEYMANAGEMENT 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
Trang 5head-Security Parameters Index (SPI) Sequence Number
.
Padding Length Payload Type
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
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
Trang 6NATO 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
Trang 7Figure 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 OFIPSECURITY 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 forig-inal
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 comSim-pletely 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
Trang 8NATO 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 comredirect-ing 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
Trang 9Figure 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 comcom-puter 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
Trang 10NATO 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,
http://www.counterpane.com
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
baltatu@athena.polito.it
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
aslioy@polito.it