Tải bản đầy đủ
7 ESP Header Processing for Inbound Messages 49

7 ESP Header Processing for Inbound Messages 49

Tải bản đầy đủ

50

Demystifying the IPsec Puzzle

4.

5.
6.
7.

takes place. Performing the authentication verification prior to
decryption is efficient. If the message has been altered, the computationally expensive decryption process is avoided.
Decrypt the encrypted portion of the packet. If decryption is not
successful or results in garbled header information, the message is
discarded and no further processing takes place.
Strip off the padding, if any was added.
Strip off the ESP header and repeat the IPsec processing for any
remaining IPsec headers.
Check the SPD to ensure that the IPsec protection applied to the
incoming packet conforms to the system’s IPsec policy requirements.

The successful authentication or encryption of an incoming packet
as specified by an existing SA does not ensure that the SA should have
been used to protect this particular type of traffic. In scenario 1 (presented in
Chapter 1), let’s assume that hosts H1 and H2 have established several SAs
to provide end-to-end security coverage for their communications. SAs 1 and
2, which ensure that HTTP messages are not tampered with, are AH SAs.
SAs 3 and 4, which protect FTP data transmissions, are ESP SAs. When a
packet comes into H2, and the SPI, protocol (ESP), and destination address
tie in the packet to SA 3, that SA will be used to decrypt the packet. What
would happen if H1 mistakenly used SA 3 to send HTTP traffic to H2?
The inbound packet’s destination address, SPI, and protocol (ESP) would all
point to SA 3. The port number, which would show that the packet is not an
FTP message, cannot be interrogated before the packet has been decrypted.
The packet will successfully decrypt, because it has used a valid SA. It is only
a policy check, after decryption, that will show that the packet has been sent
under the umbrella of the wrong SA. This erroneous usage is demonstrated
in Figure 3.5.
A more dramatic example is the case in which H1 and H2 use an SA
bundle, a grouping of several related SAs, to protect a single packet. Perhaps
the hosts have established two end-to-end SAs: SAs 1 and 2 are ESP
encryption-only SAs, and SAs 3 and 4 are AH SAs that will authenticate the
encrypted traffic and its IP header. What would happen if H1 mistakenly
used only SA 1 to send an FTP request to H2? The inbound packet’s destination address, SPI, and protocol (ESP) would all point to SA 1. The packet
would successfully decrypt, because SA 1 is perfectly appropriate for this traffic. However, a policy check would reveal that the packet should have had

The Second Puzzle Piece: The Encapsulating Security Payload

51

SA#3 (SPI3)

Host H1

HTTP packet

SA #
1
2
3
4

Src Dest IPsec
Addr Addr Protocol Port
H1
H2
AH
HTTP
H2
H1
AH
HTTP
H1
H2
ESP
FTP
H2
H1
ESP
FTP

Host H2

SPI
SPI1
SPI2
SPI3
SPI4

Mode
Transport
Transport
Transport
Transport

Figure 3.5 Erroneous SA usage.

two security headers, and the packet would be dropped. Figure 3.6 demonstrates this erroneous case, as well as the correct usage of SAs 1 and 3.
SA#1 (SPI1)

Host H1

Host H2

(a)
SA#1 (SPI1)

SA#3 (SPI3)

Host H1

Host H2

(b)
SA
IPsec
SA Bundle Src Dest
Addr Addr Protocol
#
#
1
2
3
4

1
2
1
2

H1
H2
H1
H2

H2
H1
H2
H1

ESP
ESP
AH
AH

SPI

Mode

SPI1
SPI2
SPI3
SPI4

Transport
Transport
Transport
Transport

Figure 3.6 SA bundle applications: (a) erroneous application and (b) correct application.

52

Demystifying the IPsec Puzzle

3.8 Complications
Although encryption of the upper-layer headers is desirable for security purposes, it eliminates the transport header fields, including the Transport Protocol and ports, as SA selectors. It also poses problems for certain specialized
uses of Internet traffic. A number of fields in the transport header can be
used for purposes other than transport layer processing, including network
traffic analysis, management, and performance enhancement; intrusion
detection; and preferential treatment for specified types of traffic, resulting in
several different classes of quality of service (QOS). A new protocol, called
transport-friendly ESP (TF-ESP) [3], has been proposed, but the details
have not yet been fully hammered out. There are two possible approaches:
(1) defining a special TF-ESP header that would duplicate the critical fields
in an unencrypted form and (2) beginning the encryption at a later point in
the packet, leaving the desired header fields unencrypted. One downside of
the first solution is the fear that security would be compromised by providing potential attackers with unencrypted header information, which is also
present in its encrypted form in a well-known location within the packet.
Another potential drawback is the duplication of information, resulting in
increased packet size. The second solution could complicate an already complex protocol, requiring additional specialized processing. Whether the
advantages provided by TF-ESP would outweigh the negative considerations
has not yet been determined.

3.9 Criticisms and Counterclaims
The well-known and well-respected cryptographer Bruce Schneier coauthored, with his colleague Niels Ferguson, an extremely critical analysis of
IPsec and IKE [4]. Ferguson and Schneier begin by stating that complexity is
the sworn enemy of security. Of course, they are correct; unfortunately, the
problem that IPsec is attempting to attack is an extremely complex and multifaceted area. IPsec not only has to secure IP traffic; it has to coexist with
numerous existing protocols, cope with open-ended network topologies,
and, one would hope, accommodate future networking developments as
well.
In the name of simplification, Ferguson and Schneier suggest the elimination of the AH protocol and of Transport Mode. Many IPsec developers
agree that AH should be abolished, and it is possible that that will happen in
the next version of IPsec. On the other hand, there may be other protocols
that require the use of AH and would protest its demise. As far as limiting all

The Second Puzzle Piece: The Encapsulating Security Payload

53

SAs to Tunnel Mode, they also suggest a somewhat complex headerminimization scheme to compensate for the extra baggage of Tunnel Mode
when it is not really needed. The authors admit that they are not networking
experts. Those who are expert in that arena vociferously declare that the
inclusion of both Transport and Tunnel Modes is dictated by the nature of
the network architecture [5, 6].
Ferguson and Schneier are not happy with the order of operations performed in ESP processing; they believe that outgoing packets first should be
authenticated and then encrypted. That order was selected intentionally, so
that incoming packets that did not authenticate properly would not progress
to the more computationally demanding decryption stage. The authors present a scenario in which the authentication and encryption keys are decoupled, so that successfully undergoing authentication does not guarantee that
the packet will decrypt correctly. To solve the problem without reversing
the order of the operations, Ferguson and Schneier suggest authenticating
the decryption key and any other data used in the encryption, along with the
packet data. On the other hand, the cryptographers who participated in
the IPsec development appear to be comfortable with this order of operations, without requiring authentication of additional information. In
addition, as discussed in Chapter 5, when IKE is used to negotiate the keys,
the ESP’s authentication and encryption keys are part of an integral whole.
The authors view unidirectional SAs as unnecessary baggage, causing
SAD bloat. They propose bidirectional SAs, reducing the size of the SAD
and simplifying matters. However, a single SAD entry would not allow each
peer to select its own inbound SPI; a dual entry, each with its own SPI,
would restore the SAD’s larger size. Moreover, there may be uses of IPsec,
such as multicast (more on this in Chapter 11), in which traffic actually does
flow in only one direction.
Ferguson and Schneier also are uncomfortable with affording users and
system administrators too much leeway in security decisions. With regard to
the SPD, they feel it is dangerous enough to allow users to choose which
types of traffic should or should not be IPsec-protected. Selecting specific
algorithms and levels of protection is fraught with more peril than they can
bear. It is true that the specification of security-related parameters is a tricky
business. However, it is an area in which individual implementations can distinguish themselves in terms of the interplay of ease of use and the level of
security controls.
One of their major criticisms is the difficulty of comprehending the
documentation. Aside from the number of documents involved, the failure
to include background, goals, and rationale is a major stumbling block. They