Internet security csce 813 ipsec
1 / 31

Internet Security CSCE 813 IPsec - PowerPoint PPT Presentation

  • Uploaded on

Internet Security CSCE 813 IPsec. Reading. Oppliger: Chapter 14. Benefits of IPSec. When implemented in a firewall or router, IPSec provides strong security to ALL TRAFFIC crossing the perimeter. Traffic within the perimeter does not incur security overhead.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Internet Security CSCE 813 IPsec' - zola

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Internet security csce 813 ipsec

Internet Security CSCE 813IPsec


  • Oppliger: Chapter 14

CSCE 813 - Farkas

Benefits of ipsec
Benefits of IPSec

  • When implemented in a firewall or router, IPSec provides strong security to ALL TRAFFIC crossing the perimeter. Traffic within the perimeter does not incur security overhead.

  • Cannot be bypassed (if all traffic must go through the firewall implementing IPSec)

  • Transparent to applications

  • Transparent to end users

CSCE 813 - Farkas

Ip security architecture

IPsec module 1

IPsec module 2










IP Security Architecture

RFC 2401: Overview of Security Architecture

RFC 2402: Desc. Of packet authentication extension to IPv4 and IPv6

RFC 2406: Desc. Of packet encryption extension to IPv4 and IPv6

RFC 2408: Specification of key management capabilities

CSCE 813 - Farkas

Ipsec document overview rfc 2401




Enryption algs.

Authentication algs.


Key Management

IPSec Document OverviewRFC 2401

CSCE 813 - Farkas

Ipsec services
IPSec Services

CSCE 813 - Farkas

Security association
Security Association

  • One-way relationship

  • Identified by:

    • Security parameters index (SPI)

    • IP destination address

    • Security protocol identifier

  • Security Association Database:

    • SA parameters: sequence number counter, sequence number overflow, anti-replay window, AH information, ESP information, lifetime of SA, IPSec protocol mode, path MTU

  • Security Policy Database:

    • SA selectors: destination IP address, source IP address, UserID, Data Sensitivity Level, transport layer protocol, source and destination port

CSCE 813 - Farkas


CSCE 813 - Farkas


  • Confidentiality: Encryptor

  • Integrity: Authenticator

  • Algorithm is determined by the Security Association (SA)

  • Each ESP has at most:

    • One cipher and one authenticator or

    • One cipher and zero authenticator or

    • Zero cipher and one authenticator or

    • Disallowed: zero cipher and zero authenticator or

CSCE 813 - Farkas

Esp processing
ESP Processing

  • Depends on mode in which ESP is employed

  • Both modes:

    • Cipher is authenticated

    • Authenticated plain text is not encrypted

  • Outbound: encryption happens first

  • Inbound: authentication happens first

CSCE 813 - Farkas

Protected data
Protected Data

  • Depends on the mode of ESP

    • Transport mode: Upper-layer protocol packet

    • Tunnel mode: entire IP packet is protected

CSCE 813 - Farkas

Scope of esp encryption and authentication
Scope of ESP Encryption and Authentication

Transport mode




Tunnel mode



CSCE 813 - Farkas

Outbound processing
Outbound Processing

  • ESP headerinserted into the outgoing IP packet

    • Protocol field of IP header copied into Next header field of ESP

    • Remaining fields of ESP filled (SPI, sequence number, pad, pad length)

    • Protocol number of IP header is given the value ESP (50)

  • Encrypt packet from the beginning of payload data to the next header field

  • Authenticate packet form the ESP header, through the encrypted ciphertext to the ESP trailer and insert authentication data into ESP trailer

  • Packet is routed to the destination

CSCE 813 - Farkas

Inbound processing
Inbound Processing

  • Check for SA of the packet

    • If no SA  drop packet

    • Otherwise: use valid SA to process the packet

  • Check sequence number

    • Invalid number  drop packet

  • Authenticate cipher text

    • Entire packet (without the authentication data) is processed by the authenticator

    • Match generated data with authentication data

    • No match  drop packet

CSCE 813 - Farkas

Inbound processing1
Inbound Processing

  • Decrypt ESP packet (from beginning on payload to the next header field)

    • Check pad integrity

  • Validate ESP mode using Next header field and decrypted payload

CSCE 813 - Farkas

Authentication header ah
Authentication Header (AH)

  • Does NOT provide confidentiality

  • Provides:

    • Data origin authentication

    • Connectionless data integrity

    • Prevents spoofing attack

  • May provide:

    • Non-repudiation (depends on cryptographic alg.)

    • Anti-replay protection

  • Precision of authentication: granularity of SA

  • Protocol number: 51

CSCE 813 - Farkas

Authentication data
Authentication Data

  • AH protects outer IP header (unlike ESP)

  • Computed by using

    • Authentication algorithm (MD5, SHA-1)

    • Cryptographic key (secret key)

  • Sender: computes authentication data

  • Recipient: verifies data

CSCE 813 - Farkas

Scope of authentication
Scope of Authentication

Transport Mode

Authenticates except for mutable fields


Tunnel Mode

Authenticates except for mutable fields in NEW IP hdr


CSCE 813 - Farkas

Integrity check values
Integrity Check Values

  • Message Authentication Code is Calculated from:

    • IP header fields that either do not change in transit or are predictable upon arrival – Fields that change and cannot be predicted are set to zero for the MAC calculation

    • AH header -- other than the authentication data field

    • Entire upper level protocol data

  • Note: both source and destination address fields are protected

CSCE 813 - Farkas

Sa bundle
SA Bundle

  • Individual SA: either AH or ESP but NOT BOTH

  • Some traffic flow needs both – HOW?

  • Some traffic between host and security gateway requires different services than flow between security gateways

  • Security Association Bundle:

    • sequence of SAs through which traffic must be processed to provide a desired set of IPSec services

    • SAs within a bundle may terminate at different end points

CSCE 813 - Farkas

Sa combinations
SA Combinations

  • Transport adjacency:

    • Applying more than one security protocol to the same IP packet without invoking tunneling.

    • Allows 1 level of combination (all IPSec processing are performed at one IPSec instance)

  • Iterated tunneling:

    • Multiple layers of security protocols efected through IP tunneling

    • Multiple levels of nesting (each tunnel may originate and terminate at different IPSec site)

  • Combination of the two approaches above.

CSCE 813 - Farkas

Transport adjacency
Transport Adjacency

Two bundled transport Sas

Inner SA: ESP transport SA without authentication (encrypted IP payload)

Outer SA: AH transport SA (covers ESP and the original IP header)

CSCE 813 - Farkas

Transport tunnel bundle
Transport-Tunnel Bundle

Authenticate before encrypting

Inner SA: AH transport SA (authenticates the entire IP payload + IP header)

Outer SA: ESP tunnel SA (entire authenticated packet is encrypted + new IP header)


Authentication data is protected by encryption

Can store authentication information with the message (convenience)

CSCE 813 - Farkas

Combining security associations1

one or more SAs






  • Possible combinations:

  • AH in transport

  • ESP in transport

  • ESP followed by AH in transport

  • Any 1,2,3 inside an AH or ESP

  • tunnel

Combining Security Associations

  • Case 1: between end-systems

Figure from L. Buttyan

CSCE 813 - Farkas

Combining security associations2

single tunnel SA






  • Security provided:

  • Only between gateways

  • No host security

  • Only single tunnel SA

  • AH, ESP or ESP with

  • authentication

Combining Security Associations

  • Case 2: between gateways only

Figure from L. Buttyan

CSCE 813 - Farkas

Combining security associations3

single tunnel SA

One or two SAs






  • End-to-end protection:

  • Combinations for case 1 &2 allowed

  • Gateway tunnel: authentication and

  • confidentiality

  • 3. Hosts: application specific IPSec

Combining Security Associations

Case 3: host-to-gateway (Case 2 + end-to-end security)

Figure from L. Buttyan

CSCE 813 - Farkas

Combining security associations4

Tunnel SA




  • Remote host:

  • Host: tunnel mode to firewall

Combining Security Associations

  • Case 4: remote host

One or two SAs

Figure from L. Buttyan

CSCE 813 - Farkas

Next class key management isakmp exchanges
Next Class: Key ManagementISAKMPExchanges

CSCE 813 - Farkas