Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

device address must still be translated as in regular NAT because 18.0.0.18 is not a valid

public address for us. It may refer to a real machine in MIT and we aren't supposed to be

using it on the Internet!

Let's say that we are still using the pool of 20 inside global addresses from 194.54.21.1

through 194.54.21.20 for inside addresses, and let's further suppose the NAT router

chooses 194.54.21.12 for this particular exchange. The transaction sequence would be

roughly as described in Table 78, and illustrated in Figure 115.

As you can see, in this example the outside local and outside global addresses are

different, unlike in the preceding NAT examples. Twice NAT can also handle an inbound

transaction, by watching for datagrams coming in from the Internet that overlap with the

addresses used on the local network and doing double substitutions as required.

Table 78: Operation Of “Overlapping” NAT / “Twice NAT”

Step

Description

Data-

gram

Type

Datagram

Source

Address

Datagram

Destination

Address

Inside Client Generates Request And Sends

To NAT Router: Device 18.0.0.18 generates a

request using the destination 172.16.44.55 that it

got from the (NAT-intercepted) DNS query for

“www.twicenat.mit.edu. The datagram is sent to

the NAT router for the local network.

Request

(from

inside

client to

outside

server)

18.0.0.18

(Inside Local)

172.16.44.55

(Outside Local)

NAT Router Translates Source Address And

Destination Address and Sends To Outside

Server: The NAT router makes two translations.

First, it substitutes the 18.0.0.18 address with a

publicly registered address, which is

194.54.21.12 for this example. It then translates

the bogus 172.16.44.55 back to the real MIT

address for “www.twicenat.mit.edu”. It routes the

datagram to the outside server.

194.54.21.12

(Inside Global)

18.1.2.3

(Outside Global)

Outside Server Generates Response And

Sends Back To NAT Router: The MIT server at

18.1.2.3 generates a response and sends it back

to 194.54.21.12, which causes it to arrive back at

the NAT router.

Response

(from

outside

server to

inside

client)

18.1.2.3

(Outside Global)

194.54.21.12

(Inside Global)

NAT Router Translates Source Address And

Destination Address And Delivers Datagram

To Inside Client: The NAT router translates back

the destination address to the actual address

being used for our inside client, as in regular NAT.

It also substitutes back in the 172.16.44.55 value

it is using as a substitute for the real address of

“www.twicenat.mit.edu”.

172.16.44.55

(Outside Local)

18.0.0.18

(Inside Local)

Key Concept: “Overlapping” NAT is used in situations where both the source and

destination addresses in a datagram are private addresses or otherwise cannot be

used regularly on the public Internet. In this case, unlike the other types of NAT, the

NAT router translates both the source and destination addresses of incoming and outgoing

datagrams. On outgoing messages, inside local addresses are changed to inside global

and outside local to outside global; on incoming messages, inside global addresses are

changed to inside local and outside global to outside local.

IP NAT Compatibility Issues and Special Handling Requirements

In a perfect world, Network Address Translation could be made transparent to the devices

using it. We'd like to be able to have a NAT router change IP addresses in request

datagrams as they leave the network and change them back in responses that come back

and have none of the hosts be any the wiser. Unfortunately, this ain't a perfect world.

Figure 115: Operation Of “Overlapping” NAT / “Twice NAT”

This figure is very similar to Figure 112, except that the as you can see, both source and destination

addresses are translated by the NAT router each time (shown in bold). Table 78 contains a complete expla-

nation of the four steps in “overlapping” NAT. Refer to Figure 111 for an explanation of address types.

Source 18.0.0.18

Destination 172.16.44.55

Request

Source

194.54.21.12

Destination

18.1.2.3

Translated Request

Source

172.16.44.55

Destination

18.0.0.18

Translated Response

Source 18.1.2.3

Destination 194.54.21.12

Response

1. Client Sends Request

2. NAT Router Translates

Source & Destination Addresses

NAT

Router

3. Server Sends Response

Internet

4. NAT Router Translates

Source & Destination Addresses

Client

18.0.0.18

Server

18.1.2.3

Local Network

("Inside")

Public Internet

("Outside")

Inside Local Address

Outside Local Address

Inside Global Address

Outside Global Address

It is not possible for NAT to be completely transparent to the devices that use it. There are

potential compatibility problems that arise if NAT doesn't perform certain functions that go

beyond simply swapping IP addresses and possibly port numbers in the IP header. The

main problem is that even though IP addresses are supposedly the domain of the Internet

Protocol, they are really used by other protocols as well, both at the network layer and in

higher layers. When NAT changes the IP address in an IP datagram, it must often also

change addresses in other places to make sure that the addresses in various headers and

payloads still match.

These compatibility issues require that even though NAT should theoretically work only at

the level of IP at the network layer, in practical terms NAT routers must be “aware” of many

more protocols and perform special operations as required. Some are required for all

datagrams that are translated, while others only apply to certain datagrams and not others.

And even when these techniques are added to NAT routers, some things still may not work

properly in a NAT environment.

Most NAT implementations do take these concerns into account. Certainly common appli-

cations like FTP are widely supported by NAT routers, or nobody would want to use NAT.

That said, there may be some applications that will not work over NAT. The fact that NAT

really isn't transparent and must do these extra sorts of “hacks” to other protocol headers

and even payloads is a big part of the reason why many people refer to NAT as a “kludge”;

elegant solutions don't have so many special cases that need special handling.

Let's take a look at some of the specific issues and requirements.

TCP and UDP Checksum Recalculations

Changing the IP addresses in the IP header means the IP header checksum must be calcu-

lated. Since both UDP or TCP also have checksums, and these checksums are computed

over a pseudo header that contains the IP source and destination address as well, they too

must be recalculated each time a translation is made.

ICMP Manipulations

Since NAT works so intimately with IP headers, and since IP is closely related to its

“assistant” protocol ICMP, NAT must also look for certain ICMP messages and make

changes to addresses contained within them. Many ICMP messages, such as Destination

Unreachable and Parameter Problem contain as data the original IP header of the

datagram that led to the ICMP message. Since NAT is translating addresses in IP headers

it must watch for these messages and translate addresses in included headers as required.

Applications That Embed IP Addresses

A number of TCP/IP applications embed IP addresses within the actual application data

payload. The most notorious example of this is the TCP/IP File Transfer Protocol (FTP),

which actually sends address and port assignments as text information in datagrams

between devices during a connection. In order for NAT to support FTP, it must be specifi-

cally programmed with algorithms to look for this information and make changes as needed.

The level of complication can go even beyond this. Consider what happens when an FTP

message containing these text address or port numbers is fragmented—part of the address

to be translated may be in two different IP datagrams, and hard to recognize!

Additional Issues With Port Translation

When port-based NAT (PAT) is used, the issues that apply to addresses now apply to ports

as well, making even more work for the router to perform.

Cascading Impact Of Changes To Address Or Port Numbers

Take the example of an FTP datagram encoding an IP address that NAT must change. The

address being substituted might require more characters than the original; in our first

example, 10.0.0.207 (10 ASCII characters) is replaced by 194.54.21.11 (12 ASCII

characters). Making this substitution changes the size of the payload! This means that TCP

sequence numbers also must be modified.

In these situations, NAT itself is supposed to take care of any additional work that may be

required. This is definitely a complication that does not occur without the use of NAT, and is

an often-cited example of NAT’s “kludginess”.

Problems With IPSec

When IPSec is used in transport mode, both the Authentication Header (AH) and Encapsu-

lating Security Payload (ESP) protocols use an integrity check that is based on the value of

the entire payload. When NAT tries to update the TCP or UDP checksum in the IP

datagram, this changes the value of data that the receiving device uses in performing the

AH or ESP integrity check. The check will fail. Thus, NAT can't be used in IPSec transport

mode. It may still work in tunnel mode but there can be complications here as well.

IP Security (IPSec) Protocols

One of the weaknesses of the original Internet Protocol is that it lacks any sort of general

purpose mechanism for ensuring the authenticity and privacy of data as it is passed over

the internetwork. Since IP datagrams must usually be routed between two devices over

unknown networks, any information in them is subject to being intercepted and even

possibly changed. With the increased use of the Internet for critical applications, security

enhancements were needed for IP. To this end, a set of protocols called IP Security or

IPSec was developed.

In this section I provide a brief description of IPSec concepts and protocols. I begin with an

overview of IPSec, including a discussion of the history of the technology and defining

standards. I describe the main components and protocols of the IPSec suite, and its

different architectures and methods for implementation. I then move to actually discussing

how IPSec works, beginning with a description of the two IPSec modes (transport and

tunnel) and how they differ. I describe security associations and related constructs such as

the Security Parameter Index (SPI). The last three topics cover the three main IPSec

protocols: IPSec Authentication Header (AH), IPSec Encapsulating Security Payload (ESP)

and the IPSec Internet Key Exchange (IKE).

Note: IPSec was initially developed with IPv6 in mind, but has been engineered to

provide security for both IPv4 and IPv6 networks, and operation in both versions is

similar. There are some differences in the datagram formats used for AH and ESP

depending on whether IPSec is used in IPv4 and IPv6, since the two versions have different

datagram formats and addressing. I highlight these differences where appropriate.

Note: There are many subjects in this Guide that are so involved that many large

books have been written about them. Security on IP networks and IPSec is

definitely in this category. Due to the already large size of this Guide and the

complexity of IPSec, I can only provide here a very limited description of how it works. For

more comprehensive information you will need to supplement with a reference specific to

this technology.

IPSec Overview, History and Standards

The best-known problem with the original Internet Protocol (IPv4) is the pending exhaustion

of its address space. This situation arose due to the rapid expansion of the Internet beyond

anyone's expectations when IPv4 was developed. This same mismatch between how the

Internet was when IPv4 was created and how it is now has led to another major problem

with IP: the lack of a definitive means of ensuring security on IP internetworks.

The security problem arose because 25 years ago, the Internet was tiny and relatively

“private”. Today it is enormous and truly “public”. As the Internet has grown, the need for

security has grown with it. Consider that TCP/IP and the early Internet precursors were

developed as very small networks used by government researchers at the United States

Defense Advanced Research Projects Agency (DARPA or ARPA). All the hardware was

controlled by people who were well known and would generally have had security

clearance. In such a network, you don't need to build security in to the protocols—you build

it into the building! It's easier to use locks and guards to ensure security than fancy

encryption, when you can get away with it. After all, the easiest way to keep someone from

snooping or tampering with data on the network is simply to deny them access to the hosts

that connect to the network.

This worked fine at first when there were only a few dozen machines on the Internet. And

even when the Internet first started to grow, it was used pretty much only to connect

together researchers and other networking professionals. New sites were added to the

network slowly at first, and at least someone knew the identity of each new site added to the

growing internetwork. However, as the Internet continued to increase in size and eventually

was opened to the public, maintaining security of the network as a whole became impos-

sible. Today, the “great unwashed masses” are on the Internet. Many routers—owned by

“who knows” and administered by “who knows”—stand between you and most other

devices you want to connect with. You cannot assume that the data you send or receive is

secure.

A number of methods have evolved over the years to address the need for security. Most of

these are focused at the higher layers of the OSI protocol stack, to compensate for IP's lack

of security. These solutions are valuable for certain situations, but they can't be generalized

easily because they are particular to various applications. For example, we can use Secure

Sockets Layer (SSL) for certain applications like World Wide Web access or FTP, but there

are dozens of applications that this type of security was never intended to work with.

What was really needed was a solution to allow security at the IP level so all higher-layer

protocols in TCP/IP could take advantage of it. When the decision was made to develop a

new version of IP (IPv6), this was the golden opportunity to resolve not just the addressing

problems in the older IPv4, but the lack of security as well. New security technology was

developed with IPv6 in mind, but since IPv6 has taken years to develop and roll out, and the

need for security is now

, the solution was designed to be usable for both IPv4 and IPv6.

The technology that brings secure communications to the Internet Protocol is called IP

Security, commonly abbreviated IPSec (The capitalization of this abbreviation is variable,

so IPsec and IPSEC are also seen. Though not IpSeC or IPseC, fortunately. ☺)

Overview of IPSec Services and Functions

IPSec is not a single protocol, but rather a set of services and protocols that provide a

complete security solution for an IP network. These services and protocols combine to

provide various types of protection. Since IPSec works at the IP layer, it can provide these

protections for any higher layer TCP/IP application or protocol without the need for

additional security methods, which is a major strength. Some of the kinds of protection

services offered by IPSec include:

☯ Encryption of user data for privacy.

☯ Authentication of the integrity of a message to ensure that it is not changed en route.

☯ Protection against certain types of security attacks, such as replay attacks.

☯ The ability for devices to negotiate the security algorithms and keys required to meet

their security needs.

☯ Two security modes, tunnel and transport, to meet different network needs.

Key Concept: IPSec is a contraction of IP Security, and consists of a set of services

and protocols that provide security to IP networks. It is defined by a sequence of

several Internet standards.

IPSec Standards

Since IPSec is actually a collection of techniques and protocols, it is not defined in a single

Internet standard. Instead, a collection of RFCs defines the architecture, services and

specific protocols used in IPSec. Some of the most important of these are shown in Table

79, all of which were published in November 1998:

Table 79: Important IP Security (IPSec) Standards

RFC

Number

Name Description

2401

Security Architecture for the

Internet Protocol

The main IPSec document, describing the architecture and

general operation of the technology, and showing how the

different components fit together.

2402 IP Authentication Header

Defines the IPSec Authentication Header (AH) protocol used for

ensuring data integrity and origin verification.

2403

The Use of HMAC-MD5-96

within ESP and AH

Describes a particular encryption algorithm for use by AH and

ESP called Message Digest 5 (MD5), HMAC variant.

(Obviously. ☺)

2404

The Use of HMAC-SHA-1-96

within ESP and AH

Describes a particular encryption algorithm for use by AH and

ESP called Secure Hash Algorithm 1 (SHA-1), HMAC variant.

(Naturally. ☺)

2406

IP Encapsulating Security

Payload (ESP)

Describes the IPSec Encapsulation Security Payload (ESP)

protocol that provides data encryption for confidentiality.

2408

Internet Security Association

and Key Management

Protocol (ISAKMP)

Defines methods for exchanging keys and negotiating security

associations.

The Future of IPSec

Deployment of IPSec has only really started to take off in the last few years; a major use of

the technology is in implementing virtual private networks (VPNs). It appears that the future

IPSec is bright, as more and more individuals and companies decide that they need to take

advantage of the power of the Internet, while also protecting the security of the data they

transport over it.

IPSec General Operation, Components and Protocols

I have a confession to make: I considered not writing about IPSec in this Guide. When you

find yourself writing a tome as large as this one, you lose stamina sometimes and there's

this urge to avoid writing about confusing subjects. ☺ IPSec isn't the only difficult topic in

this Guide but it is definitely a subject that baffles many because it's hard to get your hands

around. Most discussions of it jump straight to describing the mechanisms and protocols

without providing a general description of what it does and how the pieces fit together. Well,

I recognized that IPSec is important and I don't shy away from a challenge. Thus, here's my

attempt to provide a framework for understanding IPSec's various bits and pieces.

So, what exactly does IPSec do and how does it do it? In general terms, it provides security

services at the IP layer for other TCP/IP protocols and applications to use. What this means

is that IPSec provides the tools that devices on a TCP/IP network need in order to commu-

nicate securely. When two devices (either end user hosts or intermediate devices such as

routers or firewalls) want to engage in secure communications, they set up a secure path

between themselves that may traverse across many insecure intermediate systems. To

accomplish this, they must perform (at least) the following tasks:

1. They must agree on a set of security protocols to use, so that each one sends data in

a format the other can understand.

2. They must decide on a specific encryption algorithm to use in encoding data.

3. They must exchange keys that are used to “unlock” data that has been cryptographi-

cally encoded.

4. Once this background work is completed, each device must use the protocols,

methods and keys previously agreed upon to encode data and send it across the

network.

2409

The Internet Key Exchange

(IKE)

Describes the Internet Key Exchange (IKE) protocol used to

negotiate security associations and exchange keys between

devices for secure communications. Based on ISAKMP and

OAKLEY.

2412

The OAKLEY Key Determi-

nation Protocol

Describes a generic protocol for key exchange.

Table 79: Important IP Security (IPSec) Standards

RFC

Number

Name Description

IPSec Core Protocols

To support the activities above, a number of different components comprise the total

package known as “IPSec”, as shown in Figure 116. The two main pieces are a pair of

technologies sometimes called the core protocols of IPSec. These are the ones that

actually do the work of encoding information to ensure security. They are:

☯ IPSec Authentication Header (AH): This protocol provides authentication services

for IPSec. What this means is that it allows the recipient of a message to verify that the

supposed originator of a message was in fact the one that sent it. It also allows the

recipient to verify that none of the data in the datagram has been changed by any

intermediate devices en route. It also provides protection against so-called “replay”

attacks, where a message is captured by an unauthorized user and re-sent.

☯ Encapsulating Security Payload (ESP): The Authentication Header ensures integrity

of the data in datagram, but not its privacy. When the information in a datagram is “for

your eyes only”, it can be further protected using the ESP protocol, which encrypts the

payload of the IP datagram.

IPSec Support Components

AH and ESP are commonly called “protocols”, though this is another case where the validity

of this term is debatable. They are not really distinct protocols but are implemented as

headers that are inserted into IP datagrams, as we will see. They thus do the “grunt work” of

IPSec, and can be used together to provide both authentication and privacy. However, they

cannot operate on their own. For them to function properly they need the support of several

other protocols and services. The most important of these include:

Figure 116: Overview of IPSec Protocols and Components

IPSec Authentication

Header (AH)

Encapsulating Security

Payload (ESP)

IP Security Protocol Suite (IPSec)

Encryption/Hashing

Algorithms

Security Policies /

Security Associations

Internet Key Exchange

(IKE) / Key Management

IPSec Support Components

IPSec Core Protocols

☯ Encryption/Hashing Algorithms: AH and ESP are generic and do not specify the

exact mechanism used for encryption. This gives them the flexibility to work with a

variety of such algorithms, and to negotiate which is used as needed. Two common

ones used with IPSec are Message Digest 5 (MD5) and Secure Hash Algorithm 1

(SHA-1). These are also called hashing algorithms because they work by computing a

formula called a hash based on input data and a key.

☯ Security Policies and Associations, and Management Methods: Since IPSec

provides flexibility in letting different devices decide how they want to implement

security, some means is required to keep track of the security relationships between

devices. This is done in IPSec using constructs called security policies and security

associations, and by providing ways to exchange security association information (see

below).

☯ Key Exchange Framework and Mechanism: For two devices to exchange encrypted

information they need to be able to share keys for unlocking the encryption. They also

need a way to exchange security association information. In IPSec, a protocol called

the Internet Key Exchange (IKE) provides these capabilities.

Key Concept: IPSec consists of a number of different components that work

together to provide security services. The two main ones are protocols called the

Authentication Header (AH) and Encapsulating Security Payload (ESP), which

provide authenticity and privacy to IP data in the form of special headers added to IP

datagrams.

Well, that's at least a start at providing a framework for understanding what IPSec is all

about and how the pieces fit together. We’ll examine these components and protocols in

more detail as we proceed through this section.

IPSec Architectures and Implementation Methods

The main reason that IPSec is so powerful is that it provides security to IP, the basis for all

other TCP/IP protocols. In protecting IP, we are protecting pretty much everything else in

TCP/IP as well. An important issue, then, is how exactly we get IPSec into IP? There are

several implementation methods for deploying IPSec, which represent different ways that

IPSec may modify the overall layer architecture of TCP/IP.

IPSec Implementation Methods

Three different implementation architectures are defined for IPSec in RFC 2401. Which one

we use depends on various factors including the version of IP used (v4 versus v6), the

requirements of the application and other factors. These in turn rest on a primary implemen-

tation decision: whether IPSec should be programmed into all hosts on a network, or just

into certain routers or other “intermediate devices”.

This implementation decision is one that must be based on the requirements of the network.

There are two options: to implement IPSec in end hosts, or in routers.