Security Mechanisms for a Cooperative Firewall 12/02/14 February 2014 Hammad Kabir Supervisor: Prof. Raimo Kantola Instructor: Jose Costa-Requena

Outline Research Background Research Objectives Conceptual Framework (Customer Edge Switching) Literature Review Circular Pool vulnerabilities CES-to-CES communication vulnerabilities Security Models Results and Discussion Conclusions and Future Work References 12/02/2014 2

Research Background NAT deployment at network edges introduced the reachability problem in the Internet. Various NAT traversal proposals: STUN, TURN and ICE [3] have been proposed, which either had the long connection setup time or keep-alive signaling that depletes the mobile battery. A solution proposed at COMNET department of Aalto University: Customer Edge Switching 3 12/02/2014

Research Problem While the CES architecture solves many of the current Internet issues i.e. reachability problem, IPv4 address space depletion [1] [2], the prototype only offers minimal security through policy based admission control to the communicating end points. Security has generally been considered out of scope. Research Scope To identify the security vulnerabilities present within the CES architecture. Present a security model that secures CES against the attacks launched on these vulnerabilities. Evaluate the security models based on a set of test cases (attacks), to demonstrate their effectiveness. Research Objectives 4 12/02/2014

Customer Edge Switching Customer Edge Traversal Protocol (CETP)

Private Realm Gateway (PRGW) Principle: -A component in CES to support backward compatibility with legacy networks -Outgoing connection is established in a similar manner to NAT -For an inbound connection, the domain in private network is reached through address received from CES, after performing name resolution for the destination domain.

Circular Pool Model When a DNS request is received from a legacy host, the PRGW makes use of circular pool functionality and returns an address from the pool of public IP addresses, towards the sender, in the DNS response. The address returned is marked in the ‘waiting’ state. After a data packet is received at this address, the address is returned to the circular pool for future connection establishments. Since the circular pool only assigns the addresses that are not in ‘waiting’ state to establish a new connection. If all of the circular pool addresses are reserved when a DNS query is received, the circular pool cannot serve the request and the request is dropped. This state of circular pool is called blocking state. This state is not permanent, and it does not affect ongoing connections in CES. An attacker can exploit this vulnerability in different ways, to launch DoS attacks on the circular pool. 7 12/02/2014

Denial of Service (DoS) in CPOOL 8 -An attacker sends DNS queries to different domains behind the CES through various DNS servers to reserve all the circular pool addresses. -Damage: CES reaches the blocking state, and it cannot serve new incoming connection requests. 12/02/2014

Connection Hijacking in CPOOL 9 -Legitimate host reserves an address from the circular pool and a state is created with ‘waiting’ status -Before the legitimate host could return, an attacker sending attack packets can take over the state and hijacks the connection -Results in DoS to the legitimate user. 12/02/2014

CETP connection establishment 10 -After DNS response, the outbound CES (oCES) encodes CETP packet according to the sender policy and forwards it towards the inbound CES (iCES) to negotiate the connection establishment. -The CETP transaction between the oCES and the iCES is uniquely identified with the (SST, DST) pair chosen by the oCES and the iCES, respectively. -The connection establishment succeeds after both end points can successfully fulfill each other requirements, in either 1 RTT or 2 RTT. 12/02/2014

CETP Attack-1 11 Vulnerability: -A legacy host with CETP attack module forwards spoofed CETP packets towards CES-B. Damage: -The attacker opens a connection in the iCES by sending a spoofed CETP packet. -For a bot-controlled legacy host, this can result in a DoS attack on the inbound CES. 12/02/2014

CETP Attack Vulnerability: -A non-spoofing legacy host can imitate as a legitimate CES, if the sender legitimacy is not determined Damage: -The attacker successfully establishes a connection with the victim behind CES-B 12/02/2014

CETP Attack Vulnerability: -The attack can affect all the communications for which the routing infrastructure is compromised. Damage: -A successful MITM attack can compromise the integrity of the messages exchanged. -A MITM attacker can either passively eavesdrop on a communication -It can masquerade as a legitimate source and steal the victim’s information. 12/02/2014

Principle of Security Mechanisms A light weight attack should consume minimal processing at an inbound CES. Heavy verification mechanisms on attack packets generated with minimal processing give the attacker an advantage, where the attacker can flood the CES with huge attack volumes and force the CES into a denial-of-service (DoS) state. The CES architecture must eliminate source address spoofing before admitting a packet for connection establishment. Heavy verification mechanisms executed, after eliminating spoofing, must guarantee the legitimacy of the CETP packet source. With spoofing eliminated, a failure in heavy verification mechanisms must enable the CES to attribute an attack to the packet source. The response to light weight received packets should be small, to prevent network traffic amplification. The detailed response can be sent after spoofing has been eliminated /02/2014

Inbound CES Security Model 15 Cookie mechanism -Protects against spoofing attacks -Protects against replay attacks Signature Verification -Protects against MITM attacks -Authenticates the sender Based on the certificate from a CA HSS verification -Authenticates the sender A connection succeeds only if -the sender is a non-spoofing source -And, the sender is authenticated as a legitimate CES -It fulfills all the policy requirements of the destination 12/02/2014

Outbound CES Security Model 16 A connection succeeds only if the inbound packet matches -(SST, DST=0) pair in the oCES -And, the sender is authenticated as a legitimate CES 12/02/2014

Consequence of security 17 12/02/2014

Performance Analysis 18 Before Security (msec)After Security (msec) CETP connection delay – 1RTT CETP connection delay – 2RTT /02/2014

Circular Pool security 19 Protects against DoS attacks -Upper limit on ‘waiting’ connection requests to a destination -Upper limit on ‘waiting’ connection requests from a source -Greylisting a DNS source generating attack traffic -A dedicated set of resource for whitelisted sources -Resources for whitelisted DNS sources, even under DDoS 12/02/2014

Circular Pool security 20 Protections against Connection Hijacking attempts -Drop a UDP packet received for claiming a ‘waiting’ connection state -A UDP packet must be accepted after prior secure signaling i.e. SIP, from the source -Since it is difficult to eliminate spoofing on a received UDP packet -Blacklisting an IP source generating the attack traffic -TCP-relay to eliminate spoofing on the inbound traffic [4]. -Bot-detection method, to spot a non-spoofing legacy host generating the attack traffic 12/02/2014

Circular Pool Evaluation 21 Before security, -all the offered traffic was carried in to the CPOOL and processed for connection establishment. After the security: -SYN segments accepted for connection establishment reduce drastically once the bot-controlled host is identified. -Test case with a legitimate host and an attacker generating SYN segments at average 20 connection/sec. -Reduction in the volume of the carried traffic, after the security. 12/02/2014

Conclusion and Future work 22 Conclusion: -Security vulnerabilities have been identified -Security models proposed to secure the CES architecture have been evaluated -The performance analysis indicates that CES is secured against network attacks without introducing significant delay Future Work: -Implementation of TCP-Relay method to eliminate spoofing on the received packets -Exploring DNS/TCP to avoid spoofing in the received DNS requests -Faster Control plane/Data plane using C/C++, to further reduce the connection setup delay -Secure signaling for UDP flows 12/02/2014

References [1] J. S. Llorente, "Private Realm Gateway," Master Thesis, Aalto University, School of Electrical Engineering, [2] M. Pahlevan, "Signalling and Policy Enforcement for Cooperative Firewalls," Aalto University, School of Electrical Engineering Thesis, [3] N. Beijar, Z. Yan, M. Pahlavan, and R. Kantola. (2012, Mar.) Customer Edge Traversal Protocol. [Online]. [4] W. Eddy, "TCP SYN Flooding Attacks and Common Mitigations," RFC 4987, /02/2014

24 12/02/2014