Loading in 5 sec....

Collaborative Enforcement of Firewall Policies in Virtual Private NetworksPowerPoint Presentation

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

Download Presentation

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

Loading in 2 Seconds...

- 134 Views
- Uploaded on
- Presentation posted in: General

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

Fei Chen

Dept. of Computer Science and Engineering

Michigan State University

Joint work with Prof. Alex X. Liu

Virtual Private Network (VPN)

MSU

IBM

Malicious

websites

1.1.0.0/16

2.2.0.0/16

A secure hole

VPN Server

Firewall

IBM

Representative

Confidential

Database

1.1.0.10

2.2.0.1

2.2.0.25

2.2.0.2

Header

Header

Encrypted

Payload

Payload

- The problem: MSU firewall cannot know what traffic is inside VPN
- Viruses or worms can enterinto MSU’s networks

- Two straight forward ways
- Goal: MSU and IBM collaboratively enforce the firewall policy without MSU knowing IBM packet and IBM knowing MSU firewall

MSU

Firewall

IBM

VPN Server

×

×

Firewall

packet

- Secure Function Evaluation (SFE) (Yao, 1982)
- Garbled circuits (Yao, 1986)
- Computation cost is O(2b)

- Garbled circuits (Yao, 1986)
- Oblivious Attribute Certificates (OACerts) (Li et al., 2005)
- Trusted third party
- Expensive PKI operation

- Cross-Domain Cooperative Firewall (CDCF) (Cheng et al., 2007)
- CDCF is insecure
- MSU knows which rule matches which packet

- CDCF is inefficient
- It uses commutativeencryptionfunctions

- CDCF is insecure

MSU

Firewall

IBM

VPN Server

- Key idea I: We propose Xhash protocol for oblivious comparison
- Three orders faster than the commutative encryption

- Key idea II: We uses Firewall Decision Diagrams (FDD)
- For security purpose, FDD can help to prevent MSU from knowing which rule matches which packet
- For efficiency purpose, processing packets using FDD is much more efficient than using linear search

f1(Firewall)

Bootstrapping Protocol

f2(f1(Firewall))

f2(packet)

1. Compute f1(f2(packet))

Filtering Protocol

decision

2. Search f1(f2(packet))inf2(f1(Firewall))

c1

c2

IBM

MSU

- Oblivious comparison problem
- Xhash protocol

c1=c2

?

If c1≠c2, no party should learn the value of the other party

c1⊕K1

IBM(K2)

MSU(K1)

h(c1⊕K1⊕K2)

c2⊕K2

Compute h(c2⊕K2⊕K1)

Compare with h(c1⊕K1⊕K2)

c

IBM

[a, b]

MSU

- Membership query problem
- Solutions using Xhash protocol

Does c in the range [a,b]?

No party should learn the value of the other party

[3, 7]

5

Prefix format

Prefix family

{011, 1**}

PF(5)={101, 10*,1**,***}

1**

1**

MSU

IBM

[3, 7]

5

Prefix format

Prefix family

{011, 1**}

PF(5)={101, 10*,1**,***}

Prefix numericalization

{01100, 10010}

{01100⊕K1, 10010⊕K1}

Prefix numericalization

{h(01100⊕K1⊕K2),

h(10010⊕K1⊕K2)}

Store

{h(01100⊕K1⊕K2),h(10010⊕K1⊕K2)}

{10111, 10010,10001,00011}

10111⊕K2, …,00011⊕K2

Compute

{h(10111⊕K2⊕K1), …, h(00011⊕K2⊕K1)}

- Why to prevent MSU from knowing which rule matches which packet?

f1(Firewall)

Bootstrapping Protocol

f2(f1(Firewall))

f2(packet)

1. Compute f1(f2(packet))

2. Search f1(f2(packet))inf2(f1(Firewall))

Filtering Protocol

decision

IBM cannot figure out

Firewall by using f1(Firewall)

MSU may figure out packet by knowing the original rule that matches packet

f2(packet)

match

change by MSU

F1(packet) is in [1, 2]

F2(packet) is not in [5, 6]

……

- Convert overlapping rules to non-overlapping rules

FDD

construction

Prefix

generation

Overlapping rules

Prefix

numericalization

Non-Overlapping rules

Rule

generation

XOR by MSU

(0100010⊕K1, 0000010⊕K1) → a

(0100010⊕K1, 0100011⊕K1) → a

(1000010⊕K1, 0000010⊕K1) → a

(1000010⊕K1, 0100011⊕K1) → a

(0100010⊕K1, 0110011⊕K1) → d

……

The order of non-overlapping rules does not affect their function

(0100010⊕K1, 0000010⊕K1) → a

(0100010⊕K1, 0100011⊕K1) → a

(1000010⊕K1, 0000010⊕K1) → a

(1000010⊕K1, 0100011⊕K1) → a

(0100010⊕K1, 0110011⊕K1) → d

……

(h(0100010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → d

……

Send to IBM

IBM shuffles rules

(h(0100010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → d

(h(1000010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

……

- MSU statistically analyze
- Frequency of values
- Frequency of decisions

Send back to MSU

IBM add

dummy rules

(h(0100010⊕K1⊕K2), h(dummy1⊕K2)) → d

0101 0011

010* 001*

01** 00**

0*** 0***

**** ****

0101100 0011100

0100011 0010011

0100010 0000010

0000001 0000001

0000000 0000000

A Packet:

Prefix family

generation

Prefix

Numericalizaiton

(0101, 0011)

XOR by IBM

h(0101100⊕K2⊕K1) h(0011100⊕K2⊕K1)

h(0100011⊕K2⊕K1) h(0010011⊕K2⊕K1)

h(0100010⊕K2⊕K1) h(0000010⊕K2⊕K1)

h(0000001⊕K2⊕K1) h(0000001⊕K2⊕K1)

h(0000000⊕K2⊕K1) h(0000000⊕K2⊕K1)

0101100⊕K20011100⊕K2

0100011⊕K2 0010011⊕K2

0100010⊕K2 0000010⊕K2

0000001⊕K2 0000001⊕K2

0000000⊕K2 0000000⊕K2

XOR and HMAC

By MSU

- To improve search efficiency, MSU can convert non-overlapping rules to a FDD

(h(0100010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → d

(h(0100010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → d

(h(1000010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → d

(h(0100010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → a

(h(dummy5⊕K1⊕K2), h(dummy7⊕K1⊕K2)) → d

……

- For real-life firewalls in bootstrapping protocol
- Bootstrapping cost of VGuard is lower than that of CDCF for most firewalls

MSU

IBM

- For real-life firewalls in filtering protocol
- VGuard is 552 times faster than CDCF on the MSU side
- VGuard is5035 times faster than CDCF on the IBM side

(Log scale)

(Log scale)

MSU

IBM

- Two intuitive reasons for the better performance
- Xhash is three orders faster than commutative encryption
- FDD is much efficient to search the decision of a given packet

- For synthetic firewall policies in filtering protocol
- VGuard is 252 times faster than CDCF on the MSU side
- VGuard is5529 times faster than CDCF on the IBM side

(Log scale)

(Log scale)

MSU

IBM

- VGuard is secure
- VGuard prevents MSU from identifying which rule matches the given packet

- VGuard is efficient
- Xhash is three orders faster than the commutative encryption
- VGuard uses firewall decision diagrams for processing packets

- Xhash is very efficient for oblivious comparison and can be used for other applications

Thank you!