1 / 26

IPsec ( ch 16~18)

IPsec ( ch 16~18). IT443 – Network Security Administration Instructor: Bo Sheng. Securing Networks. Applications Layer telnet/ftp: ssh , http: https , mail: PGP. ( SSL/TLS ) Transport Layer (TCP). Network Security Tools: Monitoring/Logging/Intrusion Detection. ( IPSec, IKE )

rock
Download Presentation

IPsec ( ch 16~18)

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPsec (ch 16~18) IT443 – Network Security Administration Instructor: Bo Sheng

  2. Securing Networks Applications Layer telnet/ftp: ssh, http: https, mail: PGP (SSL/TLS) Transport Layer (TCP) Network Security Tools: Monitoring/Logging/Intrusion Detection (IPSec, IKE) Network Layer (IP) Control/Management (configuration) Link Layer (IEEE802.1x/IEEE802.10) Physical Layer (spread-Spectrum, quantum crypto, etc.)

  3. IPsec Objectives • Why do we need IPsec? • IP V4 has no authentication • IP spoofing • Payload could be changed without detection. • IP V4 has no confidentiality mechanism • Eavesdropping • Denial of service (DoS) attacks • Cannot hold the attacker accountable due to the lack of authentication.

  4. IPsec Objectives • IP layer security mechanism for IPv4 and IPv6 • Not all applications need to be security aware • Can be transparent to users • Provide authentication and confidentiality mechanisms.

  5. IPsec Architecture IPsec module 1 IPsec module 2 SPD SPD IKE IKE IPsec SAD SAD IPsec SA SPD: Security Policy Database; IKE: Internet Key Exchange; SA: Security Association; SAD: Security Association Database.

  6. IPsec Architecture • Two Protocols (Mechanisms) • Authentication Header (AH) • Encapsulating Security Payload (ESP) • IKE Protocol • Internet Key Management

  7. IPsec Architecture • Can be implemented in • Host or gateway • Can work in two Modes • Tunnel mode • Transport mode • Hosts can implement IPsec to connect to: • Other hosts in transport or tunnel mode • Or Gateways in tunnel mode • Gateways to gateways • Tunnel mode

  8. Authentication Header (AH) • Data integrity • Entire packet has not been tampered with • Authentication • Can “trust” IP address source • Use MAC to authenticate • Anti-replay feature

  9. Encapsulated Security Protocol (ESP) • Confidentiality for upper layer protocol • Partial traffic flow confidentiality (Tunnel mode only) • Data origin authentication and connectionless integrity (optional)

  10. New IP Header AH or ESP Header Orig IP Header TCP Data Tunnel Mode Encrypted Tunnel Gateway Gateway Encrypted Unencrypted Unencrypted A B

  11. Tunnel Mode Outer IP header IPsec header Inner IP header Higher layer protocol ESP Real IP destination Destination IPsec entity AH • ESP applies only to the tunneled packet • AH can be applied to portions of the outer header

  12. New IP Header AH or ESP Header TCP Data Transport Mode Encrypted/Authenticated A B

  13. Transport Mode IP header IP options IPsec header Higher layer protocol ESP Real IP destination AH • ESP protects higher layer payload only • AH can protect IP headers as well as higher layer payload

  14. Security Association (SA) • An association between a sender and a receiver • Consists of a set of security related parameters • E.g., sequence number, encryption key • One way relationship • Determine IPsec processing for senders • Determine IPsec decoding for destination • SAs are not fixed! Generated and customized per traffic flows

  15. Security Parameters Index (SPI) • A 32-bits string assigned to an SA. • Carried in AH and ESP headers to enable the receiving system to select the SA under which the packet will be processed. • SPI + Dest IP address + IPsec Protocol • Uniquely identifies each SA in SA Database (SAD)

  16. SA Database (SAD) • Holds parameters for each SA • Sequence number counter • Lifetime of this SA • AH and ESP information • Tunnel or transport mode • Every host or gateway participating in IPsec has their own SA database

  17. 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/out authentication to original packet • Use 2nd SA to apply AH

  18. Security Policy Database (SPD) • Decide • What traffic to protect? • Has incoming traffic been properly secured? • 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 • Selectors: IP and upper-layer protocol field values. • Examples: Dest IP, Source IP, Transport Protocol, IPSec Protocol, Source & Dest Ports, …

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

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

  21. Issues • Firewalls • IPsec encrypts information used by firewalls to filter traffic (e.g., port number) • AH mutable/immutable/predictable fields: • Some fields get modified by the intermediate routers and can’t be protected by the AH • Mutable: type of service, flags, fragment offset, TTL, header checksum • Mutable but predictable fields are included in the AH computation using their expected value at the destination (e.g., destination address even when using source routing)

  22. Internet Key Exchange • Why do we need Internet key management • AH and ESP require encryption and authentication keys • Process to negotiate and establish IPsec SAs between two entities

  23. Security Principles • Basic security principle for session keys • Compromise of a session key • Doesn’t permit reuse of the compromised session key. • Doesn’t compromise future session keys and long-term keys. • Perfect forward secrecy (PFS) • Compromise of current keys (session key or long-term key) doesn’t compromise past session keys. • Concern for encryption keys but not for authentication keys.

  24. A Note about IKE • IKE v2 was introduced in RFC 4306 (December 2005) • IKE v2 does not interoperate with IKE v1 • Both version can unambiguously run over the same UDP port • IKE v2 combines the contents of previously separate documents • ISAKMP • IKE v1 • DOI • NAT • …

  25. IKE Overview • A separate RFC has been published for IKE • RFC 2409 • Request-response protocol • Initiator • Responder • Two phases • Phase 1: Establish an IKE (ISAKMP) SA • Essentially the ISAKMP phase 1 • Bi-directional • Phase 2: Use the IKE SA to establish IPsec SAs • Key exchange phase • Directional

  26. A Clarification About PFS • In RFC 2409: • When used in the memo Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. • The key used to protect transmission of data MUST NOT be used to derive any additional keys. • If the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys.

More Related