程序代写 COMP4337/9337 WK04: Network Layer Security: IPsec

Securing Fixed and Wireless Networks, COMP4337/9337 WK04: Network Layer Security: IPsec
Professor . Jha
School of Computer Science and Engineering, UNSW
WK04-01-Network layer Sec 1

Copyright By PowCoder代写 加微信 powcoder

Why Network Layer Security?
v Higher-layer security mechanisms do not necessarily protect an organisation’s internal network links from malicious traffic.
v If and when malicious traffic is detected at the end-hosts, it is too late,
§ bandwidth has already been consumed.
v Higher-layer security mechanisms (e.g., TLS) do
not conceal IP headers.
• IP addresses of the communicating end-hosts visible to eavesdroppers.
v Possible to create Secure VPN (more soon) 2

What is network-layer confidentiality ?
§ between two network entities:
§ sending entity encrypts datagram payload, payload
§ TCP or UDP segment, ICMP message, OSPF message ….
§ Implemented below Transport layer (TCP/UDP)
§ Even when implemented in end-systems, doesn’t affect higher layers
§ all data sent from one entity to other would be hidden:
§ web pages, e-mail, P2P file transfers, TCP SYN packets § “blanket coverage”

Virtual Private Networks (VPNs)
motivation:
o institutions often want private networks for security.
o costly: separate routers, links, DNS infrastructure.
o VPN: institution’s inter-office traffic is sent over
public Internet instead
o encrypted before entering public Internet o logically separate from other traffic

IPsec services
v Data integrity
v Origin authentication
v Replay attack prevention v Confidentiality
v Two different offerings (AH and ESP) discussed later

IPsec Use case
TCP/UDP Header
Data Payload
Public Intern et
IPSec compliant Gateway Router
Enterprise Network
IPSec Header
TCP/UDP Header
Data Payload
IPSec Header
TCP/UDP Header
Data Payload
IPSec Compliant Host
Home Network
Networ 28 k

Tunnel and Transport Modes
o Transport Mode: protects IP Payload received from layers above (Higher layer TCP, UDP, ICMP..)
o There are many detailed nuances with AH/ESP support, encapsulation etc.
o Tunnel Mode: All of IP including header etc is encapsulated, new IP header is added by Firewall/Routers.
o End hosts behind firewall don’t have to worry about IPSec
o We will focus on Tunnel Mode here as it is more widely used

IPsec – tunneling mode
IPsec IPsec
v edge routers IPsec- aware
v IP address of Routers/Gateways used, destination address encrypted
v hosts IPsec-aware
v Also possible that one host is IPSec aware and other behind firewall

Advantages of tunnel mode (Edge)
v Simple key distribution: fewer keys needed as gateways do encryption/decryption
v Traffic analysis difficult as ultimate destination IP header concealed
v Less processing burden on end-hosts
v OP TION AL RE AD: C. Kiraly , S. T eofili, G. Bianchi, R. Lo Cigno, M. Nardelli, and E. Delzeri, “Traffic flow confidentiality in IPsec: Protocol and implementation,” in The Future of Identity in the Information Society, S. Fischer-Hübner, P. Duquenoy, A. Zuccato, and L. Martucci, Eds. Boston, MA:
Springer US,2008, pp. 311–324.

IPsec Formats
o IPsec supports a set of formats to implement security
o The Encapsulation Security Payload (ESP) format supports confidentiality using encrypted IP packets, data integrity using hash functions, and source authentication
o If an application does not require confidentiality, it may simply use the Authentication Header (AH) format, which supports data integrity and source authentication
o The IETF RFC2410 defines the NULL Encryption algorithm with ESP to achieve the same outcome
Networ 30 k

Four combinations are possible!
Transport mode with AH
Transport mode with ESP
Tunnel mode with AH
Tunnel mode with ESP
most common and most important

Protocol Operations for ESP
Transport: Original IP Hdr
Application
orig IP hdr
orig IP hdr
(a) Transport mode
ESP ESP trlr auth
Application
orig IP hdr
orig IP hdr
ESP ESP trlr auth
ESP ESP trlr auth
orig IP hdr
new IP hdr
(b) Tunnel mode
Figure 9.9 Protocol Operation for ESP

Security associations (SAs)
v before sending data, “security association (SA)” established from sending to receiving entity
§ SAs are simplex: for only one direction
v ending, receiving entitles maintain state information
§ recall: TCP endpoints also maintain state info
§ IP is connectionless; IPsec is connection-oriented!
v Combination of Security Associations has many advanced features : Read stallings Chapter9 (not examinable)

Example SA from R1 to R2
headquarters
R1 172.16.1/24
branch office
200.168.1.100
193.68.2.23
R1 stores for SA:
v 32-bit SA identifier: Security Parameter Index (SPI)
v origin SA interface (200.168.1.100)
v destination SA interface (193.68.2.23)
v type of encryption used (e.g., 3DES with CBC)
v encryption key
v type of integrity check used (e.g., HMAC with MD5) v authentication key
security association
172.16.2/24

Security Association Database (SAD)
v endpoint holds SA state in security association database (SAD), where it can locate them during processing.
v when sending IPsec datagram, R1 accesses SAD to determine how to process datagram.
v when IPsec datagram arrives to R2, R2 examines SPI in IPsec datagram, indexes SAD with SPI, and processes datagram accordingly.

SAD Parameters
v Normally defined by the several parameters in a SAD entry:
§ Security parameter index § Sequence number counter § Anti-replay window
§ AH information
§ ESP information
§ Lifetime of this security association § IPsec protocol mode
§ Path MTU

IPsec datagram
focus for now on tunnel mode with ESP
“enchilada” authenticated encrypted
new IP header
original IP hdr
Original IP datagram payload
pad length
next header
Note; Original IP address/hdr encrypted, destination Router/GW

headquarters
R1 172.16.1/24
branch office
What happens?
200.168.1.100
193.68.2.23
security association
172.16.2/24
“enchilada” authenticated encrypted
new IP header
original IP hdr
Original IP datagram payload
pad length
next header

R1: convert original datagram to IPsec datagram
v appends to back of original datagram (which includes original header fields!) an “ESP trailer” field.
v encrypts result using algorithm & key specified by SA.
v appends to front of this encrypted quantity the “ESP header,
creating “enchilada”.
v creates authentication MAC over the whole enchilada, using
algorithm and key specified in SA;
v appends MAC to back of enchilada, forming payload;
v creates brand new IP header, with all the classic IPv4 header fields, which it appends before payload.

Inside the enchilada:
“enchilada” authenticated encrypted
new IP header
original IP hdr
Original IP datagram payload
pad length
next header
v ESP trailer: Padding for block ciphers
v ESP header:
§ SPI, so receiving entity knows what to do § Sequence number, to thwart replay attacks
v MAC in ESP auth field is created with shared secret key (HMAC) § Note: ESP header is included in MAC calculation

IPsec sequence numbers
v for new SA, sender initializes seq. # to 0 § each time datagram is sent on SA:
§ sender increments seq # counter
§ places value in seq # field
§ prevent attacker from sniffing and replaying a packet
§ receipt of duplicate, authenticated IP packets may disrupt service
• destination checks for duplicates
• doesn’t keep track of all received packets; instead uses a window (remember from 3331)

Security Policy Database (SPD)
v policy: For a given datagram, sending entity needs to know if it should use IPsec
v needs also to know which SA to use
§ may use: source and destination IP address; protocol
v info in SPD indicates “what” to do with arriving datagram
v info in SAD indicates “how” to do it

Src: Stallings. Table9.2
Host SPD Example

Notes on Table 9.2
Table 9.2 provides an example of an SPD on a host system (as opposed to a network system such as a firewall or router). This table reflects the following configuration:
A local network configuration consists of two networks. The
basic corporate network configuration has the IP network number 1.2.3.0/24. The local configuration also includes a secure LAN, often known as a DMZ, that is identified as 1.2.4.0/24. The DMZ is protected from both the outside world and the rest of the corporate LAN by firewalls. The host in this example has the IP address 1.2.3.10, and it is authorized to connect to the server 1.2.4.10 in the DMZ.
The entries in the SPD should be self-explanatory. For example, UDP port 500 is the designated port for IKE. Any traffic from the local host to a remote host for purposes of an IKE exchange bypasses the IPsec processing.

IPsec Outbound Processing
No match found
Determine policy
Outbound IP packet (e.g., from TCP or UDP)
Search security policy database
Match found
Discard packet
Match found
No match Search found
security association database
Process (AH/ESP)
Internet key exchange
Forward packet via IP
Figure 9.3 Processing Model for Outbound Packets

IPsec Inbound Processing
Deliver packet
to higher layer (e.g. TCP, UDP)
Process (AH/ESP)
Match BYPASS Not No match found
Search BYPASS found Search
security policy database
Packet type
Inbound IP packet (from Internet)
security association database
Discard packet
Figure 9.4 Processing Model for Inbound Packets

IKEv2: Internet Key Exchange
v previous examples: manual establishment of IPsec SAs in IPsec endpoints:
Example SA
SPI: 12345
Source IP: 200.168.1.100
Dest IP: 193.68.2.23
Protocol: ESP
Encryption algorithm: 3DES-cbc HMAC algorithm: MD5 Encryption key: 0x7aeaca… HMAC key:0xc0291f…
v manual keying is impractical for VPN with 100s of endpoints
v instead use IPsec IKEv2 (Internet Key Exchange) RFC7296 27

IPsec summary
v IKE message exchange for algorithms, secret keys, SPI numbers
v either AH or ESP protocol (or both)
§ AH provides integrity, source authentication
§ ESP protocol (with AH) additionally provides encryption
v IPsec peers can be two end systems, two routers/firewalls, or a router/firewall and an end system

NAT and IPv6
o NAT devices providing IP Masquerading
o IPv6 proliferation
o 128 bit addresses increases the searchable address space
o IPv6 L3 addresses are derived directly from L2 addresses without the need to do ARP
o Allows cryptographically generated addresses (CGA) binding addresses to a public signature key
o IPsec initially mandated but now recommended

Routing Protocol Security
§ Routing protocols security
• Important aspect to ensure routers do not act on malicious
routing exchange control messages
§ Interior Gateway protocols (IGP) that work within the Autonomous Systems (AS) support no security by default
• Can be configured to support plain text-based or MD5- based authentication
• Routers exchange message digest and key-id to indicate which key to use from a previously shared list of passwords

Border Gateway Protocol Security
o Border Gateway Protocol (BGP) is the de-facto exterior gateway protocol that advertises the reachability information within and across ASs
o BGP also lacks integrity and authentication mechanisms by default and hence subject to attacks such as
o BGP route hijacking attack
o Divert all traffic to flow through your AS or another AS
o BGP DoS attack
o Attacking the BGP border router
o Utilises PKI to verify the signatures of the BGP peers
o Signature verification comes at a cost
o Can use IPsec for point to point security for exchanging update messages

v Section 8.7, Computer Networking A top-Down Approach: and , Chapter 8, (foils provided by Authors): Section 9.2 and 9.5 Network Security Essentials: Stallings: Cybok Network Security KA – Section 5
§ Internet Key Exchange is a Optional reading. Not
covered in lecture as ideas are similar to SSL.
§ Additional foils on AH and Tunnel modes are provided for optional reading. AH mode is supported for backward compatibility only. Many complicated features not covered.

Authentication Header (AH)
v AH provides authentication but not privacy
v a special hashing algorithm and a specific key known only to the source and the destination used to generate authentication header
v Parts of the datagram used for the calculation, and the placement of the header, depends on the mode (tunnel or transport) and the version of IP (IPv4 or IPv6)
v Details at https://tools.ietf.org/html/rfc4302 33

Figure src: http://www.unixwiz.net/techtips/iguide-ipsec.html

Figure src: http://www.unixwiz.net/techtips/iguide-ipsec.html
35 Network Security

Tunnel Mode and Transport Mode
Functionality (stallings Table 9.1) No need to memorise
Transport Mode SA
Tunnel Mode SA
Authenticates IP payload and selected portions of IP header and IPv6 extension headers.
Authenticates entire inner IP packet (inner header plus IP payload) plus selected portions of outer IP header and outer IPv6 extension
Encrypts IP payload and any IPv6 extension headers following the ESP header.
Encrypts entire inner IP packet.
ESP with Authentication
Encrypts IP payload and any IPv6 extension headers
following the ESP header. Authenticates IP payload but
not IP header.
Encrypts entire inner IP packet. Authenticates inner IP packet.

IKE Features
v Each entity has a certificate (incl. Public Key)
v Similarity with SSL handshake
§ Exchange certificates
§ Negotiate authentication and encryption algorithms
§ Securely exchange Key Material for creating session keys in the IPSec SAs

IKE phases
v IKE has two phases
§ phase 1: establish bi-directional IKE SA different from
– Authenticated and encrypted tunnel between two end points for IKE messages
– Est. a Master Key for use in IPSec SA in phase 2
– Another exchange for identity by signing their messages (Identities now protected by IKE SA, can’t be sniffed)
» Also negotiated encryption/auth algorithms
§ phase 2: two sides negotiate IPSec of SA in each direction
• No PKI in second phase, hence large number of SA negotiation possible for scalability.

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com