Wednesday, November 25, 2009

Chapter 12: IP Security for IPv6 and IPv4

Introduction

The IPv6 proposed standard specifies that implementations of IPv6 conform to the Security Architecture for the Internet Protocol [RFC 1825]. This protocol describes IP Security (IPsec) mechanisms and services for both IP version 4 (IPv4) and IP version 6 (IPv6). Randall Atkinson, the author, states that RFC 1825 very specifically describes IP-layer security and is not a general security architecture for the Internet.

IP Security is intended to be able to provide authentication, integrity, and confidentiality for applications operating on connected end systems when appropriate algorithms are in use.

Separate documents provide the details for each security mechanisms. RFC 1826 describes the IP Authentication Header (AH) protocol. RFC 1827 describes the IP Encapsulating Security Payload (ESP) header protocol. Key management, while separate from both these protocols, is an important part of IP security. Both the IP Authentication Header Protocol and IP Encapsulating Security Payload Protocols work with IPv6 and IPv4.

This chapter briefly:

  • Provides a quick summary of the IPv6 features pertinent to security.
  • Introduces the IP security protocol suite
  • Describes the Internet Protocol security services for IPv4 and IPv6
  • Discusses different ways to use IP security and some of its limitations
  • Summarizes the IP security sequirements
  • Briefly compares IPv6 security and the Secure Sockets Layer (SSL) protocol and discusses how you might use them together. These protocols work in different ways and indeed, reside on different layers; each has its place.

The primary objective of the IP Security Architecture is to ensure that cryptographic security mechanisms for Pv64 and IPv4 are available to users who desire security.

Quick review IPv6 features pertinent to security

This section provides is a brief review of some of the features of IPV6 that involve security, including IPv6 headers, addresses, and routing.

IPv6 headers

The IPV6 header is approximately twice the size of an IPV4 header although the IPV6 address space is significantly larger than version 4. The IPV6 designers dropped a number of header fields. shows a simplified view of the IPv6 header fields. This helps to keep the processing cost of packet handling as low as possible.

Figure -1 IPV6 header fields

(IP6F12-01.WMF)

Version ¾ This is a 4-bit field. It contains the version number of the IPV6.

Priority ¾ This is a 4-bit field. A source uses this field to determine the priority for delivering packets ().

Use values eight through 15 for non-congestion-controlled traffic such as voice and video. Use the priority value of 15 for traffic that you really do not want to loose, such as low-fidelity audio traffic. Use the lower priority value of 8 for congestion-controlled traffic that you are most willing to loose, such as high-fidelity video traffic.

Addressing

IPv6 has three type of addresses that consist of 128-bit identifiers for interfaces and sets of interfaces. IPv6 Addresses of all types are assigned to interfaces, not nodes. The three types of addresses are:

Unicast ¾ addresses identify a single interface. The protocol delivers a packet sent to a unicast address to the interface that the address identifies.

Anycast ¾ addresses identify a set of interfaces that typically belong to different nodes. The protocol delivers a packet sent to an anycast address to one of the interfaces in the set that the address identifies. The recipient is usually the nearest interface as determined by the routing protocol in use.

Anycast ¾ addresses are syntactically indistinguishable from unicast addresses. Support for global anycast sets may be unavailable or very restricted.

Multicast ¾ address identify a group of interfaces that typically belong to different nodes. A node may belong to any number of multicast groups. The protocol delivers a packet sent to a multicast address to all of the interfaces that the address identifies.

NOTE:

IPV6 does not have broadcast addresses.

Routing

Routing in IPV6 is similar to routing in IPV4 except addresses are 128 bits long. Routing algorithms that work with IPV4 also work with IPV6. However, IPV6 includes some new and powerful routing extensions. These include:

  • Provider selection that is based on policy and performance
  • Host mobility for routing to a current location
  • Auto readdressing for routing to a new address

The Next Header field includes the Routing header. The routing header lists one or more intermediate nodes, where the packet has to follow the link. This is very similar to the Source Route function in IPv4.

IP Security architecture

The IETF defines the IP security architecture in a number of protocol documents including RFC 1825, RFC 1826, and RFC 1827. The IP security architecture (referred to as IPSec) consists of security variables, mechanisms, control, and management as the conceptual model shows in.

IPSec protocol suite

The IP security protocol suite, referred to as IPsec, provides privacy and authentication services at the IP layer. The protocol suite consists of seven groups of documents as shown in. This organization of documents attempts to avoid overlapping functions and to permit a modular development and enhancement of IP security. The protocol suite specifies standard default algorithms to ensure interoperability in the global Internet.

For point-to-point communication, authentication algorithms include keyed Message Authentication Codes (HMAC) based on symmetric encryption algorithms such as DES or on one-way hash functions such as MD5 or SHA-1. For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms might be appropriate.

The minimum mandatory-to-implement encryption algorithm defined in the Encapsulation Security Payload protocol is based on the Data Encryption Standard (DES) in Cipher Block Chaining Mode (CBC).

  1. The Architecture document describes the general concepts, security requirements, and mechanisms for IP security.
  2. The Encapsulated Security Payload (ESP) protocol document defines the default values, header format, and general issues regarding confidentiality and encapsulation for secure IP datagrams.
  3. The IP Authentication Header (AH) protocol document defines the default values, header format, and general issues regarding authentication for IP datagrams.
  4. The growing body of cipher documents describe the various ciphers that can be used with the ESP protocol for encapsulation and confidentiality. Examples include The ESP CAST128-CBC Algorithm, The ESP 3DES-CBC Algorithm Using an Explicit IV, and The ESP DES-XEX3-CBC Transform documents. When these or other algorithms are used for either ESP or AH, the Domain Of Interpretation (DOI) document has to indicate certain values, such as algorithm type. The cipher documents provide input to the DOI.
  5. The growing body of authenticator documents describe the various authenticator algorithms to for both ESP and AH. Examples include HMAC- MD5, and HMAC-SHA-1 documents. When these or other algorithms are used for either ESP or AH, the DOI document has to indicate certain values, such as algorithm type. The authenticator documents provide input to the DOI.
  6. The Domain Of Interpretation document (DOI) is part of the IANA Assigned Numbers mechanism. The values described in the DOI are well-known.
  7. The key management documents describe the IETF standards-track key management schemes. Examples include The OAKLEY Key Determination Protocol and The Resolution of ISAKMP with Oakley. The key management documents also provide values for the DOI.

The primary objective of IP security protocol suite is to ensure that IPv4 and IPv6 will have solid cryptographic security mechanisms available to users who desire security. The design of the various components of the IP security protocol suite is to:

IPSec services for IPv4 and IPv6

The IP Authentication Header (AH) the IP Encapsulating Security Payload Header (ESP) as defined by RFC 1826 and RFC 1827, provide security services to IPv4 and IPv6. You can use these two IP security mechanisms together or separately. Both protocols operate in either of two modes; tunnel-mode or transport-mode.

Combining security mechanisms

You can combine the use of the IP Authentication Header protocol with the IP Encapsulating Security Payload protocol to provide different types of security. Use AH to provide:

  • Integrity and authentication.
  • Non-repudiation if used with authentication algorithms such as RSA.; a public key cryptographic algorithm named for its inventors (Rivest, Shamir, and Adleman) that does encryption and digital signatures.

Use ESP to provide:

  • Integrity and confidentiality
  • Authentication if used with certain authenticating encryption algorithms.

AH and ESP together can provide added security for users who want strong authentication, integrity, and confidentiality. You can do this by adding the AH to an IP datagram prior to encapsulating the datagram using ESP. When you combine AH and ESP, the placement of the IP Authentication Header makes clear which part of the data is being authenticated.

Typical use

The primary difference between the authentication provided by ESP and AH is the degree of the coverage. ESP can provide the same security services but it can also provide confidentiality services. ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode).

The AH and ESP headers can be used in a number of different ways. The IP Authentication Header protocol provides integrity and authentication for IP datagrams, but it does not provide confidentiality services. Companies could import or export products implementing AH to or from locations that regulate the use of encryption.

The IP Encapsulating Security Payload protocol provides integrity and confidentiality to IP datagrams. ESP encrypts either the entire IP datagram (tunnel-mode) or it encrypts the upper-layer protocol portion of the datagram (transport-mode). Both protocols can operate in either transport- or tunnel-mode.

shows that both AH and ESP work between

  • Two or more hosts implementing AH or ESP or both
  • Security gateways implementing AH or ESP or both
  • A host or security gateway implementing AH or ESP or both and a set of hosts or gateways.

Security gateways

A security gateway is a system that provides security services and acts as the communications gateway between internal trusted hosts and subnets and external untrusted systems. A trusted subnet contains hosts and that trust each other not to take part in active or passive attacks against each other. It also means that the hosts and routers trust that the underlying communications channel between them is not being attacked.

The security gateway establishes the security association for the host and provides security services between the gateway and an external destination. In this situation, only the gateway needs to implement AH, ESP, or both. The trusted hosts can take advantage of the AH and ESP services between the gateway and the rest of the Internet.

When a security gateway provides services on behalf of hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and external systems

Protocol support for security gateways

The AH and in particular ESP support for security gateways means that a trusted host or network behind the gateway can omit encryption (). When the security gateway implements the IP security protocols, hosts and networks can still provide authentication, integrity, and confidentiality for packets crossing untrusted network segments. The gateway provides the needed security services.

When there is no intervening security gateway, the hosts in a host-to-host connection can implement AH, ESP, or both. When the host implements ESP, it can encrypt only the upper-layer protocol data such as TCP or UDP data. The IP header is in cleartext and the packet can reach its destination. This mode reduces both the bandwidth consumed and the protocol processing costs for users that don't need to keep the entire IP datagram confidential.

Sometime a security gateway can receive a datagram containing a security label, such as an IP security option (IPSO) label, from a Trusted Host. In this case, the security gateway considers the security label when it establishes the security association to use between the gateway and the destination. If the security gateway receives a packet containing an ESP header, it adds the appropriate authentication information. Security gateways must perform address-based IP packet filtering on unauthenticated packets from a system known to be using IP security.

ESP can be used to provide gateway-to-gateway encryption. This is particularly useful if you want to build a private virtual networks across an untrusted backbone such as the Internet. Gateway-to-gateway encryption is not a substitute for host-to-host encryption. You can use gateway-to-gateway and host-to-host encryption together.

End systems that implement ESP can use it to encrypt the user data carried between them. A security gateway does not have to be present in the connection between the end systems.

IPSec modes

The IP security protocols support two modes of operation; transport-mode or tunnel-mode.

Transport-mode

Transport-mode applies only to host implementations. Transport-mode provides protection for upper-layer protocols and selected IP header fields.

Note that the use of transport-mode is not restricted to the use of TCP and UDP. For example, host-to-host implementation can send ICMP message in either mode: transport- or tunnel-mode.

In ESP implementations transport-mode does not provide protection for the IP header. The transmitter encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header and, if it is an IPv6 implementation, any IP extension headers.

Tunnel-mode

Tunnel-mode can apply to hosts, security gateways, or both. Tunnel-mode encapsulates the entire IP datagram including the IP header that carries the ultimate source and destination addresses. Another IP header carries intermediate addresses such as the address of a security gateway. Tunnel-mode protects the entire inner IP packet, including the entire inner IP header.

IPSec and key management

The IP-layer security mechanisms use key management methods where an upper layer protocol such as TCP or UDP carries the key management data. These protocols might carry key management data on a specific port or provide for the manual distribution of the key management data.

Key management could be either in-band key management, or out-of-band key management. In-band key management implementations carry the key management data in a distinct IPv6 header. In out-of-band key management, an upper layer protocol such as UDP or TCP carries the key management data. This arrangement decouples the key management mechanism from the other security mechanisms.

The only coupling between the key management protocol and the IP security protocols is with the Security Parameters Index (SPI). A security parameter index (SPI) value identifies a security association. The SPI, a 32-bit pseudo-random value used in conjunction with the destination address, uniquely identifies the security association for this datagram. The SPI is similar to the SAID used in other security protocols. Several key management systems will be usable with the IP security specifications, including manual key configuration. Work is ongoing within the IETF to specify an Internet Standard key management protocol.

The lose coupling of the key management protocol and IP security protocol means you can use several different key management schemes. Key management protocols include numerous features including the key establishment and verification methods, key transfer methods, authentication, symmetry, perfect forward secrecy, and back traffic protection.

The key management protocol negotiates a number of parameters for each security association. A security association is the set of security information relating to a given network connection or set of connections. The negotiated parameters include not only the keys but other information such as the cryptographic algorithms and modes and security classification level, if any used by the communicating parties.

The key management mechanism creates a logical table with the parameters for each current security association. When processing a datagram, the IP Authentication Header and reads this table to determine which algorithm, mode, and key to use in authentication. An ESP implementation normally needs to read that security parameter table to determine how to process each datagram containing an ESP, such as which algorithm, mode and key to use.

Control and logic of the IPSec mechanisms

The security association and polity for a communication determines the control of the AH and ESP mechanisms for outgoing and incoming traffic. The security policy determines the correct security association for outbound and inbound datagrams. The security association determines which algorithms to applied to the datagrams and how they are applied.

Security Associations

Both the AH and ESP use a security association as (SA) part of a communication. An SA is a relationship or a contract between two or more communicating entities that describes how they will use security services to communicate securely. All parties to the communication session must agree upon the contents of this shareable contract, the SA.

A security association identifies such things as the algorithms in use and the keys in use with the authentication and encryption algorithms. At a minimum, the senders and receivers must agree on a key, on an authentication or encryption algorithm, and on a set of additional parameters needed for use by the algorithms. Put another way, a security association contains all the variables needed for the control and calculation of the AH and ESP.

While additional parameters can be included, a Security Association normally includes the parameters shown in . show an example of a security association.

A security association is one-way; a communications session between two hosts will normally have two security associations in use, one for each direction.

The security association separates the key management and the security mechanisms from each other. The only role key management has with the security association is to update the SA variables and the other mechanisms that use those variables. The IP security protocols specify that the only coupling between the key management protocol in use and the security protocol is with the security parameter index (SPI).

Security policy

The security policy in use controls the use of the IP security mechanisms and the choice of the appropriate security associations. A security association can be either host-oriented or user-oriented. A host-oriented security association supports the use of the same session key for all the users in the same host. In a user-oriented security associations, all users have separate session keys.

The security policy in place determines if a security association is to be host-oriented or user-oriented. The security policy of an implementation defines the variables that enforce the security policy when selecting correct security associations and SPI for the datagrams.

The combination of the security association and the security policy records make up the security context of a communication. Think of the security context as a management concept that represents the security variables and the mutual trust shared by the communication entities.

shows and example of a security policy record with user-oriented keying enforcement.

A Security Association communication session

A user accessing SA attributes, uses the Security Parameter Index (SPI) that belongs to the key-exchange procedure. A host uses the sending user ID and the destination address to select the SPI for security association for the communication. The destination address can be a unicast address or a multicast group address. The receiving host uses the SPI value along with the destination address to identify the correct security association. Each station must remember the SPI used by its partners to identify the security context.

Unicast communications

A normal authenticated session between hosts has two SPIs; one for each direction. In a unicast communication, the destination system normally selects the SPI value. An AH implementation can use the SPI in combination with the destination address to determine the security association and related security configuration data for all valid incoming packets.

Multicast communications

In a multicast communication, there are multiple destination systems but a single destination multicast group. This means one system needs to select the SPIs for the group and then communicate that information to all the members of the group.

All senders of multicast traffic to a group can use a single SPI or the senders of multicast traffic to a group can use a separate SPI for each sender.

In the first instance, the receiver only knows that the message came from a system knowing the security association data for that multicast group. The receiving system can only authenticate that the packet was sent from one of those systems and cannot authenticate which of those systems sent it.

In the second instance, If each sender has its own security association and asymmetric algorithms are in use, then data authentication can occur. The receiver needs to check the validity of the security association for the packet and the claimed source address of the packet. If the receiver fails to do so, the receiving system cannot authenticate whether the packet's claimed source address is valid.

For example, in the receiver C shares a unique security association with sender A and with sender B. Both A and B send C a secure packet that contains their valid security association. A’s packet also properly contains A’s source address. However, B has forged A’s source address and included it in the packet. Receiver C fails to verify that the source addresses in each of the packets are correctly identified with the security association that was used. In this situation, B has successfully fooled C into believing the packet came from A.

IP Authentication Header details

The Authentication Header provides connectionless integrity and data origin authentication for IP datagrams. It also provides protection against replays. AH provides authentication for as much of the IP header and upper-layer protocol data as possible. Because some IP header fields can change in transit, the values of such fields cannot be protected by AH.

AH does not provide for confidentiality and protection from traffic analysis; it does not encrypt IPv6 datagrams. This means that locations that regulate the export, import, or use of encryption to provide confidentiality can still use implementations of AH.

R. Atkinson (RFC1826) says the use of the IP Authentication Header protocol "might also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed. For example, use of an asymmetric digital signature algorithm, such as RSA, could provide non-repudiation."

The IP Authentication Header holds authentication information for its IP datagram. The AH calculates the authentication information using all of the fields in the IP datagram that do not change in transit. The AH uses a secret authentication key in the computation. Fields that change in transit, such as the hop count are not considered in the calculations

The default authentication algorithms is HMAC with MD5 or SHA-1 which cannot provide non-repudiation by itself. The AH provides more security than is in IPv4 and might be sufficient for the needs of many users.

All IPv6-capable hosts must implement the IP Authentication Header and support the use of keyed MD5. IPv4-systems claiming to implement AH must do the same. Implementations can support other authentication algorithms in addition to MD5.

The authentication data carries its own payload. This means the Internet infrastructure does not need to change. Systems that do not use authentication can ignore the authentication data.

Authentication Header syntax

An Authentication Header normally occurs after IP headers that are read at each hop. However, an Authentication Header appears before other headers that are not read at intermediate hops. When used with IPv6, the Authentication Header normally appears after the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options ().

When used with IPv4, the Authentication Header normally follows the main IPv4 header ().

Authentication Header fields

The Internet Assigned Numbers Authority (IANA) has assigned AH the protocol number 51. This value is included in the Next Header field (IPv6) or the Protocol field (IPv4) of the protocol header (IPv4, IPv6, or Extension) that immediately precedes the AH header.

The IP Authentication Header holds authentication information for its IP datagram. The Authentication Header uses a secret key to do the necessary calculations. Calculations are performed prior to sending the authentication packet to the recipient. At a minimum, an IPv6 capable host must implement the Authentication Header with HMAC with MD5 or SHA-1, for security reasons. MD5 algorithm using a 128-bit key. Use of the MD5 algorithm standard is to help prevent compatibility problems within the Internet. Only use algorithms that are believed to be cryptographically strong one-way functions with the IP Authentication Header.

The authentication data is the output of the calculation over the entire IP datagram. show a simplified version of the AH header fields.

The authentication header has the following fields:

The Internet Assigned Numbers Authority (IANA) has reserved the SPI values of 1 through 255.

This field would be used for anti-replay services for a specific security association. Both the sender’s and receiver’s counters reinitialize to zero when they establish a security association. The first packet sent with that security association will have a sequence number of 1. The transmitter increments the counter by one and ensures that the counter has not recycled.

Calculation of the authentication data

The AH protocol uses information in the AH header to calculate the authentication data. This occurs before fragmentation of the outbound datagrams and after the reassembley for inbound datagrams.

The calculation sequence for outbound datagrams is as follows. The protocol:

AH and sensitivity labeling

IPv6 normally uses implicit sensitivity label rather then the explicit ones used in IPV4. The Authentication Header provides the implicit sensitivity labels. Explicit sensitivity labeling is not a requirement.

In some cases an implementation might also support explicit labeling, such as IP Sensitivity Option (IPSO) labels as defined by RFC 1108.

If an implementation uses explicit sensitivity labels:

In an IPv4 network with explicit labeling, there is no authentication or cryptographic binding of the label to the IP header and user data.

NOTE:

All explicit IP sensitivity labels must be authenticated using either AH, ESP, or both.

Encapsulating Security Payload details

The second IP security extension Header, the IPv6 Encapsulation Security Header (ESP) provides integrity and confidentiality to IPv6 and IPv4 datagrams. Depending on the algorithm in use, it can also provide data origin authentication and connectionless integrity to IP datagrams. ESP also provide anti-replay service, a form of sequence integrity, and limited traffic flow. Traffic flow confidentiality requires selection of tunnel mode. Traffic flow confidentiality is most effective if implemented at a security gateway. Data origin authentication and connectionless integrity are joint services and independent of confidentiality.

ESP works with both unicast and multicast traffic.

Like AH, the Encapsulating Security Header is also cipher independent. To get interoperability within the Internet, the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) mode is being used as a proposes standard algorithm.

NOTE:

In June, 1997, the DES encryption block cipher was cracked. DES uses a fixed-size, 56-bit encryption key. DES was endorsed by the U.S. government in 1977 as an official standard.

ESP supports two modes, transport-mode ESP and tunnel-mode ESP. ESP encrypts data and places the encrypted data in the data portion of the IP Encapsulating Security Payload. You can use ESP to encrypt the whole the IP datagram (tunnel-mode) or just to encrypt transport-layer data, such as TCP and UDP data. (transport-mode).

The use of ESP should not adversely impact routers or other intermediate systems that are not participating in the particular ESP security association.

Encapsulating the encrypted data provides confidentiality for the entire original datagram. Encrypting and decrypting each IP datagram increase the IP protocol processing cost and the communications latency. The cost of implementing ESP will vary from implementation-to-implementation and will depend on the encryption algorithm, key size, and various other factors. Hardware implementations of ESP can be advantageous when high throughput is needed.

To provide interoperability throughout the Internet, the ESP protocol requires that, at a minimum, all ESP implementations support the use the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) mode. In addition, you can implement other confidentiality algorithms and modes. Remember that the export and use of encryption is regulated in some countries.

Cost and benefit of using cryptographic algorithms

The use of AH and ESP increases the IP protocol processing costs and communication latency.

comparison of the authentication data causes the increased latency in AH. the encryption and decryption of the ESP causes the increased latency in ESP.

B. Schneier in his book Applied Cryptography implies that public-key algorithms are slow. Symmetric algorithms are generally considerably faster than public-key algorithms. Public key algorithms with long key lengths provide better security than private key algorithms with short key lengths. The stronger you want the security to be, the larger the cost of computing the cryptographic algorithm. Using a cryptographic algorithms is a trade between benefits and costs. compares the encryption speeds of some block ciphers on a 33 MHz 486SX.

compares encryption speeds of some hash functions on a 33 MHz 486SX.

ESP Header syntax

The ESP payload consist of the unencrypted fields of the payload and encrypted data. The unencrypted fields of the ESP header inform the intended receiver how to decrypt and process the encrypted data. The encrypted data portion includes some protected fields containing security protocol information and the encrypted encapsulated IP datagram.

ESP Header location

An Encapsulating Security Payload header normally occurs before the upper layer protocol header if operating in transport mode or before an encapsulated IP header if operating in tunnel mode. The Internet Assigned Numbers Authority (IANA) has assigned ESP the protocol number 50. This value is included in the Next Header field (IPv6) or the Protocol field (IPv4) of the header that immediately precedes the ESP header. shows that ESP consists of an unencrypted header, encrypted header fields, and encrypted user data. The user data can consist of either an upper-layer protocol frame such as TCP or UDP, or an entire IP datagram. and the encrypted data.

The field(s) of the unencrypted ESP header inform the receiver how to decrypt and process the encrypted data. The encrypted data component includes fields for the security protocol and the encrypted encapsulated IP datagram.

Encapsulated Security Payload Header fields

Some of the ESP Header fields are optional. The security association defines if an option has been selected. If the option field is not selected, the entire field is omitted from the Integrity Check Value (ICV) calculations. The format of ESP packets for a given security association is fixed for the duration of the security association. shows a more detailed diagram of an ESP header.

The ESP hearer fields include:

  • Security Parameters Index ¾ This is a 32-bit field. This field identifies the security association for this datagram. If no security association exists, the value is this field is zero. You could use a value of zero for local debugging purposes. The destination system usually selects the SPI when the sender and received establish the security association for the datagram.

The Internet Assigned Numbers Authority (IANA) has reserved the SPI values of 1 through 255.
  • Sequence Number ¾ The sequence number is optional and is only included if the security association includes anti-replay services. Both the sender’s and receiver’s counters reinitialize to zero when they establish a security association. The first packet sent with that security association will have a sequence number of 1. The transmitter increments the counter by one and ensures that the counter has not recycled.
  • Initialization Vector ¾ This is a variable-length field and is optional. A security association uses this field only when the encryption algorithm requires an explicit initialization vector. The length of the initialization vector is dependent upon the choice of encryption algorithm.
  • Payload Data ¾ This is a variable-length field and contains the data describe by the Next Header.
  • Padding ¾ This field is used with encryption and is used to fill the Payload Data to a multiple of the blocksize required by the encryption algorithm. If encryption has not been selected, the Padding field is used to align the Next Header field so that the last bit of that field ends on a 32-bit boundary.
  • Next Header ¾ This is an 8-bit field and identifies the type of data in the Payload Data field. The value of this field is chosen from the set of IP protocol numbers. defined IANA.
  • Authentication Data ¾ The length of this field varies. However, this field is always an integral of 32-bit words. The protocol uses the combination of destination address and SPI to find the necessary information for this field. If the field is longer than needed to store the authentication data, then the protocol fills the unused bits with implementation-dependent values. This field can include explicit padding. Padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6).

ESP modes

ESP uses two modes; transport mode or tunnel mode. In transport mode the protocol encrypts only the options. In tunnel mode the protocol encrypts the whole IP packet and allocates a new unencrypted IP.

Transport mode

Transport mode provides protection for upper layer protocols but not the IP header. Only host-to-host implementations can use transport mode. Using transport mode conserves bandwidth because there are no encrypted IP headers or options.

In this mode, the protocol inserts ESP after the IP header and before any upper layer protocols or other IP security headers such as AH. shows ESP transport mode for a typical IPv4 packet. The ESP trailer field includes any padding, pad length, and Next Header fields.

Note that in IPv6, the destination options extension header as shown in, can appear before or after the ESP header. Because ESP only protects fields following the ESP header, it is a good idea to place the destination options headers after the ESP header.

In the IPv6 ESP is considers an end-to-end payload. In transport mode this means ESP header follows the end-to-end headers such as hop-by-hop, routing, and fragmentation extension headers. The ESP header should precede any transport layer headers.

In transport mode outbound datagrams the host:

  • Uses the senders user ID and the destinations address as data and selects the security association according to the security policy for the datagram
  • Encapsulates the original transport layer frame into the ESP
  • Applies the appropriate encryption algorithms to the ESP
  • Encapsulates the encrypted ESP in a cleartext IP datagram as the last payload

In transport mode inbound datagrams, the host:

  • Checks the security policy for the datagram
  • Selects the correct security association according to the SPI field in the datagram
  • Applies the appropriate decryption algorithms to the encrypted ESP
  • Removes the original transport-layer data from the ESP if decryption succeeds

ESP tunnel mode

Both hosts and security gateways can use ESP tunnel mode. If you implement ESP in a security gateway, you must use tunnel mode. Implementing ESP in a security gateway provides a mechanism to protect subscriber transit traffic. ESP tunnel mode protects the entire inner IP packet, including the entire inner IP header.

In tunnel mode outbound datagrams, the host:

  • Uses the senders user ID and the destinations address as data and selects the appropriate security association according to the security policy for the datagram

Note that if host-oriented keying is in use, all sending user IDs on a given system have the same security association for a given destination address. If there is no key, the key management system that is in place generates a key to use during the communication session to encrypt the data.
  • Encapsulates the original IP datagram into the ESP
  • Applies the appropriate encryption algorithm and encrypts the ESP
  • Encapsulates the now encrypted ESP frame in a cleartext IP datagram as the last payload.

The inner IP header carries the ultimate source and destination addresses. The outer IP header is unencrypted and can contain intermediate addresses such as security gateway addresses.

In tunnel mode, the transmitter encapsulates and encrypts the entire original IP datagram. This includes the padding, pad length, and Next Header. If authentication is to be part of the communication session, ESP performs the encryption before authentication. Note that authentication data field is not encrypted during this process. Processing a datagram in this order means the receiver can detect and reject replayed or bad packets before decrypting the packet.

Various protocols use the information in the unencrypted IP header to route the secure datagram from origin to destination. An unencrypted IP routing header might be included between the IP header and the Encapsulating Security Payload.

In tunnel mode inbound datagrams:

  • Checks the security policy for the datagram
  • Selects the correct security association according to the SPI field in the datagram and locates the correct session key
  • Strips off the cleartext IP header and cleartext optional IP payloads
  • Uses the session key and applies the appropriate decryption algorithms to the encrypted ESP

If the receiver fails to find the session key for the packet, it discards the encrypted ESP and logs the failure in the system or audit log.

If decryption succeeds, the contents of the decrypted ESP part is the original datagram

  • Removes the original IP datagram from the ESP and processes the datagram using normal IP datagram processing

The diagram shown in illustrates ESP tunnel mode positioning for a typical IPv4 and IPv6 packet.

ESP and sensitivity labeling

IPv6 normally uses implicit sensitivity label rather then the explicit ones used in IPV4. The SPI indicates the sensitivity level. The encrypted IP datagram usually does not contain any explicit sensitivity label. Explicit sensitivity labeling is not a requirement. This is an improvement over the current practices with IPv4 that normally uses an explicit sensitivity label for systems requiring security labels.

In some cases an organization might choose to support explicit labeling, such as IPSO labels, for IPv6 communications in addition to using the implicit labels provided by ESP. The specific implementation could define the explicit label options using the IPv6 End-to-End Options Header or the IPv6 Hop-by-Hop Options Header.

NOTE:

Implementations of ESP in systems that claim to provide multilevel security are required to support implicit labels.

Different ways to use IPsecurity mechanisms

There are a number of possible way to use the IP security mechanisms to reduce security risks. This section describes some implementation of IP security in different environments to show you how you might use IP security mechanisms in your own environment.

IPSec use with firewalls

Many organization use firewalls to protect the organization’s computers from the very real threat of a hacker attack through the Internet. Indeed, firewalls are quite common on the Internet even though may dislike their presence because they restrict connectivity. A firewall is a gateway usually consisting of a dedicated computer equipped with safeguards that acts as a single internet connection for an organization. Information secured behind a firewall is generally inaccessible to users of the Internet.

You can use both AH and ESP on the gateway to increase the protection provided by the firewall. A firewall needs to be able to parse the header of incoming packets to determine weather to use the TCP or UDP protocol and which port number for that protocol to use

A firewall can use AH even if the firewall is not involved with the security association. However, in this case, decrypting an upper-layer protocol fails. The firewall will be unable to view the protocol or port number needed to:

  • Perform per-packet filtering
  • Verify that the data being used for access control decisions is correct and authentic

This means that authentication might be performed within an organization or campus and also end to end with remote systems across the Internet. Using AH with IP provides assurance that the data being used for access control decisions is authentic.

Firewalls and tunneling

An organization might want to use a selectively encrypting firewall to protect the company’s sensitive traffic from eavesdropping and modification. Lets say that our sample organization has several sites that are interconnected using a commercial IP service provider. In this case, the company would place an encrypting firewall between each of its sites and its IP service provider. The firewall could provide an encrypted IP tunnel between the company sites; and if the company elected to do so, with designated suppliers, power customers, and subsidiaries. The company would be free to choose not to encrypt traffic to other organizations and sites on the internet to improve network performance and connectivity but still protect its sensitive data.

Tunneling refers to the practice of encapsulating a message from one protocol in another protocol and using the second protocol to transverse a number of network hops. At the destination, the encapsulation is stripped off and the original message is reintroduced to the network at its destination. shows User A tunneling through the organizations firewall and communicating securely with User B who in on a network outside of the organization.

Fully encrypting firewall

A fully encrypting firewall can be used to provided a protected virtual network that transverses a commercial IP service. A fully encrypting firewall filters decrypted traffic and provides encryption services for IP packets.

IPSec use with IP multicast

A quick search on the Internet reveals a whole body of information and substantial activity about IP multicasting and the MBone. MBone stands for the IP Multicast Backbone on the Internet. In this context and for IPv4, IP-Multicast is the class-D addressing scheme in IP developed by Steve Deering at Xerox PARC. Class-D IP addresses range from 224.0.0.0 to 239.255.255.255. IANA has allocated the address range of 224.2.*.* for MBone based audio video conferences. These addresses are routed through standard IP routers with multicast routing support.

Numerous organizations are now:

  • Multicasting conferences and meetings with real time audio, video, and whiteboards.
  • Teleconferencing using IP multicast based applications on an Intranet and the Internet
  • Using IP multicast for distributed simulation
  • Using IP multicast to deliver time critical information to special groups throughout the organization and indeed sometimes to the entire organization.

Most IP routers in the market today support multicast routing. And there are numerous local, regional, national, and international IP multicast Services providers. MBone and IP multicasting is not going away any time soon. IPv6 is ideally suited for IP multicasting as a method of communication.

It is increasingly important that the security mechanisms in IP be suitable for use in an environment where multicast is in general use. The receiver-oriented nature of an SPI makes it quite suitable for use in IP multicasting. There is a great deal of active research going on in the area of IP multicast security. However, most currently published multicast key distribution methods do not scale well for large scale implementations of IP multicasting.

In the meantime:

  • A multicast group could repeatedly use a secure unicast key distribution protocol to distribute the key to all members
  • A multicast group could pre-arrange keys by using a manual key distribution mechanism.

IPSec use in multilevel secure networks

Many government and private organizations use multilevel secure networks to protect sensitive data. A multilevel secure (MLS) network is one where a single network communicates data at different sensitivity levels such as the IPSO levels of UNCLASSIFIED, CONFIDENTIAL, SECRET, and TOP SECRET. In such a network, a user can not control or violate the strong access controls that are in place at all security levels of the network.

Using AH with multilevel secure networks

IPv6 normally use implicit sensitivity labels. Although part of the security association, implicit sensitivity labels are not transmitted with each packet.

You can use AH to provide strong assurance for mandatory and discretionary access control decisions in multilevel networks. You can use AH to authenticate an entire packet If the multilevel implementation uses explicit sensitivity labels and confidentiality is not needed in the particular environment. The AH authentication include cryptographic binding of the sensitivity level to the IP header and user data. The IP Security protocols require the authentication of all IP sensitivity labels using either ESP, AH, or both.

NOTE:

In IPv4 there is no authentication or cryptographic binding of the label to the IP header and user data. This means that in labeled IPv4 networks the label is trusted even though it is not trustworthy

Using ESP With Multilevel Secure Networks

When you combine ESP and appropriate key polices to provide multilevel secure networking.

When you use ESP with multilevel secure networking you use a separate key for each sensitivity level. For example, you would use one key for an IPSO secret level packet and another key for a top secret level packet.

The sensitivity level of the key should be the same as the sensitivity level of the security association. Note that the AH can also have different keys depending on the sensitivity level of the packet. Even if a network environment is protected, you should use full encryption for all communications between multilevel computers.

IPSec notes, cautions, and precautions

The quality of security provided by the IP security protocols depends on a number of factors. The cryptographic algorithm and key strength play an important role in IP security as does the implementation of the protocols and key management in all of the participating systems. The correctness of the algorithm's implementation is equally important. The security of an IPv6 (or IPv4) implementation depends partly on the security of the operating system on which the IPv6 is running. For example, if an fails to keep all symmetric keys and all private asymmetric keys secure, then any communication using those keys is insecure.

Encapsulating Security Payload protocol used alone or in combination with the Authentication Header protocol provides for confidentiality.

Randall Atkinson in RFC 1826 describes a potential security problem with a large packet that causes an ICMP error; the packet may be to large to fit in the ICMP error message. This means the receiving host would probably do one of two things:

  • Trust an unauthenticated ICMP message. This could create security problems.
  • Not trust the ICMP message. This means the host could react inappropriately to a legitimate ICMP message.

Similar security risks can occur if an encrypted packet causes an ICMP error message and that packet is truncated.

Using IP tunneling with the Authentication Header protocol can create multiple pairs of endpoints. Such pairs of endpoints could perform Authentication Header processing. When implementing IPv6, pay careful attention to the impact of tunneling on the authenticity of tunneled IP packets.

Use of user-oriented keying is recommended to prevent any kind of chosen plaintext attack. If you do not implement user-oriented keying choose your keying algorithm carefully. Make sure that the algorithm in use is not vulnerable to any kind of Chosen Plaintext attack.

Limitations of the IPSec mechanisms

The IPsec has some security limitations including lack of:

  • Traffic analysis services. It is important to note that these IP-layer mechanisms do not provide security against a number of traffic analysis attacks. Indeed, it is questionable if meaningful protection from traffic analysis can be provided economically at the Internet Layer.

While ESP provides limited traffic flow confidentiality, use other types of security, such as bulk link encryption, for protection against traffic analysis. You could also send false traffic in order to increase the noise in the data provided by traffic analysis.
  • Non-repudiation services. Neither AH nor ESP provides non-repudiation when used with keyed MD5 and DES algorithms. Other algorithms , if use with appropriate transformation might provide non-repudiation services. Non-repudiation should be concerned with the application layer security.
  • Replay Attack Services. The AH keyed MD5 (RFC 1828) [12], AH keyed SHA (RFC 1852) [13], ESP DES DBC (RFC 1829) [6], or ESP Triple-DES (RFC 1851) [7] transformations do not protect against replay attacks. ESP transformation.

Upper protocol layers can also provide protection against replay attacks
  • Denial of services. The IP security mechanism do not provide protection against all of the known Denial of Service attacks. For example, AH and ESP can not protect against a power loss caused by an enemy.

Security services for upper layers

Upper layer secure applications can use the IP security mechanism. Secure applications can request to send and receive authenticated and encrypted IP datagrams.

The use of IP security mechanism by upper layer secure applications requires the presence of:

  • User-oriented keying in a multi-user environment
  • Security service support from the network programming interfaces

The network programming interface support might be new options to the sockets or security API.

Summary of IPSec requirements

This section summarizes the requirements for IPv6 and IPv4 configurations that implement IP security using AH, ESP, or both.

Security Associations. It is:

  • Required that all implementations support manual configuration of security associations
  • Recommended that all implementations support an Internet standard Security Association Protocol when one is published as an Internet standards-track RFC
  • Suggested that all implementations can optionally support other means of configuring security associations
  • Required that all implementations be able to have more than one concurrent security association for communications between two endpoints
  • Recommended that multi-user hosts support user-oriented security associations

Security labels. It is

  • Required that implementations of ESP in systems claiming to have multilevel security support implicit labels
  • Required that implementation claiming to have multilevel security support authenticate all explicit IP sensitivity labels (IPSO labels) using either ESP, AH, or both

Key distribution. It is:

  • Required that all implementations support manual key distribution
  • Required that all implementations support for automated keying through Oakley/ISAKMP

Keying methods. It is

  • Required that all implementations permit the configuration of host-oriented keying
  • Suggested that dedicated IP encrypting devices such as a security gateway can optionally support user-oriented keying for traffic originating on other systems. Typically such a device cannot generally provide user-oriented keying for traffic originating on other systems.

Key protection. It is

  • Required that all implementations take reasonable steps to protect keys and other security association information from unauthorized examination or modification.

Algorithms. It is:

  • Required that ESP compliant implementations support at a minimum:
  • DES in CBC mode
  • HMAC with MD5
  • HMAC with SHA-1
  • Required that AH compliant implementations support at a minimum:
  • HMAC with MD5
  • HMAC with SHA-1
  • Suggested that implementations of AH and ESP can optionally support other authentication and encryption algorithms

IPSec, Secure Socket Layer Security, or both

The IPv6 security mechanisms reside in the TCP/IP layered model’s Internet Layer (often referred to as the IP layer). The Secure Socket Layer (SSL) protocol is a TCP/IP Transport layer protocol. References to a layer in this chapter use the TCP/IP layered model nomenclature.

IPv6 security mechanisms handle everything above the Internet layer equally. IPv6 has no notion of the transport layer protocols TCP and UDP. The concept of port numbers upon which upper layer protocols depend is meaningless to IPv6. IPv6 also works with non transport protocols like ICMP. The IPv6 security mechanisms authenticate and encrypt packets without regard to what the packets contain.

The advantage of the SSL Protocol is that it is application protocol independent. A higher level application protocol such as. HTTP, FTP, and TELNET can layer on top of the SSL Protocol transparently. SSL works with reliable transport protocols such as TCP. The IANA has assigned SSL specific port numbers that are dependent on the application protocol to which the implementation of SSL is associated; for example:

  • HTTP, the HyperText Transfer Protocol (typically port 443)
  • SMTP, the Simple Mail Transfer Protocol (typically port 465)

With its location on a lower layer, IPv6 provides a different level of security as it can encrypt information from the layers above. This means information such as port numbers is not available to traffic analysis and an encrypted TCP packet can be encapsulated within an encrypted IP datagram.

compares the position and nomenclature for the TCP/IP layer model and the Open System Interconnection (OSI) layer model for computer communications.

Typical use of SSL and IPSec features

From a users point of view, both IP and the SSL security mechanism do roughly the same thing; each one provides data confidentiality and authentication. From the network point of view, you can use IPv6 security mechanisms for host-to-host, host-to-subnet, and subnet-to-subnet communications. However, you can use the SSL security mechanism only for host-to-host communications.

IP security mechanism provide the possibility of encryption, authentication, or a combination of both. This means encryption can occur between two hosts or two gateways when communication transverses the internet. Traffic within a corporate network can go unencrypted because traffic gets encrypted at the IP level by the router as it leaves the local network.

The SSL security mechanism provides the possibility of confidentiality and authenticity only between two hosts or typically between a host and a server. A Host to Subnet or Subnet to Subnet application is not possible as SSL provides its features only for defined ports.

In either case, If you implement security mechanisms on your network you need to have:

  • A carefully designed local network
  • Clearly defined gateways to the Internet
  • Support for the same version of the protocol (IPv4, IPv6, or SSL) on both sides of the connection.

IPSec and SSL key exchange options

IPv6 does not have built in key exchange capabilities. The current key management options required for both AH and ESP are manual keying and automated keying. There are two proposed methods for managing keys over the Internet: the Simple Key-Management for Internet Protocols (SKIP) and ISAKMP (Internet Security Association & Key Management Protocol) + Oakley. The Oakley (for the cowgirl Annie Oakley) Key Determination Protocol portion provides for key exchange mechanism. ISAKMP provides for security association and key management.

The actual method to be employed for IPv6 implementations is unresolved. At this point, ISAKMP is required for IPv6 with SKIP as an option. IP secure implementations of IPv4 can use either ISAKMP or SKIP.

In addition, key exchange can occur through the Domain Name System Security Extensions protocol (RFC 2065) which supports signed host keys. It can also support a number of protocols within the Internet protocol suite; not just the IP security protocols.

Work is still continuing within the IETF to fully specify a protocol and cryptographic techniques that will support the key management requirements of IPv6. Until there is widespread adoption of a public key management standard, IPv6 security can be used only on a very limited basis; manual key exchange is not realistic in large networks and particularly not on the Internet.

SSL uses public/private key pairs and has built in key exchange capabilities. The SSL Protocol can negotiate an encryption algorithm and session key as well as authenticate a server before the application protocol transmits or receives its first byte of data. It supports both server and client key exchange messages. When a master key is needed, the SERVER-HELLO message contains enough information for the client to generate it. This message includes the server’s public key and a list of ciphers the server supports.

Each SSL endpoint uses a pair of ciphers for a connection. One pair is used for outgoing communications, and one is used for incoming communications. The client and server use the master key to generate the various sessions keys. When both client and server have finished exchanging messages, the handshake is completed and the application protocol begins to operate. The application protocol is layered on the SSL protocol. After the pair of session keys has been determined by each party, the protocol encrypts message bodies with the session key using a Message Authentication Code (MAC). A MAC uses an encryption process to create an authentication code that prevents a hacker from modifying any data in a packet, including the source address field.

The SSL protocol provides a secure channel between the communicating pair. A secure channel generally has the following properties:

  • The channel is private. The SSL protocol uses encryption for all messages after using a simple handshake to define a secret key.
  • The channel is authenticated. The protocol always authenticates the server endpoint of the conversation. The protocol optionally authenticates the client endpoint.
  • The channel is reliable. The protocol uses a message transport that includes a message integrity check.

With this capability of key exchange, you can use SSL for spontaneous secure communications between a Server and a Client. For example you could use SSL for secure WWW Internet connections where passwords or credit card numbers have to cross the Internet.

IPSec and SSL ciphers

IPv6 as well as SSL are cipher independent. This means you change the protocol in use for a more sophisticated encryption algorithm if the need arises or government regulations change to allow stronger encryption. Cipher attacks are getting more successful for small keylength

At a minimum AH requires HMAC with MD5 or SHA-1 and ESP requires DES CBC with a 56 bit key and HMAC with MD5 or SHA-1.

IPv6 chose the DES CBC cipher mainly for Internet compatibility. Note that the DES CBC cipher is potentially weak and vulnerable to attacks. It might be a better choice to use triple DES (3DES) as this cipher offers significantly more confidentiality and should be able to resist attacks in the near future. . Refer to for the algorithms that both IPv6 and SSL define.

Authentication

Both IPv6 and SSL protocols rely on the same default authentication algorithm; both use MD5. The algorithms yield a 128 bit key length. The IP security mechanism make the authentication of IPv6 resistible to attack from hackers who can find two chosen texts with a common MD5 hash value.

The main difference between the two authentication possibilities lies on the different levels on which they work. SSL works on the transport layer; IPv6 works on the Internet layer. The IP security can be used to eliminate some network attacks including host masquerading and IP address spoofing.

IP address spoofing allows an unauthorized user to masquerade as an approved user to break into your network. The hacker steals an authorized IP address and uses it to hide his identity.

IPv6 authentication provides authentication to the source and destination address as well as to the upper layer protocols, while SSL provides authentication to the transport layer and above.

Encryption

As both protocols use the same possible encryption algorithms although they operated on different layers of the TCP/IP model. SSL only has the option to encrypt the whole packets such as HTTP, FTP or SMTP. The IP security mechanism two possibilities to provide confidentiality: tunnel mode ESP and Transport mode ESP.

In tunnel mode, the protocol encrypts the original IP datagram included its header and places this in a new datagram with an unencrypted IP header. The receiver strips off the cleartext IP header and decrypts the ESP. The protocol then uses the header of the decrypted packet to route the packet to the recipient.

In transport mode the protocol encrypts only the payload. The protocol uses the unencrypted IP header and IP options for routing the packet. . The receiver decrypts the ESP and uses the unencrypted header as the IP header if further communication is necessary.

The transport mode ESP provides approximately the same capabilities as the SSL protocol. The major differences is that transport mode provides its services to all packets, while SSL provides its services only to defined port addresses.

Even when you use encryption the address and control information portions of the IP packet must not be scrambles so that the packet can be routed across the Internet.

NOTE:

Even encrypted packets are at risk to spoofing attacks and, firewalls do not protect against address spoofing attacks.

Using SSL and IPv6 security together

There is nothing to preclude using SSL simultaneously with IPv6 security mechanisms. IP can provide its services to all packets above the Network Layer. IPv6 is universally usable without being limited to the type of payload. SSL can provide only authentication and confidentiality to protocols using defined port numbers. SSL will certainly continue to have its applications in Web browsers. SSL will have its use in Internet transactions as a probably secure transmission can be made without prior knowledge of the private key of the client

There have been at least seven revisions of the proposed ISAKMP protocol. Because of this flux, selecting an Internet key management security system is currently challenging. SSL has a proven key exchange mechanism already in place.

In general, every security specification is only as secure as its implementation in the final product. IPv6 offers a high standard for probably secure transmissions over network but no protocol or application can guarantee a 100% secure way for transmitting information over networks.

Extranets, virtual private networks, and security

The extranet represents the bridge between the public Internet and the private corporate Intranet. An extranet refers to an Intranet that is partially accessible to authorized business partners, vendors, and other qualified outsiders. An extranet can be viewed either as part of a company's Intranet that is made accessible to other companies or as a collaborative Internet connection with other companies.

Examples of extranet applications include:

  • Private newsgroups that several companies use to share new, experiences, and ideas
  • Groupware where several companies collectively develop new application programs they can all use
  • Training programs that companies develop and share
  • Shared product catalogs accessible only to wholesalers or honored customers
  • Project management for companies or diverse groups that are part of a common work project

Sometimes referred to as a Virtual Private Network (VPN) an extranet is usually constructed by using public wires to connect nodes. Typically, extranets are implemented as logical overlays defined only by access privileges and routing tables. You can also view an extranet as an intersection set of a number of different company Intranets. A single corporate Web site, a database, or an application can reside on all three networks: the Internet, the Intranet, and the extranet;. The network in use depends on who is accessing the network and what security privileges are being used.

Security is what makes the extranet. These systems use encryption and other security mechanisms to ensure that only authorized users can access the network and that the data cannot be intercepted. Security and privacy can be obtained either by ensuring that the transmission lines are privately owned or leased, or by using the Internet with password authorization, or by tunneling through the Internet.

Tunneling works by encapsulating a network protocol within packets carried by the second network. A VPN connects several separate local area networks (LANs) together with encrypted point to point tunnels. Each LAN can have a firewall or a router separating it from the Internet.

Specialized routers can encrypt TCP/IP packets for transport over insecure communications networks. Secure Extranets are a fast-growing segment of the Internet because they are much less expensive to build and manage than private networks based on proprietary protocols. The rapid increase in Extranets highlights the critical need for strong authentication, encryption and nonrepudiation services on the World-Wide Web.

Usually you can access an VPN only if you have a valid user name and password. Your authentication credential determine which parts of the extranet you can access. However, if sensitive information or applications need to be accessed over the network, security features such as protocol tunneling and public -key certificates will be needed.

Protocol tunneling means protocol packets can be encrypted, encapsulated, and delivered to a remote Intranet firewall. The packets are decrypted at the remote network and sent on to their destination on the remote Intranet as shown in. Depending on the implementation, encryption/decryption can take place at the firewall or at a security server.

Open industry standards have been defined, but none of them has achieved the widespread acceptance necessary for open extranets to flourish.

Tunneling standards

The existing open tunneling standards include:

IPSec ¾ A network-level authentication, data integrity, and encryption standards defined in RFCs 1826 and 1827 and described previously in this chapter.

Point-to-Point Tunneling Protocol (PPTP)¾ An extension to the PPP developed by Microsoft Corporation along with firewall, router, and remote access server manufactures. This protocol runs over Microsoft Windows NT 4.0 and supports IP tunneling as well as IPX and NETBEUI tunneling inside IP packets.

Layer 2 Tunneling Protocol ¾ This proposed Internet standards combines the PPTP standard with Cisco’s Layer 2 Forwarding technology.

Virtual Tunneling Protocol ¾ This proposed Internet standard uses IPSec as the underlying security mechanisms.

Successful secure tunneling will be an important feature of tomorrow’s IPv6 networks and indeed should be an integral part of any transition plan. It is a good idea to test your current routers and firewalls for their tunneling capabilities and for bilateral interoperability. Future firewalls and routers should support tunneling and the evolving IPSec protocols for the Internet.

An Extranet check list

Successful secure tunneling will be an important feature of tomorrows IPv6 networks and indeed should be an integral part of any transition plan. It is a good idea to test your current routers and firewalls for their tunneling capabilities and for bilateral interoperability. Future firewalls and routers should support tunneling and the evolving IPSec protocols for the Internet.

A number of applications exist on the market today to help implement and manage VPN. You can use the following checklist () to help you determine the capabilities that you will need in an extranet implementation.

From here…

This chapter showed you how the different parts of the IPsec protocol suite work, described how you might use the various IP security mechanisms, and listed some basic IP security requirements. For additional information, you may want to see the following:

  • Chapter XX, "IPv6 Key Management Issues and Protocols" talks about different key management methods, the IPv6 key management requirements, and some of the key management protocols under considerations for IPv6 implementations.
  • Appendix C, Appendix D, and Appendix E talk the role of the TCP/IP Internet layer, Transport layer, and Application layer protocols.
  • Chapter 13 "Migration Issues" talks about interim options to make the migration from IPv4 to IPv6 smoother
Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)