CSE 4905 IPsec 8 1 IPsec v security

CSE 4905 IPsec 8 -1

IPsec v security protocol for network layer § Between two network entities • Host-host, host-gateway, gateway-gateway v § 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 v “blanket coverage” § used case: VPN 8 -2

Virtual Private Networks (VPNs) motivation: vinstitutions often want private networks for security § costly: separate routers, links, DNS infrastructure. v. 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) IP header Secure payloa d laptop w/ IPsec r ylo IP er ad pa router w/ IPv 4 and IPsec he ad router w/ IPv 4 and IPsec salesperson in hotel e cur Se load y pa IPsec heade r ec IPs der ea IP r h e ad IP heade IPsec header he Secur e paylo ad public Internet d a ylo he IP ad er pa headquarters branch office 8 -4

IPsec v. 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 v Authentication Header (AH) protocol § provides source authentication & data integrity but not confidentiality v Encapsulation Security Payload (ESP) § provides source authentication, data integrity, and confidentiality § more widely used than AH 8 -8

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

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

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

IPsec – tunneling mode IPsec v v IPsec edge routers IPsecaware protects entire IP packet IPsec v IPsec hosts IPsec-aware 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) v before sending data, SA (logical networklayer connection) established from sending to receiving entity § SAs are simplex: for only one direction v sending and receiving entitles maintain state information about SA § recall: TCP endpoints also maintain state info § IP is connectionless; IPsec is connectionoriented! 8 -14

Example SA from R 1 to R 2 Internet headquarters 200. 168. 1. 100 R 1 172. 16. 1/24 branch office 193. 68. 2. 23 security association R 2 172. 16. 2/24 R 1 stores for SA: v v v v 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. , 3 DES with CBC) encryption key type of integrity check used (e. g. , HMAC with MD 5) authentication key 8 -15

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

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

What happens? Internet headquarters 200. 168. 1. 100 R 1 branch office 193. 68. 2. 23 security association 172. 16. 1/24 R 2 172. 16. 2/24 “enchilada” authenticated encrypted new IP header ESP hdr SPI original IP hdr Seq # Original IP datagram payload padding ESP trl ESP auth pad next length header 8 -18

R 1: convert original datagram to IPsec datagram v v v 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 IPv 4 header fields, which it appends before payload. 8 -19

Discussion v 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 v 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… v Cryptographic techniques used in Ipsec § HMAC-SHA-96 (reasonble) HMAC-MD 5 -96 (should not be used) § 3 DES CBC: still reasonable in practice 8 -20

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

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

Security Policy Database (SPD) v v 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 v v info in SPD indicates “what” to do with arriving datagram info in SAD indicates “how” to do it 8 -23

Exercise: IPsec services v suppose Trudy sits somewhere between R 1 and R 2. 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 R 1 using R 1’s IP address? § replay a datagram? 8 -24

Exercise: IPsec services v suppose Trudy sits somewhere between R 1 and R 2. 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 R 1’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