Spring 2004 IP Security School of Electronics and Information Kyung Hee University Choong Seon HONG [email protected] Summarized

Spring 2004

IP SecurityIP Security

School of Electronics and Information

Kyung Hee University

Choong Seon [email protected]://networking.khu.ac.kr

Summarized Chapter 6 of “Network Security Essentials” by William Stallings +

2Spring 2004

IP Security OverviewIP Security Overview

1994 – RFC1636, Security in the Internet Architecture

Identified key needs: secure network infrastructure from unauthorized

monitoring control network traffic secure end-to-end user traffic using encryption

and authentication

3Spring 2004

IP Security OverviewIP Security Overview

CERT – most serious attacks are IP spoofing and eavesdropping/packet sniffing recently DDoS

Next generation IP includes authentication and encryption

IPv6 IPSec IPv6Available with IPv4

4Spring 2004

Application of IPSecApplication of IPSec

Secure branch office connectivity over the Internet

Secure remote access over the InternetEstablishing extranet and intranet

connectivity with partnersEnhancing electronic commerce security

5Spring 2004

Application of IP SecurityApplication of IP Security

6Spring 2004

Benefits of IPSecBenefits of IPSec

Strong security for all traffic when crossing the perimeter (assuming it is implemented in a firewall or router)

IPSec in a firewall is resistant to bypass Below the transport layer (TCP, UDP) and transparen

t to applications Transparent to the end user Provides security for individual users – offsite worker

s, VPN

7Spring 2004

Routing & IPSecRouting & IPSec

Router advertisement comes from an authorized router

Neighbor advertisement comes from an authorized router

Redirect comes from router to which initial packet was sent

Routing updates are not forged Prevents disruption and diversion of traffic

8Spring 2004

Network SecurityNetwork Security

Basic Networking

9Spring 2004

TCP and UDP HeadersTCP and UDP Headers

10Spring 2004

IP HeadersIP Headers

128-bit field

32-bit field

QoS

max # allowable hops

11Spring 2004

TP/IP ConceptsTP/IP Concepts

12Spring 2004

PDUs in TCP/IPPDUs in TCP/IP

TCPHeade

r

User Data

IPHeader

User Data

NetworkHeader

User Data

User Data

Application Byte Stream

TCPSegment

IP Datagram

Network-level Packet

13Spring 2004

Some TCP/IP ProtocolsSome TCP/IP Protocols

14Spring 2004

Assigned Port NumbersAssigned Port Numbers

Port Service Port Service

7 echo 110 pop3

20 ftp-data 119 nntp

21 ftp 123 ntp

23 telnet 389 ldap

25 smtp 443 https

39 rip 500 isakmp

53 DNS 520 rip2

80 http 1812 radiusauth

88 kerberos 2049 Sun NFS

15Spring 2004

Configuration of TCP/IPConfiguration of TCP/IP

16Spring 2004

Network SecurityNetwork Security

IP Security – Part 1

17Spring 2004

IPSec DocumentsIPSec Documents

November - 1998 RFC 2401 – Overview RFC 2402 – packet authentication extension RFC 2406 – packet encryption extension RFC 2408 – key management capabilities

Implemented as extension headers that follow the main header: Authentication Header (AH) Encapsulating Security Payload Header (ESP)

18Spring 2004

IPSec DocumentsIPSec Documents

packet format

Domain of Interpretationrelation between documents(identifiers and parameters)

19Spring 2004

IPSec ServicesIPSec Services

Provides security services at the IP layerEnables a system to:

select required security protocols determine algorithms to use setup needed keys

20Spring 2004

IPSec Services – 2 ProtocolsIPSec Services – 2 Protocols

Authentication protocol – designated by the authentication header (AH)

Encryption/Authentication protocol – designated by the format of the packet, Encapsulating Security Payload (ESP); it is a mechanism for providing integrity and confidentiality to IP datagrams

AH and ESP are vehicles for access control

21Spring 2004

IPSec ServicesIPSec Services

22Spring 2004

Security AssociationsSecurity Associations

Key Concept:Security Association (SA) – is a one-way

relationship between a sender and a receiver that defines the security services that are provided to a user

Requirements are stored in two databases: security policy database (SPD) and security association database (SAD)

23Spring 2004


Uniquely identified by:Destination IP address – address of the

destination endpoint of the SA (end user system or firewall/router)

Security protocol – whether association is AH or ESP. Defines key size, lifetime and crypto algorithms (transforms)

Security parameter index (SPI) – bit string that provides the receiving device with info on how to process the incoming traffic

24Spring 2004


IP Secure Tunnel

SA SA

A B

1. Destination IP address2. Security Protocol3. Secret keys4. Encapsulation mode5. SPI

25Spring 2004


SA is unidirectional It defines the operations that occur in the transm

ission in one direction onlyBi-directional transport of traffic requires a pair o

f SAs (e.g., secure tunnel)Two SAs use the same meta-characteristics but

employ different keys

26Spring 2004

Security Association DatabaseSecurity Association Database

Each IPSec implementation has a Security Association Database (SAD)

SAD defines the parameters association (SPI) with each SA

SAD stores pairs of SA, since SAs are unidirectional

27Spring 2004

Security Association DatabaseSecurity Association Database

Sequence number counter Sequence counter overflow Anti-replay window AH information ESP information Lifetime of this SA IPSec protocol mode – tunnel, transport, wildcard Path MTU

28Spring 2004

Security Policy DatabaseSecurity Policy Database

Considerable flexibility in way IPSec services are applied to IP traffic

Can discriminate between traffic that is afforded IPSec protection and traffic allowed to bypass IPSec

The Security Policy Database (SPD) is the means by which IP traffic is related to specific SAs

29Spring 2004


Each entry defines a subset of IP traffic and points to an SA for that traffic

These selectors are used to filter outgoing traffic in order to map it into a particular SA

30Spring 2004


Destination IP address Source IP address User ID Data sensitivity level – secret or unclassified Transport layer protocol IPSec protocol – AH or ESP or AH/ESP Source and destination ports IPv6 class IPv6 flow label IPv4 type of service (TOS)

31Spring 2004


Outbound processing for each packet:

1. Compare fields in the packet to find a matching SPD entry

2. Determine the SA and its associated SPI

3. Do the required IPSec processing

32Spring 2004

Transport and Tunnel ModesTransport and Tunnel Modes

SA supports two modes:

Transport – protection for the upper layer protocols

Tunnel – protection for the entire IP packet

33Spring 2004

Transport ModeTransport Mode

Protection extends to the payload of an IP packet

Primarily for upper layer protocols – TCP, UDP, ICMP

Mostly used for end-to-end communicationFor AH or ESP the payload is the data following

the IP header (IPv4) and IPv6 extensionsEncrypts and/or authenticates the payload, but

not the IP header

34Spring 2004

Tunnel ModeTunnel Mode

Protection for the entire packetAdd new outer IP packet with a new outer

headerAH or ESP fields are added to the IP packet

and entire packet is treated as payload of the outer packet

Packet travels through a tunnel from point to point in the network

35Spring 2004

Tunnel and Transport ModeTunnel and Transport Mode

Transport Mode SA Tunnel Mode SA

AH Authenticates IP payload and selected portions of IP header and IPv6 extension headers

Authenticates entire inner IP packet plus selected portions of outer IP header

ESP Encrypts IP payload and any IPv6 extesion header

Encrypts inner IP packet

ESP with authentication

Encrypts IP payload and any IPv6 extension header. Authenticates IP payload but no IP header

Encrypts inner IP packet. Authenticates inner IP packet.

36Spring 2004

Transport vs Tunnel ModeTransport vs Tunnel Mode

37Spring 2004

Authentication HeaderAuthentication Header

38Spring 2004

Authentication Header (2)Authentication Header (2)What is AH ?

A mechanism for providing strong integrity and authentication for IP datagrams

Provide secure communication using shared secret key and key exchange mechanism

Security Service by AH Authentication

• Data origin authentication using authentication data (MD5, SHA-1)

Integrity • Provide connectionless integrity based on individual IP datagram

Anti-replay attack • Protect replay attack using sequence number

39Spring 2004

Authentication Header (2)Authentication Header (2)

Security Mechanism Default Implementation : HMAC with MD5

and SHA-1 Negotiation (HMAC-MD5-96, HMAC-SHA-

1-96, No Service, etc)

40Spring 2004

IPSec Authentication HeaderIPSec Authentication Header

41Spring 2004

Authentication HeaderAuthentication Header

Next Header (8bits): type of immediately following header (e.g TCP=6)

Payload length (8 bits): Length of AH in 32-bit words minus 2

Security Parameters Index (32 bits): Identifies (with destination IP address) a security association

(SA)

Sequence Number (32 bits): Monotonically increasing counter up to 232 -1 (to discard

replayed packets)

Authentication Data (variable): variable field that contains the Integrity Check Value (ICV), o

r MAC

42Spring 2004

Anti-Replay ServiceAnti-Replay Service

Replay Attack: Obtain a copy of authenticated packet and later transmit to the intended destination

Mainly disrupts serviceSequence number is designed to prevent this

type of attack

43Spring 2004


Sender initializes seq num counter to 0 and increments as each packet is sent

Seq num < 232; otherwise new SA If the limit of 232 – 1 is reached, the sender termin

ates this SA

IP is connectionless, unreliable service• So, not delivered in order

AccordinglyAccordingly

Receiver implements window of WRight edge of window is highest seq num, N, r

eceived so far

44Spring 2004


Received packet within window & new, check MAC, if authenticated mark slot

Packet to the right of window, do check/mark & advance window to new seq num which is the new right edge

Packet to the left, or authentication fails, discard packet, & flag event

45Spring 2004


Replay attack: getting a copy of an authenticated packet and then transmitting it to the intended destination

Each time a packet is sent on a SA, the sender increments the Sequence Number Counter (of SA) and places the values in the Sequence Number field (of AH)

Remember IP is a connectionless, unreliable service: packets may not all be delivered, and not in order

46Spring 2004


47Spring 2004

Anti-Replay ProcessingAnti-Replay Processing

1. If received packet is in the Window and new, MAC is checked. If OK, slot is marked

2. If to the right of the window and new, MAC is checked. If OK, window is moved to the right and slot is marked

3. If to the left of the window or if MAC not OK or not new, packet is discarded

48Spring 2004

Anti-Replay MechanismAnti-Replay Mechanism

W = 64N = 104

49Spring 2004

Integrity Check ValueIntegrity Check Value

Contained in the Authentication Data field Is a truncated version of a code produced by a MAC

algorithm (HMAC-MD5-96, HMAC-SHA-1-96), using the first 96 bits (default length of the Authentication Data field)

The MAC is calculated over: “immutable” or “predictable” IP header fields (TTL is mutable;

destination address, with source routing, is predictable) The AH header other than the Authentication Data field The upper level protocol data (like a TCP segment)

50Spring 2004

End-to-end AuthenticationEnd-to-end Authentication

tunnel

transport

Two Ways To Use IPSec Authentication Service

51Spring 2004

AH Tunnel and Transport ModesAH Tunnel and Transport Modes

Considerations are different for IPv4 and IPv6Authentication covers the entire packetMutable fields are set to 0 for MAC

calculation

52Spring 2004

IPv4 and IPv6 PacketsIPv4 and IPv6 Packets

53Spring 2004

Transport Mode AHTransport Mode AH

54Spring 2004

Tunnel Mode AHTunnel Mode AH

Could be addresses of firewall or other security gateways

55Spring 2004

Encryption + Authentication:Encryption + Authentication: ESP Encapsulating Security Payload ESP Encapsulating Security Payload

Encrypts and optionally authenticates payload, but not IP header

DES in CBC (cipher block chaining) mode and others

Guards against replay attacksTo be combined with AH for “full” authenticationESP support use of a 96bit MAC similar to AH

56Spring 2004

ESP Header and encription scopeESP Header and encription scope

57Spring 2004

ESP Header (1)ESP Header (1)

Security Parameters Index (32 bits): Identifies (with destination IP address) a security association

(SA) (same as in AH)

Sequence Number (32 bits): Protects against replay attacks, as in AH

Payload Data (variable): Transport level segment or IP Packet protected by

encryption (preceded by IV, when needed)

IV : initialization vector

58Spring 2004

ESP Header (2)ESP Header (2)

Padding (0-255 bits): Requested by encryption algorithms Used for assuring alignment

Pad length (8 bits): How much padding was added

Next header (8bits): Identifies the type of data contained in the payload datafield by

identifying the first header in that payload (e.g. TCP) Authentication Data (variable):

Carries the Integrity Check Value, as in AH

59Spring 2004

Transport-Level SecurityTransport-Level Security

60Spring 2004

A VPN (with encryption) viaA VPN (with encryption) via Tunnel Mode Tunnel Mode

61Spring 2004

IPv4 and IPv6 PacketsIPv4 and IPv6 Packets

62Spring 2004

Transport Mode ESP Transport Mode ESP

63Spring 2004

Transport Mode ESP OperationTransport Mode ESP Operation

1. ESP trailer + transport-layer segment is encrypted. Ciphertext replaces plaintext in the IP packet for transmission. Authentication added if selected.

2. Packet routed to destination. Intermediate routers do not need to examine ciphertext

3. Dest Node examines and processes the IP header + ext headers. Then on the basis of the SPI in the ESP header decrypts the remainder of the packet

64Spring 2004

ESP Tunnel ModeESP Tunnel Mode

65Spring 2004

Tunnel Mode ESP OperationTunnel Mode ESP Operation

1. Source prepares a inner packet with destination address of the target internal host, prefixed by an ESP header; then packet and ESP trailer are encrypted and Authentication Data may be added. Resulting block encapsulated with a new IP header

2. Outer packet routed to destination firewall. No need to examine ciphertext by intermediate routers

66Spring 2004

Tunnel Mode ESP OperationTunnel Mode ESP Operation

3. Destination firewall examines and processes the outer IP header plus any extension headers. Then on the basis of the SPI in the ESP header, decrypts the remainder of the packet to recover plaintext inner packet. This packet is then transmitted in the internal network

4. The inner packet is routed through zero or more routers in the internal network to the destination host

67Spring 2004

Transport Mode SA Tunnel Mode SA

AH Authenticates IP payload and selected portions of IP header and IPv6 extension headers

Authenticates entire inner IP packet plus selected portions of outer IP header

ESP Encrypts IP payload and any IPv6 extesion header

Encrypts inner IP packet

ESP with authentication

Encrypts IP payload and any IPv6 extension header. Authenticates IP payload but no IP header

Encrypts inner IP packet. Authenticates inner IP packet.

Tunnel Mode and Transport Mode Tunnel Mode and Transport Mode FunctionalityFunctionality

68Spring 2004

Why so many combinations!?Why so many combinations!?

To support different VPN arrangements, to meet different security and deployment-practicality requirements

Wouldn’t be enough Tunnel Mode ESP?

69Spring 2004

Combining SAsCombining SAs

SA can implement either AH or ESP protocol, but not both

Traffic flow may require separate IPSec services between hosts, than gateways

Need for multiple SAsSecurity Association Bundle refers to a sequenc

e of SAsSAs in a bundle may terminate at different end p

oints

70Spring 2004

Combining Authentication and ConfidentialityCombining Authentication and Confidentiality

ESP with Authentication Option Transport mode Tunnel mode

Transport Adjacency Inner ESP (w/o authentication) SA Outer AH SA Pros: authentication covers more fields, including source and destination IP

addresses Cons: 2 SAs vs 1 SAs

Transport-Tunnel Bundle Authentication before encryption Inner AH transport SA Outer ESP tunnel SA Entire authenticated inner packet is encrypted; new outer IP header is

added

71Spring 2004

Basic Combinations – Case 1Basic Combinations – Case 1

All security is provided between end systems that implement IPSec

Possible combinationsa. AH in transport modeb. ESP in transport modec. AH followed by ESP in transport mode (an AH SA insid

e an ESP SA)d. Any one of a, b, or c inside an AH or ESP in tunnel mo

de

72Spring 2004

Basic Combinations of SecurityBasic Combinations of Security Associations – Case 1 Associations – Case 1

73Spring 2004


Security is provided only between gateways and no hosts implement IPSec

VPN – Virtual Private Network Only single tunnel needed (support AH, ESP or

ESP w/auth)

74Spring 2004

Basic Combinations of Security Basic Combinations of Security Associations – Case 2 Associations – Case 2

75Spring 2004


Builds on Case 2 by adding end-to-end security

Gateway-to-gateway tunnel Individual hosts can implement additional IPSe

c services via end-to-end SAs

76Spring 2004

Basic Combinations of Security Basic Combinations of Security Associations – Case 3 Associations – Case 3

77Spring 2004


Provides support for a remote host using the Internet and reaching behind a firewall

Only tunnel mode is required between the remote host and the firewall

One or two SAs may be used between the remote host and the local host

78Spring 2004

Basic Combinations of Security AssociationsBasic Combinations of Security Associations – Case 4 – Case 4

79Spring 2004

Key ManagementKey Management

Determination and distribution of secret keys Four keys for communication between two applications:

transmit and receive pairs for both AH & ESP

Two modes: manual and automated Two protocols:

Oakley Key Determination Protocol• a specific key exchange algorithm

Internet Security Association and Key Management Protocol (ISAKMP)

80Spring 2004

Oakley Key Based on Diffie-HellmanOakley Key Based on Diffie-Hellman

Refinement of the Diffie-Hellman key exchange algorithm

Secret keys created only when neededExchange requires no preexisting infrastructureDisadvantage: Subject to MITM (man-in-the mid

dle) attack

81Spring 2004

IPSec Key ManagementIPSec Key Management Security Security Goals Goals

Authentication of parties (by digital signature, public key encryption, or symmetric key encryption)

Establishment of a fresh shared secret Shared secret used to derive keys for channel

confidentiality and authentication “Perfect Forward Secrecy” Anti-clogging, against denial-of-service attacks Secure negotiation of algorithms: asymmetric (e.g. RSA,

elliptic curve), symmetric (e.g. 3DES, Blowfish, AES), and hash (e.g. MD5, SHA-1)

82Spring 2004

ISAKMPISAKMP

Internet Security Association and Key Management Protocol

Defines procedures and packet formats to establish, negotiate, modify, and delete SAs

Defines packet formats for exchanging key-generation and authentication data (framework only)

Does not dictate a specific key exchange algorithm

83Spring 2004

IKE and ISAKMPIKE and ISAKMP

IKE = Internet Key Exchange Documentation hard to follow The distinction is very confusing You may think of IKE as a profiling (i.e. defining fields, choosing

options) of ISAKMP or a specific adaptation of more general protocols (“Oakley” and “ISAKMP”)

It is made of 150 pages (80 for ISAKMP, 30 for DOI document, and 40 for IKE), nevertheless people were able to implement it and even interoperate

84Spring 2004

Oakley/IKEOakley/IKE

Oakley is a refinement of the Diffie-Hellman key exchange algorithm for use with the initial version of ISAKMP

85Spring 2004

Diffie-Hellman Protocol Attractive Diffie-Hellman Protocol Attractive FeaturesFeaturesSecret keys are created only when needed.

There is no need to store secret keys for a long period of time, exposing them to increased vulnerability

The exchange requires no preexisting infrastructure other than an agreement on the global parameters (p and g)

It provides Perfect Forward Secrecy

86Spring 2004

Perfect Forward SecrecyPerfect Forward Secrecy

A protocol is said to have perfect forward secrecy (PFS) if it is impossible for an eavesdropper S to decrypt a conversation between Alice and Bob even if S records the entire encrypted session, and then subsequently breaks into both Alice and Bob and steals their long-term secrets.

87Spring 2004

Examples of Protocols not having Examples of Protocols not having PFSPFSPublic Key encryption of the conversationKerberos (the session key is inside the ticket

and is encrypted with long-term key)Session key encrypted with public key

88Spring 2004

Diffie-Hellman WeaknessesDiffie-Hellman Weaknesses

It does not provide any information about the identities of the parties. It is subject to a man-in-the-middle attack

It is computationally intensive (modular exponentiation). Vulnerable to a clogging attack, requesting a high number of keys.

89Spring 2004

Perfect Forward SecrecyPerfect Forward Secrecy

The trick, used in DH, is to generate a temporary session key, not derivable from information stored at the node after the session concludes, and then forget it after the session concludes

In the first two messages, the DH quantity is signed in order to foil a man-in-the-middle attack

90Spring 2004

Features of OakleyFeatures of Oakley

Retains DH advantages while countering its weaknesses

It employs a mechanism known as cookies to thwart clogging attacks

It enables the two parties to negotiate a group (to specify DH global parameters)

It uses nonces to ensure against replay attacks

91Spring 2004

Features of Oakley (cont.)Features of Oakley (cont.)

It enables the exchange of DH public key values It authenticates the DH exchange to thwart man-in-

the-middle attacks. Different authentication methods can be used:

Public-key signatures Public-key encryption (original and revised) Pre-shared symmetric-key encryption

92Spring 2004

Cookie ExchangeCookie Exchange((Nothing to do with web browser cookies!)Nothing to do with web browser cookies!)

Each side sends a pseudorandom number, cookie, inn the initial message, which the other side ackniwledges.

This ACK must be repeated in the first message of the Diffie-Hellman key exchange.

If the source address was forged, the opponent gets no answer.

Thus, an opponent can only forge a user to generate acknowledgments and not to perform the DH calculation

93Spring 2004

Cookie Generation RequirementsCookie Generation Requirements

The cookie must depend on the specific parties: to prevent an attacker from obtaining a cookie using a real IP address and then using it to swamp the victim from randomly chosen IP addresses

It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. Cookies are not to be saved.

The cookie generation and verification methods must be fast to thwart attacks intended to sabotage processor resources

94Spring 2004

A Cookie ProtocolA Cookie Protocol

I want to talk

c

c, start of rest of protocolInit

iato

r Bob

c = hash(IP address, secret)

Does c = hash(IP address, secret)?If so, continue with protocol.

95Spring 2004

IPsec Key Exchange – IKEIPsec Key Exchange – IKE

Two levels of SA negotiated an initial ISAKMP SA (bidirectional, with heavy-duty

authentication and negotiation) then several “normal” SAs, negotiated quickly using initial

SA as secure channel; one for each direction and each AH and ESP

initial SA also used for error traffic and similar management traffic

96Spring 2004

IKE DetailsIKE Details

Two parties (Initiator and Responder) wishing to establish a common SA, call the ISAKMP.

Phase 1 (“main/aggressive mode” ) is the heavyweight exchange to establish a secure key management channel (ISAKMP SA) with the following

attributes: encryption algorithm, hashing function, authentication method, DH global parameters.

ISAKMP SA is a bidirectional channel providing both confidentiality and authenticity.

Phase 2 (“quick mode”) establishes SAs for IPSec itself, using the Phase 1 ISAKMP SA

97Spring 2004

Why two phases?Why two phases?

ISAKMP theoretically usable to establish SAs for protocols different from IPSec

Different SAs for different traffic flows; one for each source/destination pair

Key rollover (changing keys in the middle of a conversation) is cheaper than use of phase 2

98Spring 2004

Phase 1 ModesPhase 1 Modes

Main mode: slower, more cautious, hides details of credentials used and allows forward secrecy (independence of short-term keys)

Aggressive mode: less negotiation, fewer round trips, more information disclosed

99Spring 2004

IKE Phase 2/Quick ModeIKE Phase 2/Quick Mode

Once an IKAMP SA is set up, an IPsec SA can be initiated by any of the two party

Quick mode exchange establishes an ESP and/or AH SA, which involves negotiating crypto parameters, optionally doing a D-H exchange and negotiating what traffic will be sent on the SA

100Spring 2004

ISAKMP/IKE EncodingISAKMP/IKE Encoding

Messages have a fixed header, and a sequence of what ISAKMP refers to as payloads. Similar in spirit to IPv6 extension headers.

There are several Payload Types used for different purposes

101Spring 2004

ISAKMP Payload TypesISAKMP Payload Types

102Spring 2004

ISAKMP FormatsISAKMP Formats

May be more than one

103Spring 2004

IPsec in the Operating SystemsIPsec in the Operating Systems

Implemented in all most recent Unix versions Implemented by SUN with SKIP; the others with

ISAKMP+OAKLEY FreeS/WAN (Linux): an opensource project “to make

the Internet more secure and more private” www.freeswan.org

After trying to roll-its-own with PPTP, MS has put IPSec into WinXP

* Linux FreeS/WAN is an implementation of IPSEC & IKE for Linux

* Point-to-Point Tunneling Protocol (PPTP).

104Spring 2004

IPsec in the Routers IPsec in the Routers

main vendors (Cisco, 3COM, Nortel, ..)Normally used between routers, but not with

the end nodesCisco provides public key authentication with

X.509 certificates

105Spring 2004

ISAKMP ExchangesISAKMP Exchanges

Provides a framework for message exchangePayload type serve as the building blocksFive default exchange types specifiedSA refers to an SA payload with associated

Protocol and Transform payloads

106Spring 2004

ISAKMP Exchange TypesISAKMP Exchange Types

107Spring 2004

EtherealEthereal

Ethereal is a free network protocol analyzer for Unix and Windows

Packet Sniffer - data can be captured "off the wire" from a live network connection

http://www.ethereal.com

108Spring 2004

Important URLsImportant URLs

http://www.ethereal.com/ Home page for Ethereal, the free network protocol anal

yzer for Unix and Windows http://naughty.monkey.org/~dugsong/dsniff/

A suite of powerful tools for sniffing networks for passwords and other information (UNIX).

http://www.insecure.org/tools.htmlSite has the top 50 security tools

http://www.protocols.com/A comprehensive listing of data communications protocols

http://packetstormsecurity.nl/sniffers

A comprehensive list of sniffers

109Spring 2004

Related RFCsRelated RFCs

Basic Specifications Security Architecture of the Internet Protocol (RFC 2401) IP Authentication Header (AH) (RFC 2402) IP Encapsulation Security Payload (ESP) (RFC 2406)

Authentication Algorithms IP Authentication using Keyed MD5 (RFC1828) HMAC: Keyed-Hashing for Message Authentication (RFC 2104) HMAC-MD5 IP Authentication with Replay Prevention (RFC 2085) The Use of HMAC-MD5-96 within ESP and AH(RFC 2403) The Use of HMAC-SHA-1-96 within ESP and AH(RFC 2404) The ESP DES-CBC Cipher Algorithm With Explicit IV(RFC2405)

Encryption Algorithms The ESP DES-CBC transform (RFC 1829) The NULL encryption algorithm and its use with IPsec(RFC 2410) The ESP CBC-mode cipher algorithms(RFC 2451)

Key Management The OAKLEY key determination protocol(RFC 2412) The Internet IP security domain of interpretation for ISAKMP(RFC 2407) Internet security association & key management protocol (ISAKMP)(RFC 2408) The internet key exchange (IKE)(RFC 2409) IP security document roadmap(RFC