Tải bản đầy đủ
8 AH Processing for Outbound Messages 25

8 AH Processing for Outbound Messages 25

Tải bản đầy đủ

26

Demystifying the IPsec Puzzle

must be agreed on. Until that happens, this message cannot be sent,
and the AH processing comes to a halt.
5. For a Transport Mode SA, change the preceding IP header’s Next
Header field to AH.
6. Add a tunnel header, if required. If the SA specifies Tunnel Mode,
the additional (outer) IP header must be constructed and added
to the message. The source and destination addresses of the outer
header are the tunnel endpoints, as specified by the SA.
If both headers are IPv4 headers, the following fields are copied
from the inner header to the outer header: Version, Type of Service, Protocol, Fragment Identification, MF (More/Last Fragment)
Flag, and Fragment Offset. The following fields are recomputed for
the outer header: Header Length, Total Length, and Header
Checksum; the recomputation is necessary so that these fields
incorporate information from both the inner and outer IP headers
and from the AH. The Next Header field is set to AH. The
Options field is not copied. The TTL is set to the system’s default
value. The local system’s policy also determines the value of the DF
(don’t/may fragment) Flag: It can be copied from the inner header,
set to 1 to prohibit fragmentation, or set to 0 to allow fragmentation. The fields of the inner header are left intact, with the following exception: If the source addresses of the inner and outer headers
differ, that means the inner packet has traveled to reach the tunnel’s
source address. In this case, the inner header’s TTL field is decremented and the inner header’s Header Checksum is recomputed to
reflect that change.
If both headers are IPv6 headers, the following fields are copied
from the inner header to the outer header: Version and Traffic
Class. The Payload Length field is recomputed for the outer header;
the recomputation is necessary so that this field incorporates the
lengths of both the inner and outer IP headers and the AH. The
Next Header field is set to AH or to the header type of the extension header that precedes the AH. The extension headers themselves are not copied. The hop limit is set to the system’s default
value. The fields of the inner header are left intact, with the following exception: If the source addresses of the inner and outer headers
differ, that means the inner packet has traveled to reach the tunnel’s
source address. In that case, the inner header’s Hop Limit field is
decremented.

The First Puzzle Piece: The Authentication Header

27

If the inner header is an IPv4 header and the outer header is an
IPv6 header, or vice versa, the processing is slightly different: The
Version field is set to 4 for the IPv4 header and to 6 for the IPv6
header; the Traffic Class field is transformed into TOS; and the
source and destination addresses are converted to the appropriate
format, if necessary.
7. Compute the authentication data. The authentication data consist
of the output of a keyed message hash. An algorithm (more on this
in Chapter 4) is used that takes a message of any size and generates a
fixed-length output, with the property that it is infeasible to modify
a message in such a way that the resulting hash of the modified message would be equivalent to that of the original message. Incorporating a secret key into the hash computations makes it impossible for
a user not privy to the key to fake an authenticating hash.
The entire message is not protected by the AH, because IP
headers can contain three classes of data: immutable data, which
never changes in transit; mutable but predictable data, which can
be modified during transit, but whose final value, on arrival at the
destination, is predictable; and mutable unpredictable data, whose
value can change during transit in an unforeseen manner. Table 2.1
lists the fields of the IP header that fall into each category. Only
the message data and those header fields that will not change in
an unpredictable manner in transit are used as input to the
authenticating hash, so the final recipient of the packet can verify
the hash. Thus, in Transit Mode, the message data and the predictable fields of the IP header are protected. In Tunnel Mode, the
entire original IP header and the message data are protected, but
only the predictable fields of the added header are protected.
When the hash is computed, zeroes are used in place of the contents of the unprotected header fields.
The mandatory keyed hash algorithms for IPsec AH are
HMAC-MD5, which generates a 128-bit hash, and HMACSHA-1, which generates a 160-bit hash. In AH, to ensure proper
byte boundaries for efficient processing, the authenticating hash is
truncated to 96 bits. Expert cryptographers have ascertained that
truncating the hash does not lessen its uniqueness or the properties
that ensure cryptographic safety. Once the hash has been placed in
the Authentication field, along with any other data required by the
specific hash algorithm, the message is ready to be sent on its way.

28

Demystifying the IPsec Puzzle
Table 2.1
Classes of IP Header Fields

Immutable

Mutable but
Predictable

Mutable
Unpredictable

IPv4

IPv6

Version

Version

Internet header length

Payload length

Total length

Next header (AH)

Identification

Source address

Protocol (should be value for AH)

Destination address (without routing
extension header)

Source address

—

Destination address (without
source routing)

Destination and hop-by-hop extension
headers option type/data length

Option type/data length/data
(classified as immutable)

Destination and hop-by-hop extension
headersoption data (option type classified
as immutable)

Destination address (with source
routing)

Destination address (with routing
extension header)

—

Routing extension header

TOS

Class

Flags

Flow label

Fragment offset

Hop limit

TTL

Destination and hop-by-hop extension
headers: option data (option type
classified as mutable)

Header checksum

—

Option type/data length/data
(classified as mutable)

—

8. Fragment the message, if necessary. If the message, enlarged by the
AH and possibly by an additional IP header for Tunnel Mode, is
sufficiently large that it needs to be fragmented before it is sent,
fragmentation takes place at this point. In Transport Mode, the
message’s source address is always the initiator of the message, so
the total message can be authenticated before fragmentation
occurs. In Tunnel Mode, the source address of the original header

The First Puzzle Piece: The Authentication Header

29

is the actual initiator of the message; if that source address differs
from the outer header’s source address, the message may already
have been fragmented after it exited the original host. In that case,
the tunnel header’s authentication was performed on a message
fragment, which at this point may have to be further fragmented.
Figure 2.7 illustrates the Transport Mode case and Figure 2.8 the
Tunnel Mode case.
Compute
message ICV

Host H2

Fragment #2

3

Host H1

Fragment #1

2

Router R1

1

Large message

Recombine
fragments
Authenticate
message

Figure 2.7 Fragmentation and authentication: Transport Mode host-to-host SA.

1

Compute
Fragment #1’s
ICV
3

Fragment #1-2

4
Gateway SG2

Router R1

Authenticate
Fragment #1
Fragment #1

1

2

Fragment #2

Recombine
Fragment #1-1
and
Fragment #1-2
Host H2

Fragment #1-1

Gateway SG1

Fragment #1

Compute
Fragment #2’s
ICV
5

Fragment #2

Authenticate
Fragment #2
5

Fragment #2

Recombine
Fragment
#1 and #2

Figure 2.8 Fragmentation and authentication: Tunnel Mode gateway-to-gateway SA.

30

Demystifying the IPsec Puzzle

2.9 AH Processing for Inbound Messages
When a message is received that contains an AH, the IP processing routines
first ensure that all fragments of the message have been received and reintegrated to form a complete message. The routines also ensure that the fields
that identified each piece of the message as a fragment are reinitialized: The
offset field is reset to zero and the “more fragments” flag is turned off,
so the IPsec processing routines do not erroneously identify the reassembled
message as a message fragment. The message is then passed to the IPsec processing routines, which perform the following steps.
1. Locate the inbound SA governing this protected communication
in the SAD. This step is initially accomplished through the use of
the three identifying indices: the SPI, the destination address, and
the AH protocol. The SA’s indices are compared to those found
in the packet’s outmost AH, whether it is Tunnel Mode or Transport Mode. The packet must also conform to any other selectors
that limit the SA’s applicability (e.g., port or protocol). If this is a
tunnel header, the SA selectors are compared to those found in the
packet’s inner header, because these fields are not copied into
the tunnel header. Once a matching SA has been found, processing
can continue. If no such SA is found, the packet is dropped.
2. If replay protection is enabled, perform the replay protection check.
The originator of a packet with AH will always increment the
replay protection counter; the recipient is free to either ignore this
counter or use it to ensure replay protection. However, because IP
does not guarantee delivery of packets in the same order in which
they were sent (that is the responsibility of the Transport Protocol
or the application), this counter cannot be used to ensure exact
ordering of the packets, but only a relatively correct order within a
window that is a multiple of 32.
For each inbound SA, the SAD includes a replay window. The
size of the window determines how greatly out of order a message
can be without being rejected; the size is a multiple of 32, with 64
recommended as a default. A replay window of size N keeps track
of the sequence numbers of the last N messages received. Any message with a sequence number so low that it is outside the window’s
range is dropped. A message within the window’s range whose
sequence number is a duplicate of a message that was already
received is also dropped.

The First Puzzle Piece: The Authentication Header

31

A bit mask (or some equivalent structure) can be used to track
the sequence numbers of the last N messages received for this SA.
Initially, a 64-bit mask could keep track of the receipt of messages
with sequence numbers between 1 and 64. Once a message with
a sequence number greater than 64 (e.g., sequence number 70) is
received, the bit mask would keep track of messages with sequence
numbers from 7 to 70; it would then drop any arriving messages
with a sequence number less than 7. This check ensures that each
inbound message has not been previously received and that it is not
grossly out of order. Figure 2.9 illustrates how the sliding replay
window works.
3. Verify the authentication data. The authentication hash is computed, in exactly the same manner as for an outbound message. If
the computed hash does not match the authentication data found
in the message, the message is discarded and no further processing
takes place.
4. Strip off the AH and repeat the IPsec processing for any remaining
IPsec headers. If there are other nested IPsec headers that terminate
at the current destination, each successive header must be processed
#4

1

2

3

#10

4

5

6

7

8

9



10

…

…



64



#64
#10

Window shifts when
packet #70 arrives

Packet dropped (duplicate)

7
#70

#6

8

9

10

…

…


Packet dropped (not in window)

Figure 2.9 The sliding replay protection window.

64



65

66

67

68

69

70