What is IPsec?
Most of the time when we are trying to establish a site-to-site or LAN-to-LAN connectivity between two independent parties over an untrusted medium we rely on IPsec. Internet Protocol Security (IPSec) is a open standard suite of protocols used to authenticate and encrypt IP Packets in a connection. This ensures data integrity and data confidentiality. IPsec can be used in a variety of ways, to secure host-to-host communication, network-to-network communication, host-to-network. The most common type is network-to-network. An argument can be made that host-to-host is the same as network-to-network with /32s (i.e. 192.168.1.1/32 to 192.168.255.1/32). Anyway!
IPsec allows us to form a secure virtual communication link over a untrusted medium such as the internet to allow LAN to LAN communication. Sound familar? VPN anyone? For instance if CompanyA with 192.168.1.0/24 address space and CompanyB with 172.16.1.0/24 address space require hosts on each of their networks to talk to one another, this can be accomplished by utilizing a IPsec tunnel. Hosts at CompanyA would be able to traverse the IPsec tunnel to CompanyB as it appears to them to be nothing more than another routed LAN. It’s a cheap and easy way to create this linked infrastructure without the need to buy or lay-down physically dedicate cabling. Why not piggy back and on an already existing insecure circuit and make it secure with IPSec!!
Phase 1 and Phase 2 ???
“Phase 1” — Before IPsec can even begin to send your data, there is a negotiation and the establishment of an agreed upon method to create and secure this connection. The negotiation is performed by Internet Key Exchange (IKE), which consists of (I think) 3 different Key Management protocols. ISAKMP, Oakley, SKEME. All of which are used based on how you want to setup the key exchange, ISAKMP being the most popular. The main point of this Phase 1 is two things, one to agree upon a way to protect this negoitation, followed by authenticating each endpoint to form a trust relationship. This all happens bidirectionally. Once both of those have been completed we have a successfully formed a IKE Security Association(SA) that maintains this trust. IKE uses the key exchange algorithm called Diffie-Hellman to establish a secret key between each end. After this secure channel is setup it will be used in the next phase to negotiate the IPsec SAs, creatively called “Phase 2”. Keep in mind thata single Phase 1 SA can house multiple IPSec SAs!!!, unless you are using Perfect Forward Security(PFS). PFS make it so each IPSec tunnel has only 1 unique Phase 1 SA, that way if Phase 1 is ever compromised it won’t jeopardize all your IPSec tunnels under a single Phase 1 SA. Did I lose you? 🙂
“Phase 2” — IKE is used to negotiate IPSec SAs and how IPSec should be protected. In this Security Association (SA), the actual networks at each end of the tunnel must be agree upon. If they are not, Phase 2 will never come up as their SA are in mismatch. Furthermore, in this Phase 2 an agree upon Transform-set is established. The Transform-Set is the method on how the packets will be encrypted and transmitted out the tunnel interface. How should we transform the packets through the tunnel? Phase 2 also uses the key exchanged from Phase 1 to be used when encrypting the data. If PFS is used, keys are derived independently and not from Phase 1. The cost being time, benefit being a single key compromise does not compromise all IPSec tunnels. Keep in mind Phase 2 is required to be completed at both ends. If not the opposing side won’t know how to decrypt the data!!
So in summary IKE is used to protect Phase 1 and Phase 2, IPSec is used to send the packets. If you want to understand these steps further, I recommned reading this overview. It is a great explaination. Also if you haven’t already bookmark PacketLife.net!!
Tunnel vs Transport ??
Difference between Tunnel and Transport mode is in Tunnel mode the complete Original IP packet header information is encapsulated and encrypted, in Transport mode only the TCP/UDP payload is encrypted.
Openswan U2.6.37/K3.2.0-4-amd64 w/NetKey Support connecting to a Cisco ASA 5505 running version 9.1(3). I include the versioning because I read a lot of articles where the version of OpenSwan matters tremendously, and also seems to influence what types of issues you might run into. The version I am running uses a fairly new feature called NetKey. From my research this was introduced to make configuring a IPSEC tunnel easier and not require the re-compiling of the Linux Kernel.