Understanding IPsec: Security Protocol and VPNs Explained

CSE 4905 IPsec 8-1

IPsec security protocol for network layer Between two network entities Host-host, host-gateway, gateway-gateway Specified in more than dozen RFCs, developed in 1990 s security goals verify sources of IP packets - authentication prevent replaying of old packets protect integrity and/or confidentiality of packets data integrity/data encryption blanket coverage used case: VPN 8-2

Virtual Private Networks (VPNs) motivation: institutions often want private networks for security costly: separate routers, links, DNS infrastructure. VPN: institution s inter-office traffic is sent over public Internet instead encrypted before entering public Internet logically separate from other traffic 8-3

Virtual Private Networks (VPNs) laptop w/ IPsec public Internet salesperson in hotel router w/ IPv4 and IPsec router w/ IPv4 and IPsec branch office headquarters 8-4

IPsec A collection of protocols (RFC 2401) Authentication Header (AH) RFC 2402 Encapsulating Security Payload (ESP) RFC 2406 Internet Key Exchange (IKE) RFC 2409 IP Payload Compression (IPcomp) RFC 3137 6 8-6

IPsec main components ESP AH Encapsulating Security Payload Authentication Header IPsec Security Policy IKE The Internet Key Exchange 8-7

Two IPsec protocols Authentication Header (AH) protocol provides source authentication & data integrity but not confidentiality Encapsulation Security Payload (ESP) provides source authentication, data integrity, and confidentiality more widely used than AH 8-8

Authentication Header (AH) Provides source authentication Protects against source spoofing Provides data integrity Use cryptographic hash (96-bit) HMAC-SHA-96, HMAC-MD5-96 Protects against replay attacks Use 32-bit monotonically increasing sequence numbers NO protection for confidentiality! 8-9

Encapsulating Security Payload (ESP) Provides all that AH offers, and in addition provides data confidentiality Uses symmetric key encryption 3-DES, ESP is much more widely used than AH 8-10

IPsec transport mode IPsec IPsec IPsec datagram emitted and received by end-system protects upper level protocols (not IP header) IP header IPsec header TCP header data 8-11

IPsec tunneling mode IPsec IPsec IPsec IPsec hosts IPsec-aware edge routers IPsec- aware protects entire IP packet new IP header IPsec header IP header TCP header data 8-12

Four combinations are possible! Host mode with AH Host mode with ESP Tunnel mode with AH Tunnel mode with ESP most common and most important 8-13

Security associations (SAs) before sending data, SA (logical network- layer connection) established from sending to receiving entity SAs are simplex: for only one direction sending and receiving entitles maintain state information about SA recall: TCP endpoints also maintain state info IP is connectionless; IPsec is connection- oriented! 8-14

Example SA from R1 to R2 Internet headquarters branch office 200.168.1.100 193.68.2.23 security association R1 R2 172.16.1/24 172.16.2/24 R1 stores for SA: 32-bit SA identifier: Security Parameter Index (SPI) origin SA interface (200.168.1.100) destination SA interface (193.68.2.23) type of encryption used (e.g., 3DES with CBC) encryption key type of integrity check used (e.g., HMAC with MD5) authentication key 8-15

Security Association Database (SAD) endpoint holds SA state in security association database (SAD), where it can locate them during processing. between headquarter and n salespersons, 2n SAs in R1 s SAD when sending IPsec datagram, R1 accesses SAD to determine how to process datagram. when IPsec datagram arrives to R2, R2 examines SPI in IPsec datagram, indexes SAD with SPI, and processes datagram accordingly 8-16

IPsec datagram focus for now on tunnel mode with ESP enchilada authenticated encrypted new IP header ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth pad length next header Seq # padding SPI 8-17

What happens? Internet headquarters branch office 200.168.1.100 193.68.2.23 security association R1 R2 172.16.1/24 172.16.2/24 enchilada authenticated encrypted new IP header ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth pad length next header Seq # padding SPI 8-18

R1: convert original datagram to IPsec datagram appends to back of original datagram (which includes original header fields!) an ESP trailer field. encrypts result using algorithm & key specified by SA. appends to front of this encrypted quantity the ESP header, creating enchilada . creates authentication MAC over the whole enchilada, using algorithm and key specified in SA; appends MAC to back of enchilada, forming payload; creates brand new IP header, with all the classic IPv4 header fields, which it appends before payload. 8-19

Discussion Why new IP header part is not authenticated? There are variable parts (e.g., TTL) Important source authentication is by source IP address, which is protected An IPsec datagram can exceed the maximum transmission unit, and hence may be fragmented. Will fragmentaton cause any security threats? Functionality-wise, fragmentation can be handled by IP layer (through a flag and fragmentation offset) just as for any IP packet Security-wise, no problem, since the receiver will only reassemble the IP datagram, and then decrypt, authenticate Cryptographic techniques used in Ipsec HMAC-SHA-96 (reasonble) HMAC-MD5-96 (should not be used) 3DES CBC: still reasonable in practice 8-20

Inside the enchilada: enchilada authenticated encrypted new IP header ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth pad length next header Seq # padding SPI ESP trailer: Padding for block ciphers ESP header: SPI, so receiving entity knows what to do Sequence number, to thwart replay attacks MAC in ESP auth field is created with shared secret key 8-21

IPsec sequence numbers for new SA, sender initializes seq. # to 0 each time datagram is sent on SA: sender increments seq # counter places value in seq # field goal: prevent attacker from sniffing and replaying a packet method: destination checks for duplicates doesn t keep track of all received packets; instead uses a window 8-22

Security Policy Database (SPD) policy: For a given datagram, sending entity needs to know if it should use IPsec needs also to know which SA to use may use: source and destination IP address; protocol number info in SPD indicates what to do with arriving datagram info in SAD indicates how to do it 8-23

Exercise: IPsec services suppose Trudy sits somewhere between R1 and R2. she doesn t know the keys. will Trudy be able to see original contents of datagram? How about source, dest IP address, transport protocol, application port? flip bits without detection? masquerade as R1 using R1 s IP address? replay a datagram? 8-24

Exercise: IPsec services suppose Trudy sits somewhere between R1 and R2. she doesn t know the keys. Trudy is not able to see original contents of datagram, or original source, dest IP address, transport protocol, application port flip any bits in enchilada will be detected (through MAC) Trudy can spoof R1 s IP address; but packets will not be authenticated because Trudy does not have MAC key replaying a datagram will be detected from the sequence # 8-25