HP 635n Practical IPsec Deployment for Printing and Imaging Devices - Page 28

Figure 23 - ESP Here we can see what is going to happen to a packet that matches Rule 2 in our IPsec policy. First, the IP header will be modified to indicate that ESP is the protocol that IP is carrying. Next, the ESP Header, followed by the IP payload of the original packet, followed by an ESP trailer, then the ESP Authentication data. This packet is an IPsec ESP packet formed using Transport Mode. Thinking back to our parable, we know what confidentiality, authentication, and integrity mean. Now, we can see how ESP can help thwart our attacker Jane. Since the original IP payload is provided confidentiality protection, we know that Jane and her attempts to capture this information via Wireshark will not do any good. All she will see is what appears to be random data and because she doesn't possess the key used to provide the confidentiality protection, she can't decrypt the message. Jane can attempt a brute force search of the key, but because we selected very good confidentiality algorithms and large key sizes, such a brute force search would take many lifetimes to complete (as of Summer 2008 anyway ☺). Jane could attempt to modify the ESP headers or attempt to change data in the packet. However, the message's authentication and integrity would be violated. As you can see, Jane would not be happy if IPsec was being used. The IPsec Policy is providing the information needed to determine which packets should be protected by IPsec, the format of the IPsec packet, and the algorithms that can be used to provide IPsec services. However, the IPsec policy doesn't have any secret keys and these algorithms need secret keys to work! Where do the secret keys for these algorithms come from? Well, they are taken from the Security Association Database, aka SADB. Who/What puts the secret keys in the SADB? The Internet Key Exchange Protocol or IKE is responsible for populating the SADB. Refer to Figure 24 - IKE. 28