Ipsec 2

IP Security
Mr. Sourabh S. Badve

IP Security
 Have a range of application specific security mechanisms
 eg. S/MIME, PGP, Kerberos, SSL/HTTPS
 However there are security concerns that cut across protocol
layers
 Would like security implemented by the network for all
applications

IPSec
 General IP Security mechanisms
 Provides
 authentication
 confidentiality
 key management
 Applicable to use over LANs, across public & private WANs,
& for the Internet

Benefits of IPSec
 In a firewall/router provides strong security to all traffic crossing the
perimeter
 In a firewall/router is resistant to bypass
 Is below transport layer, hence transparent to applications
 Can be transparent to end users
 Can provide security for individual users
 Secures routing architecture

IP Security Architecture
 Specification is quite complex
 Defined in numerous RFC’s
 incl. RFC 2401/2402/2406/2408
 many others, grouped by category
 Mandatory in IPv6, optional in IPv4
 Have two security header extensions:
 Authentication Header (AH)
 Encapsulating Security Payload (ESP)

Architecture & Concepts
 Tunnel vs. Transport mode
 Security association (SA)
 Security parameter index (SPI)
 Security policy database (SPD)
 SA database (SAD)
 Authentication header (AH)
 Encapsulating security payload (ESP)
 Practical Issues w/ NAT

A B
Encrypted Tunnel
Gateway 1 Gateway 2
New IP
Header
AH or ESP
Header
TCP DataOrig IP
Header
Encrypted
Transport Mode vs. Tunnel Mode
 Transport mode: host -> host
 Tunnel mode: host->gateway or gateway->gateway

Transport Mode
 ESP protects higher layer payload only
 AH can protect IP headers as well as higher layer payload
IP
header
IP
options
IPSec
header
Higher
layer protocol
ESP
AH
Real IP
destination

Tunnel Mode
 ESP applies only to the tunneled packet
 AH can be applied to portions of the outer header
Outer IP
header
Inner IP
header
IPSec
header
Higher
layer protocol
ESP
AH
Real IP destinationDestination
IPSec
entity

Security Association - SA
 Defined by 3 parameters:
 Security Parameters Index (SPI)
 IP Destination Address
 Security Protocol Identifier
 Have a database of Security Associations
 Determine IPSec processing for senders
 Determine IPSec decoding for destination
 SAs are not fixed! Generated and customized per traffic flows

Security Parameters Index - SPI
 Can be up to 32 bits large
 The SPI allows the destination to select the correct SA under which
the received packet will be processed
 According to the agreement with the sender
 The SPI is sent with the packet by the sender
 SPI + Dest IP address + IPSec Protocol (AH or ESP) uniquely
identifies a SA

SA Database - SAD
 Holds parameters for each SA
 Lifetime of this SA
 AH and ESP information
 Tunnel or transport mode
 Every host or gateway participating in IPSec has their own
SA database

Security Policy Database - SPD
 What traffic to protect?
 Policy entries define which SA or SA bundles to use on IP traffic
 Each host or gateway has their own SPD
 Index into SPD by Selector fields
 Dest IP, Source IP, Transport Protocol, IPSec Protocol, Source & Dest
Ports, …

SPD Entry Actions
 Discard
 Do not let in or out
 Bypass
 Outbound: do not apply IPSec
 Inbound: do not expect IPSec
 Protect – will point to an SA or SA bundle
 Outbound: apply security
 Inbound: check that security must have been applied

SPD Protect Action
 If the SA does not exist…
 Outbound processing: use IKE to generate SA dynamically
 Inbound processing: drop packet

Is it for IPSec?
If so, which policy
entry to select?
…
SPD
(Policy)
…
SA
Database
IP Packet
Outbound packet (on A)
A B
SPI & IPSec
Packet
Send to B
Determine the SA
and its SPI
IPSec processing
Outbound Processing

Use SPI to
index the SAD
…
SA Database
Original IP Packet
SPI & Packet
Inbound packet (on B) A B
From A
Inbound Processing
…
SPD
(Policy)
Was packet properly
secured?
“un-process”

Authenticated Header
 Data integrity
 Entire packet has not been tampered with
 Authentication
 Can “trust” IP address source
 Use MAC to authenticate
 Symmetric encryption, e.g, DES
 One-way hash functions, e.g, HMAC-MD5-96 or HMAC-SHA-1-96
 Anti-replay feature
 Integrity check value

…
SAD
SPI
Sequence Number
ICV
Next Header
(TCP/UDP)
Payload Length
Reserved
IPSec Authenticated Header
Length of the authentication header

Integrity Check Value - ICV
 Keyed Message authentication code (MAC) calculated over
 IP header field that do not change or are predictable
 Source IP address, destination IP, header length, etc.
 Prevent spoofing
 Mutable fields excluded: e.g., time-to-live (TTL), IP header checksum, etc.
 IPSec protocol header except the ICV value field
 Upper-level data
 Code may be truncated to first 96 bits

AH: Tunnel and Transport Mode
 Original
 Transport Mode
 Cover most of the original
packet
 Tunnel Mode
 Cover entire original packet

Encapsulating Security Payload (ESP)
 Provide message content confidentiality
 Provide limited traffic flow confidentiality
 Can optionally provide the same authentication services as AH
 Supports range of ciphers, modes, padding
 Incl. DES, Triple-DES, RC5, IDEA, CAST etc
 A variant of DES most common
 Pad to meet blocksize, for traffic flow

ESP: Tunnel and Transport Mode
 Original
 Transport Mode
 Good for host to host traffic
 Tunnel Mode
 Good for VPNs, gateway to
gateway security

Outbound Packet Processing
 Form ESP header
 Security parameter index (SPI)
 Sequence number
 Pad as necessary
 Encrypt result [payload, padding, pad length, next header]
 Apply authentication (optional)
 Allow rapid detection of replayed/bogus packets
 Integrity Check Value (ICV) includes whole ESP packet minus authentication
data field

SPI
Sequence Number
Original IP Header
Integrity Check Value
Authenticationcoverage
Encrypted
Payload (TCP Header and Data)
Variable Length
Pad
Length
Padding (0-255 bytes)
Next
Header
ESPTransportExample

Inbound Packet Processing...
 Sequence number checking
 Duplicates are rejected!
 Packet decryption
 Decrypt quantity [ESP payload,padding,pad length,next header] per
SA specification
 Processing (stripping) padding per encryption algorithm
 Reconstruct the original IP datagram
 Authentication verification (optional)
 Allow potential parallel processing - decryption & verifying
authentication code

NATs
Network address translation = local, LAN-specific
address space translated to small number of
globally routable IP addresses
Motivation:
Scarce address space
Security: prevent unsolicited inbound requests
Prevalence of NATs
Claim: 50% of broadband users are behind NATs
All Linksys/D-Link/Netgear home routers are NATs

NAT types
 All use net-10/8 (10.*.*.*) or 192.168/16
 Address translation
 Address-and-port translation (NAPT)
 most common form today, still called NAT
 one external (global) IP address
 Change IP header and TCP/UDP headers

NAT ExampleIAP’s Point of Presence
Router with NAT
External IP: 68.40.162.3
Internal IP: 192.168.0.0
Router assigns internal
IPs to hosts on LAN :
A: 192.168.0.100
B: 192.168.0.101
C: 192.168.0.102
A B C
Messages sent between host B
to another host on the Internet
Host B original source socket:
192.168.0.101 port 1341
Host B translated socket:
68.40.162.3 port 5280

Will IPSec Work with NAT ?
 Consider both AH and ESP protocols.
 Consider both transport and tunnel modes. For tunnel mode, consider the
following two cases
 Sender – NAT – IPSec Gateway 1 – IPSec Gateway 2 – Receiver
 Sender – IPSec Gateway 1 – NAT – IPSec Gateway 2 – Receiver
 What about w/o port # translation?

Combining Security Associations
 SA’s can implement either AH or ESP
 to implement both need to combine SA’s
 form a security association bundle
 may terminate at different or same endpoints
 combined by
 transport adjacency
 iterated tunneling
 issue of authentication & encryption order

Combining Security Associations

SA Bundle
 More than 1 SA can apply to a packet
 Example: ESP does not authenticate new IP header. How to
authenticate?
 Use SA to apply ESP w/o authentication to original packet
 Use 2nd SA to apply AH

Outbound Packet Processing...
 Integrity Check Value (ICV) calculation
 ICV includes whole ESP packet minus authentication data field
 Implicit padding of ‘0’s between next header and authentication data is
used to satisfy block size requirement for ICV algorithm

Inbound Packet Processing
 Sequence number checking
 Anti-replay is used only if authentication is selected
 Sequence number should be the first ESP check on a packet upon
looking up an SA
 Duplicates are rejected!
0
Sliding Window
size >= 32
reject
Check bitmap, verify if new
verify

Anti-replay Feature
 Optional
 Information to enforce held in SA entry
 Sequence number counter - 32 bit for outgoing IPSec packets
 Anti-replay window
 32-bit
 Bit-map for detecting replayed packets

Anti-replay Sliding Window
 Window should not be advanced until the packet has been
authenticated
 Without authentication, malicious packets with large
sequence numbers can advance window unnecessarily
 Valid packets would be dropped!

ESP Processing - Header
Location...
 Tunnel mode IPv4 and IPv6
New
IP hdr
Orig
IP hdr
TCP Data
ESP
trailer
ESP
Auth
ESP
hdr
New
ext hdr
New
IP hdr
TCP Data
ESP
trailer
ESP
Auth
Orig
IP hdr
ESP
hdr
Orig
ext hdr
IPv4
IPv6

Key Management
 Handles key generation & distribution
 Typically need 2 pairs of keys
 2 per direction for AH & ESP
 Manual key management
 Sysadmin manually configures every system
 Automated key management
 Automated system for on demand creation of keys for SA’s in large systems

Ipsec 2

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to Ipsec 2 (20)

More from Sourabh Badve (8)

Recently uploaded (20)

Ipsec 2

Editor's Notes