Security in IPv 6 IPsec Dr Stephen Kent

Security in IPv 6: IPsec Dr. Stephen Kent Vice President & Chief Scientist - Information Security

What is IPsec? A set of protocols used to provide security services for IP traffic Works with IPv 4 and is an intrinsic part of IPv 6 Two protocols for traffic protection – Encapsulating Security Payload (ESP) – Authentication Header (AH) One protocol for Security Association & Key Management – Internet Key Exchange (IKE)

Why Secure Traffic at the IP Layer? Lowest layer in stack that is independent of network technology Highest layer in stack that is essentially protocol suite independent Supports true “end-to-end” protection, but also allows “enclave” protection cleanly Supports all transport protocols

IPsec Key Concepts Security Policy Database (SPD) - a database that indicates how traffic is processed when it passes through IPsec – Bypass – Discard – Protect (how to apply IPsec) Security Association (SA) - a simplex, cryptographically-secure channel between two IPsec peers, always created in pairs Security Association Database (SAD) - a database that contains the parameters needed to process traffic traversing an SA, i. e. , the SAD describes extant SAs created under the policies specified in the SPD

Peer Authorization Database (PAD) Contains IKE peer authentication and authorization data – Pre-shared secret or certificate (EE or CA) for peer authentication – ID types and value ranges to match against IKE ID – Use of IKE ID or constrained range of IP (v 4/v 6) addresses for SPD matching when creating child SAs The last two bullets constrain names and addresses asserted by peers to ensure that a peer does not create child SAs that misrepresent its authorization

IPsec Basic Processing Model Black / Unprotected / Ciphertext Bypass DIS AH/ESP IKE DIS Red / Protected / Plaintext IPsec boundary

IPsec in the Protocol Stack Application Session Transport Network Link Physical IP Local Net IP IPsec Native IP w/IPsec

IPv 4, IPv 6, IPsec, and IKE Application IKE Session Transport IPv 4 IPsec Network IPv 6

IPsec Deployment Options Individual host: each host (i. e. , “end system”) may implement its own protection end-to-end – Native host OS implementation – “bump in the stack” (BITS) retrofit implementation – “bump in the wire” (BITW) hardware implementation Host community: a security gateway can protect an entire enclave of hosts Peers: host-to-host, host-to-gateway, gateway-to -gateway Can also use IPsec for PPVPN contexts and for “link” security in overlay nets

IPsec Implementation Options Native BITS Application Session Transport Native IP w/IPsec IP IPsec Local Net Local net BITW IP IPsec Net

IPsec Protocols IP Authentication Header (AH) – RFC 4302, issued in 2005, replaces RFC 2402 – connectionless data integrity/origin authentication (for payload and selected header fields), anti-replay IP Encapsulating Security Payload (ESP) – RFC 4303, issued in 2005, replaces RFC 2406 – “mix and match” services: data integrity/origin authentication, data confidentiality, anti-replay, traffic flow confidentiality Internet Key Exchange (IKE) – IKE v 1: RFC 2409, RFC 2407, … – IKE v 2: RFC 4306 IPsec architecture – RFC 4301 – Describes how protocols work with SPD & SAD, how to deal with fragmentation, ICMP, etc.

Security Associations An SA is a unidirectional IPsec construct An SA defines the traffic that will flow over it – Source/destination IP addresses – Protocols – Ports (if applicable) An SA defines the protection offered to this traffic – Security protocol (AH or ESP) – Crypto algorithms – Crypto keys & crypto periods – Anti-replay

How IPsec Identifies SAs When an SA management protocol (e. g. , IKE) creates a new SA, the creator chooses a label for the SA, called the Security Parameter Index (SPI), a 32 -bit string The SA management protocol sends the SPI to the peer who will send packets over the SA. The peer must label each packet for the SA with the SPI chosen by the IPsec implementation that will receive the packets This mechanism allows the receiver to manage SPIs in any fashion that is convenient, and permits flexibility in SA granularity Multicast works differently, see MSEC WG docs

IPsec SA Example Three pairs of SAs between two IPsec Implementations IPsec Implementation A IPsec Implementation B Although we speak in terms of individual SAs, IKE always creates bidirectional SA pairs

IPsec Encapsulation AH and ESP involve encapsulation – each encapsulates a protocol above it – each is encapsulated by a protocol below it In IPv 6, IPsec is an “extension header” AH does not offer “clean” encapsulation, covers: – some parts of IPv 4 header, and some parts of IPv 6 base header – some complete IPv 6 extension headers – some parts of other IPv 6 extension headers ESP encapsulation is clean

AH Format Next Length Reserved Security Parameters Index (4 octets) Sequence Number (4 octets) Integrity Check Value - including padding if needed (variable length, multiple of 4 octets) Next Header – tells type of encapsulated layer – values defined in RFC 791, value in IP header is “ 51” to identify IPsec AH protocol Length – count includes Authentication Data – number of 32 -bit words, minus 2 (an IP header extension length convention)

Fields in AH SPI – identifies security association (details later) Sequence Number – monotonically increasing counter to detect and reject replayed packets – transmitter must send, but receiver can ignore – transmitter cannot send a packet that wraps the sequence number (MUST create a new SA) – receiver checks for duplicates within sliding window (min 32 packets, 64 packets recommended) Integrity Check Value (ICV) – length determined by algorithm negotiated for SA – MUST support HMAC with MD 5 and HMAC with SHA-1 – may include padding to make AH header length a integral multiple of 64 bits for IPv 6

AH Packet Structures Before AH Is Applied After AH Is Applied Original IPv 6 Opt Ext. Upper Base Headers Header Data Adjust value of Payload Length Field Insert AH Header Adjusted IPv 6 Opt H-by-H, Des Op’s, Upper Opt AH Ops Des Header Data Base Header Route, or Frag Ext’s Ext. Authenticated (Except for Unpredictably Mutable Fields in IP Header) This shows AH in “Transport Mode”. “Tunnel Mode” shown later.

ESP Header Format Security Parameters Index (4 octets, mandatory) Sequence Number (4 octets, mandatory) Payload Data (variable number of octets, mandatory) Padding (0 ≤ n ≤ 255 octets, as needed) Pad Length Next Header (1 oct. , mand. ) ICV - including padding if needed (varies per algorithm, multiple of 4 octets, optional) Leader Payload and Pad Trailer Integrity Check SPI – identifies security association Sequence Number – same as in AH Payload – encapsulated PDU protected by ESP – Encryption is optional

Fields in ESP Padding – may be used to match plaintext to block cipher size – or to align trailer on 4 -byte boundary – minimal TFC capability Pad Length – length of padding in bytes (0 -255) Next Header – tells type of encapsulated layer – values defined by RFC 791 – ICV– computed check value – Optional, but recommended, same algorithms as AH

ESP Packet Structure for IPv 6 Original IPv 6 Opt Ext. Upper Base Headers Header Data Before After Encrypted Fields Adj IPv 6 Opt H-by-H, Route, Header or Frag Ext’s ESP Opt Des Upper ESP Leader Ops Ext. Header Data Trailer Auth Data Authenticated Fields Security Parameters Index Sequence Number Payload Data Padding Pad Next Length Header ICV Information protected by ESP data origin authentication and data integrity service Information protected by ESP data confidentiality service Note: ESP’s integrity does not cover any of encapsulating IP header, but AH’s does

IKE SA & “Child” SAs IKE Entity IKE First Negotiates Its Own SA, Then Uses That To Protect Negotiations for IPsec SAs Negotiation Messages IKE Entity (number varies with IKE mode) SA 1 SA 2 IPsec SA 3 SA 4. . . SAn SA 1 Each SA Defines A Protection Suite SA(s): ID’d by SPI(s) Each SA Is Identified By An SPI SA 2 SA 3 SA 4. . . SAn IPsec

IKE Features for IPsec Support IKE uses an ephemeral Diffie-Hellman exchange to generate shared, secret bits for symmetric encryption and integrity keys, both sets of keys are directional IKE performs two-way authentication of peers, based on digital signatures or shared secret input to a hash IKE negotiates parameters for subscriber SAs – – – SPIs protocol (AH or ESP, or both) traffic selectors algorithms for confidentiality and/or integrity mode (tunnel vs. transport) SA lifetime IKE also exchanges housekeeping (NOTIFY) messages

IKE Step 1: SA Initiation Initiator Responder HDR, SAi 1, KEi, Ni HDR, SAr 1, KEr, Nr, [CERTREQ] HDR - SPI, version #, sequence number, flags SAi/r 1 - algorithms list for IKE SA protection KEi/r - Diffie-Hellman public value Ni/r - Nonce CERTREQ - optional request for certificates, in terms of trust anchor IDs

IKE Step 2: IKE SA Authentication Initiator Responder HDR, SK{IDi, [CERTs], [CERTREQ], [IDr] AUTH, SAi 2, TSi, TSr} HDR, SK{IDr, [CERTs], AUTH, SAr 2, TSi, TSr} SK - symmetric keys for encryption and integrity, derived from D-H exchange, nonces, addresses IDr/i - ID for initiator/responder SAi/r 2 - algorithms selected for child SA protection AUTH - signed value derived from step 1 TSi/r - traffic selectors for child SA CERTs - optional certificates (this exchange creates the first child SA)

IKE Step 3: Create Child SA Initiator Responder HDR, SK{ [N], SA, Ni, [KEi] [TSi, TSr] } HDR, SK{SA, Nr, [KEr] [TSi, TSr] } N - ID of SA being re-keyed (optional ) IDr/i - ID for a responder identity (optional) Ni/r - Nonce KEi/r - new DH public key for child SA (optional ) TSi/r - traffic selectors for child SA (not present for rekeys) (this exchange creates an additional child SA or rekeys an extant child SA)

Options for Applying AH and ESP Datagram To Be Protected by IPsec Upper IP Header Data Permissible Combinations Alone Together Nested IP AH or Upper Header ESP Header IP Header AH ESP Data Upper Header (discouraged) Data IP AH or Upper Header ESP Header Data Permissible Modes Transport Tunnel IP AH or Header ESP Upper Header Data (New) Outer AH or (Original) Inner Upper IP Header ESP IP Header Data

Why Transport and Tunnel Modes? Transport mode is ideal for host-to-host SAs – Low per-packet overhead – No need for inner IP layer – Could use tunnel mode here, just inefficient Tunnel mode is required for gateway-togateway SAs – Need inner IP header to carry “true” source & destination addresses – Need outer header to deal with fragmentation in “black” network When either end of an SA is a gateway, we usually employ tunnel mode for both SAs, to make life simpler, but there are exceptions

IPsec Peering Examples Mobile R 2 Internet R 3 H 4 R 1 H 5 H 6 H 1 H 2 H 3

Access Control in IPsec represents a barrier between plaintext & ciphertext or protected & unprotected interfaces The purpose of the barrier is to control the flow of packets IPsec is more powerful than a firewall, because it can make decisions on protected packet flows with authenticated identity info Although IPsec contains just a basic firewall, one cannot achieve equivalent security with a firewall placed behind an IPsec implementation

SPD Entry Examples Simple SPD entry example – IP: Source = 128. 89. 0. 0 -128. 89 - 255 (range) Dest = 24. 1. 2. 3 - 24. 1. 2. 3 (single address) – Protocol = 6 (TCP) – Port: Source = 0 - 255 (ANY) Dest = 23 - 23 (Telnet) – Disposition = ESP tunnel mode, AES-128 -CTR, HMAC-SHA-1 Simple SPD entry example – IP: Source = 128. 89. 0. 0 - 128. 89. 0. 100 (range) Dest = 128. 100. 0. 1 - 128. 100. 0. 1 (single) – Protocol = 17 (UDP) – Port: Source = 0 - 255 (ANY) Dest = 53 - 53 (DNS) – Disposition = Bypass The top entry creates one SA to protect Telnet traffic between all hosts In the specified range, and the specified destination host. The bottom entry bypasses all (UDP) DNS queries & responses from all hosts in the specified range to/from the designated host (DNS server)

IPsec ≠ Crypto + Firewall AH or ESP SPI SPD Check IPsec Implementation AH or ESP Just Crypto? NO SPI Filter Check Firewall

What was Updated in IPsec? Revised versions of AH & ESP – Extended sequence numbers (64 vs. 32 bit) – Multicast SA demuxing – Removal of default algorithms (separate RFC) – New TFC features for ESP Revised IPsec architecture – New processing model – No requirement to support SAs “bundles” – Revised SPD to match IKEv 2 – Peer Authorization Database (PAD)

Decorrelation of the SPD Why do it? – Order of SPD entries is critical in expressing policy, exactly what we do for other ACL systems that allow wildcards – BUT, can’t cache an entry, in general, because traffic might match cached entry instead of other, earlier entry not yet cached! (non-deterministic behavior is NOT good) How do we do it? – Start with first entry in SPD, compare to all later entries – When overlap is found, break target entry into pieces that don’t overlap – Establish links among all decorrelated entries that result from original entry – When caching, bring in all decorrelated entries linked together – Decorrelated entries no longer overlap, so ordered search not required, thus caching is safe!

New Processing Model (Outbound) Unprotected Interface Forwarding SPD-I cache DIS SPD cache SPD Selection Protected Interface AH/ESP

New Processing Model (Inbound) Unprotected Interface demux ~IPsec SPD-O cache DIS Bypass/ discard Forwarding Protected Interface IPsec ICMP AH/ESP IKE SAD check

Summary IPsec is the IETF standard for IP layer security It works for host-to-host, gateway-to-gateway, and host/gateway communication It is available in every modern OS, although most do not yet support the latest RFCs It is NOT just an encryption protocol (like TLS) It is a communication access control mechanism Its set of applications is expanding: – OSPFv 3 – BGP? – BTNS (unauthenticated IPsec)

Thank You