Security Mechanisms for a Cooperative Firewall

12/02/14

February 2014

Hammad KabirSupervisor: Prof. Raimo Kantola Instructor: Jose Costa-Requena

2

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

3

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

12/02/2014

4

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

12/02/2014

Customer Edge Switching

host

hosthost

host

host

host

Service Provider Network

CES-ACES-BDNS

Customer Network

Customer Network

Version Header Length Reserved SSTLen DSTLen

Source Session Tag - SST

Destination Session Tag - DST

C P

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

CodeOper Cmpt E E G G G TLV-Length

TLV-Value

CodeOper Cmpt E E G G G TLV-Length

TLV-Value Padding

Fixed header

Control TLVs

Customer Edge Traversal Protocol (CETP)

Private Realm Gateway (PRGW)

Host-A(hosta.cesa) CES-A/NAT

Host-E2(Public Host)

Data: E1-> AData: A->E1

Host-E1(Public Host)

DNS Q: hosta.cesa DNS R: hosta.cesa (R1)

Data: E1-> R1

Data: R1 -> E1

R1-R2

Host-B(hostb.cesa)

Private Network

(__,R1,A,w,2)

(E1,R1,A,a,30)

DNS

A: Private IP of Host-A R1-R2: Circular Pool addressesE1: Public IP of Host-E1 E2: Public IP of Host-E2hosta.cesa: Domain Name of Host- AConnection state: (IP source, Public IP in CES, internal host, status, timeout)

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.

7

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.

12/02/2014

8

Denial of Service (DoS) in CPOOL

- 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.

Host-B R1-R3 Host-E1Host-A Attacker-E2

(__,R1,A,w,2sec)[ATTACKER] DNS Q: A, hosta.cesa

DNS R: hosta.cesa @ R1

(__,R2,B,w,2sec)[ATTACKER] DNS Q: A, hostb.cesa

DNS R: hostb.cesa @ R2

(__,R3,C,w,2sec)[ATTACKER] DNS Q: A, hostc.cesa

DNS R: hostc.cesa @ R3

All slots allocated! DNS Q: A, hosta.cesa

hostb.cesahosta.cesa Public hosts

DNS ServersCES-A

12/02/2014

9

Connection Hijacking in CPOOL

Host-B R1-R2 Host-E1Host-A

(__,R1,A,w,2sec)DNS Q: A, hosta.cesa

DNS R: hosta.cesa @ R1

Data: (A:oPA) > (E2:oE2)[TO ATTACKER] TCP: (R1:oPA) > (E2:oE2)

[DELAYED] TCP: (E1:oE1) > (R1:oPA)Data: (E2:oE2) > (A:oPA)(P2,R1,A,a,3600sec)

R.NAT (A:oPA)->(R1:oPA)

drop

Does not match state

Does not match state

hostb.cesahosta.cesa Public hosts

[ATTACKER] TCP: (E2:oE2) > (R1:oPA)drop

[ATTACKER] TCP: (E2:oE2) > (R1:oPA)drop

[ATTACKER] TCP: (E2:oE2) > (R1:oPA)drop

[ATTACKER] TCP: (E2:oE2) > (R1:oPA)drop

NAT (R1:oPA)->(A:oPA)[ATTACKER] TCP: (E2:oE2) > (R1:oPA)

Attacker-E2CES-A DNS

- 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

10

CETP connection establishment

- 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.

Host-A

hosta.cesa

CES-A CES-B Host-B

hostb.cesb

SST=33000, DST=0; Query: Id, RLOC, PayloadInfo: Id, RLOC, Payload, CESID, destep

DST=33000, SST=35050 Response: Id, RLOC, Payload

DNS Q: hostb.cesb

DNS R: hostb.cesb (PA-B)

DNS

DNS R: CES_IDB, RLOCB

DNS Q: hostb.cesb

DNS R: CES_IDB, RLOCB

oCES iCES

12/02/2014

11

CETP Attack-1

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.

Host with CETP Attack software

CES-A CES-B Host-B

hostb.cesb

DST=x, SST=y Response: Id, RLOC, Payload

SST=x, DST=0; Query: Id, RLOC, PayloadInfo: Id, RLOC, Payload, CESID=’cesa’, destep

Packet dropped for not matching

state

12/02/2014

12

CETP Attack -2

CES-A CES-B Host-B

DST=x, SST=y Response: Id, RLOC, Payload

SST=x, DST=0; Query: Id, RLOC, PayloadInfo: Id, RLOC, Payload, CESID=’cesa’, destep

Host with CETP Attack software

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

13

CETP Attack -3

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.

MITM-CES

CES-B

SST=x, DST=0; Query: Id, RLOC, Payload

Info: Id=’hosta1’, RLOC, CESID, destep=’hostb’SST=x, DST=0; Q

uery: Id, RLOC, Payload

Info: Id=’ho

sta2’, R

LOC, CESID, destep=’ho

stb’

DST=x, SST=0;

Info: Id, RLOC, Payload

DST=x, SST=0;

Info: Id, RLOC, Payload

CES-A Host-B

Host-A1

Host-A2

12/02/2014

14

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.

12/02/2014

15

Inbound CES Security Model

Compulsory

Only If required by the policy

Cookie-TLV present

CETP Full Query packet

no

Is cookie TLV valid

All required TLVs presentCETP packet is dropped

If Signature is correct

HSS verification success

yes

yes

no

no

yes

CETP connection success

yes

yes

no

no

Respond with cookie-TLV

CETP received over “Legacy” interface

Multiple Interfaces

Incoming CETP packet

yes

no

Compulsory, if spoofing is possible

no yes

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

16

Outbound CES Security Model

Matching (SST, DST=0)

yes

no

Incoming CETP packet

If Signature is correct

yes

HSS verification success

yes

no

no

CETP packet is dropped

CETP connection established

Compulsory

If required by policy

Contains ‘Query’ TLVs

Send CETP 2RTT packet

no

yes

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

17

Consequence of security

12/02/2014

18

Performance Analysis

  Before Security (msec) After Security (msec)CETP connection delay – 1RTT 197.724 -CETP connection delay – 2RTT 360.371 398.150

12/02/2014

19

Circular Pool security

System Load > max

If DNS is black listed

If source_load > max_dns_load

If domain_load > max_load

systemLoad < min

min<systemLoad<med

Only allow whitelisted med < systemLoad < max

no

no

no

no

DNS Response denied

yes

yes

yes

yes

DNS response issued

Else

Incoming DNS request

Is Whitelisted

Allow DNS with ‘Rw’ probability

Allow DNS with ‘Rg’ probability

GreylistedWhitelisted

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

20

Circular Pool security

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

21

Circular Pool Evaluation

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

22

Conclusion and Future work

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

23

References

[1] J. S. Llorente, "Private Realm Gateway," Master Thesis, Aalto University, School of Electrical Engineering, 2012.

[2] M. Pahlevan, "Signalling and Policy Enforcement for Cooperative Firewalls," Aalto University, School of Electrical Engineering Thesis, 2013.

[3] N. Beijar, Z. Yan, M. Pahlavan, and R. Kantola. (2012, Mar.) Customer Edge Traversal Protocol. [Online]. http://www.re2ee.org/

[4] W. Eddy, "TCP SYN Flooding Attacks and Common Mitigations," RFC 4987, 2007.

12/02/2014

24

Questions?

Thank You

12/02/2014