Page 248 - Handout Computer Network.

Along with a SAD, the IPsec entity also maintains another data structure called the Security Policy
Database (SPD). The SPD indicates what types of datagrams (as a function of source IP address,
destination IP address, and protocol type) are to be IPsec processed; and for those that are to be
IPsec processed, which SA should be used. In a sense, the information in a SPD indicates “what”
to do with an arriving datagram; the information in the SAD indicates “how” to do it.

Summary of IPsec Services So what services does IPsec provide, exactly? Let us examine these
services from the perspective of an attacker, say Trudy, who is a woman-in-the-middle, sitting
somewhere on the path between R1 and R2.

Assume throughout this discussion that Trudy does not know the authentication and encryption
keys used by the SA.
What can and cannot Trudy do?

First, Trudy cannot see the original datagram. If fact, not only is the data in the original datagram
hidden from Trudy, but so is the protocol number, the source IP address, and the destination IP
address. For datagrams sent over the SA, Trudy only knows that the datagram originated from
200.168.1.100 and is destined to 193.68.2.23. She does not know if it is carrying TCP, UDP, or
ICMP data; she does not know if it is carrying HTTP, SMTP, or some other type of application
data.
This confidentiality thus goes a lot farther than SSL. Second, suppose Trudy tries to tamper with
a datagram in the SA by flipping some of its bits.

When this tampered datagram arrives at R2, it will fail the integrity check (using the MAC),
thwarting Trudy’s vicious attempts once again. Third, suppose Trudy tries to masquerade as R1,
creating an IPsec datagram with source 200.168.1.100 and destination 193️.68.2.23️. Trudy’s
attack will be futile, as this datagram will again fail the integrity check at R2. Finally, because IPsec
includes sequence numbers, Trudy will not be able create a successful replay attack.
In summary, as claimed at the beginning of this section, IPsec provides—between any pair of
devices that process packets through the network layer—confidentiality, source authentication,
data integrity, and replay-attack prevention.

IKE: Key Management in IPsec When a VPN has a small number of end points, the network
administrator can manually enter the SA information (encryption/authentication algorithms and
keys, and the SPIs) into the SADs of the endpoints. Such “manual keying” is clearly impractical for
a large VPN, which may consist of hundreds or even thousands of IPsec routers and hosts. Large,
geo graphically distributed deployments require an automated mechanism for creating the SAs.
IPsec does this with the Internet Key Exchange (IKE) protocol, specified in RFC 5996. IKE has some
similarities with the handshake in SSL.
Each IPsec entity has a certificate, which includes the entity’s public key. As with SSL, the IKE
protocol has the two entities exchange certificates, negotiate authentication and encryption
algorithms, and securely exchange key material for creating session keys in the IPsec SAs. Unlike
SSL, IKE employs two phases to carry out these tasks. Let’s investigate these two phases in the
context of two routers, R1 and R2, in Figure 8.28. The first phase consists of two exchanges of
message pairs between R1 and R2:

288