The IETF has developed the IPSec architectural framework for securing transmissions over an IP network. IPSec features network layer support for authentication of the originator, encryption of transmitted data, and even protection of the header information of transmitted packets through a process known as encapsulation. These services enable end-to-end security of data through an IP network. Although this may not seem significant, remember that IP was designed to provide best-effort delivery of data through a routed and connectionless network environment. Connectionless means that virtually every packet could take a different route through the network. Therefore, the challenge was to develop a series of mechanisms that would allow each router in an internetwork to support the end-to-end security of the data in transit.

The solution developed by the IETF is known as a security association (SA). An SA is a logical, simplex "path" between a source and a destination machine. This path is considered logical rather than physical because it remains possible for each transmitted packet to take a different route through the network. The SA itself is a relatively simple construct. It consists of a security parameter index (SPI), the security protocol being used, and the destination IP address. This construct can be supported in both IPv4 and IPv6. Its fields are added to the datagram after the IP header, but before the TCP or UDP header.

Placing these fields at the beginning of the IP datagram's payload is a relatively easy way of enabling end-to-end protection of the IP data, despite its passage through an otherwise unsecured network. Equally as important, this technique does not encumber the routers in the network. They can forward IPSec-compliant datagrams just as they would any other IP datagram. Thus, they can contribute to the end-to-end security of an IPSec-compliant session without having to do anything but forward datagrams! This preserves their previous level of operational efficiency, while adding substantial network layer security.

SAs can be used to support two IPSec security protocols: Authentication Header (AH) and Encapsulating

Security Payload (ESP). It is important to note that IPSec only permits one SA per service! Therefore, if you want to perform both encapsulation and authentication, you would need two SAs. SAs, however, are simplex in nature. That is, they only work in one direction. To illustrate this point, consider Figure 15-4. This figure illustrates a simplex authentication SA. The source machine is authenticated to the destination machine, but any datagrams generated in response are not similarly authenticated. In other words, the destination machine is assumed to be legitimate and no authentication is performed.

Figure 15-4: Simplex authentication.

Figure 15-4: Simplex authentication.

Assuming that the destination machine is legitimate can be a dangerous assumption. Providing bidirectional authentication is just a matter of using two unidirectional authentication SAs:

• One authenticates the source machine to the destination machine.

• The other authenticates the destination machine to the source machine.

Figure 15-5 depicts this bidirectional authentication.

ESP headers work the same way. They are simplex, but can be paired to provide bidirectional encapsulation. The important thing to remember is that multiple SAs are permitted, per connection. Providing bidirectional authentication and bidirectional encapsulation on a connection would require the definition of four SAs. This flexibility enables a network administrator to customize the degree of security according to the users' needs.

Figure 15-5: Bidirectional authentication.

SAs are little more than the mechanisms that enable IPSec to function. The actual security protocols, AH and ESH, warrant further examination.

0 0

Post a comment