As can be seen, I will be adding the configuration for a sweet new IPSec VPN between R1 and R2 in the next post which will be the actual lab session, as there is so much theory and acronym definitions that are important to know and understand that it really just needs its own post to cover all of it for future reference.
I put the Topology in this post because I was so excited about the little green VPN tunnel I built first in paint, only to be built again on the equipment in the near future 🙂
Speaking of that boring stuff you need to know in regards to IPSec VPN, lets start with acronym definitions:
- IPSec = IP Security
- GRE = Generic Routing Encapsulation
- AH = Authentication Header
- ESP = Encapsulation Security Payload
- IKE = Internet Key Exchange
And here are some phrases that will also need to be very clear on:
- VPN Data Origin Authentication = Receiver can guarantee the source of the packet
- VPN Encryption = Making content of IP Packet unreadable during transmission
- VPN Integrity = Receivers ability to ensure data is not tampered with during transmission
To begin I’d like to mention the first protocol that can be used to create a VPN tunnel, GRE, which uses no encryption scheme for transmission making it a poor choice for a VPN.
The answer to GRE tunnels for encrypted VPN transmission is IPSec VPN. IPSec offers encryption and authentication using a combination of the protocols AH, ESP, and IKE:
As seen in the compilation of an IPSec VPN packet, AH is in a field of it’s own doing Authentication and Securing the data payload, while ESP is a re-encapsulation of the original IP packet with it’s own Header and Trailer.
AH offers solid security by performing data origin authentication to secure the payload, and offers anti-reply protection. The major drawback is that the authentication it provides for the IP header is not complete, because some of the IP fields cannot be correctly predicted by the receiver, as they may change during transmission – THOUGH IT DOES PROTECT THE IP PACKETS PAYLOAD.
AH offers data origin authentication, data integrity, and optional anti-replay protection. However, it does not offer data confidentiality.
ESP on the other hand does exactly what it’s acronym stands for, Encapsulating Security Payload using an ESP Header and Trailer. It offers data origin authentication, anti-replay protection, and data confidentiality.
ESP vs AH can be likened to TCP vs UDP, in the way that one of them has a lot of great features that we want for every packet in our network, however everything has a cost to the network devices CPU / Memory so we have to pick and choose where to use what.
ESP’s strong cryptography has a few drawbacks of its own:
- It puts a huge load on the routers CPU
- It is not used everywhere because of its strong cryptography
- Cryptography is not allowed in all countries (as in Cisco IOS disclaimers)
- AH has no such problem, but ESP should be used where possible
Both ESP and AH can be run in either Tunnel Mode or Transport mode:
In Tunnel mode the entire IPSec process is transparent to end hosts, it encrypts the entire packet, then places it into another IP packet. That encapsulating packet will have the IP addresses configured on the tunnel endpoints, and its those tunnel IP addresses that will be used to route the packet.
Transport mode encrypts the IP packets payload, but the IPSec Header is inserted directly after the IP Header, resulting in no protection for the original IP address. Also, the packet is routed using the original IP address, and only the data from the Transport layer up is protected by IPSec.
We are almost done with theory, almost there, just need to review the 5 steps of the formation of an IPSec VPN tunnel (these will be covered in detail during lab):
- Initialization of the tunnel by “interesting traffic” which is traffic that matches a Crypto ACL
- This triggers the IKE Phase 1, where IKE SA is negotiated
- Once Phase 1 completes, IKE Phase 2 IPSec SA Negotiation
- One Phase 2 is complete, the Tunnel is formed and Data Transfer takes place
- Once Data Transfer is complete we need to tear down the VPN tunnel (Tunnel Termination) after a determined amount of idle time with no data transmission
If the tunnel has a predetermined time that it will be Up, yet Data Transfer is still occurring, a new SA will be negotiated between Tunnel end points while the existing SA remains in place.
And with that, theory is wrapped up at least for now, I actually turned my rack on immediately out of habit when I sat down to type this post 🙂 Onward to IPSec tunnel configuration between R1 and R2! (More theory will be explained as I configure)
The DEVNET GRIND! 