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, 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 as lioy@polito.it . 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. 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