March 2009IETF 74 - NSIS1 Implementation of Permission-Based Sending (PBS) NSLP: Network Traffic...

20
March 2009 IETF 74 - NSIS 1 Implementation of Permission- Based Sending (PBS) NSLP: Network Traffic Authorization draft-hong-nsis-pbs-nslp-02 Se Gi Hong*, Henning Schulzrinne*, Swen Weiland** *Columbia University, ** University of Goettingen Presented by Henning Schulzrinne

Transcript of March 2009IETF 74 - NSIS1 Implementation of Permission-Based Sending (PBS) NSLP: Network Traffic...

March 2009 IETF 74 - NSIS 1

Implementation of Permission-Based Sending (PBS) NSLP: Network Traffic

Authorizationdraft-hong-nsis-pbs-nslp-02

Se Gi Hong*, Henning Schulzrinne*, Swen Weiland** *Columbia University, ** University of Goettingen

Presented by Henning Schulzrinne

March 2009 IETF 74 - NSIS 2

Overview of PBS NSLP

• Objective – Preventing Denial-of-Service (DoS) attacks and other forms of unauthorized

traffic.

• Authorization– Permission is granted by the intended receiver.– Permission represents the authority to send data.

• Deny-by-default– In closed network (all end users have PBS NSLP functionalities)

• The unauthorized traffic without permission are dropped at the first router by default.

– In the open Internet (some end users do not have PBS NSLP functionalities)• The traffic from the end users who do not have PBS NSLP functionalities are

rate-limited by default.

PBS NSLP Signaling Message

3

• Two-way handshake– Query message

• Sent by a sender to request permission.• Carry the flow identification (5-tuple) of the data packet.• Flow identification: descriptor of flow

– Permission message• Sent by a receiver.• Set up (grant), remove (revoke) and modify permission state.• Carry permission, time limit, flow identification• Trigger reaction mechanism against the attacks.

• Soft-state – Robustness of the system– Periodic refreshment of the permission state

• Peer-to-Peer delivery– The signaling messages are delivered in peer-to-peer fashion between the

nodes that have PBS NSLP functionality

March 2009 IETF 74 - NSIS

March 2009 IETF 74 - NSIS 4

PBS NSLP architecture

• On-path signaling (PBS NSLP processing/ GIST processing)– Install and maintain permission state.– Monitor attacks.– Trigger reaction mechanism against the attacks.– Distribute public key (X.509 certificate) and session key

• Authorization– Decide the grants of permission (amount of data volume) for a flow– Detect and identify the attack.– Decide the reaction mechanism against the attacks.

• IPsec AH• Changing data path

• Traffic management– Handle all incoming message.– IP packet filter drops the unauthorized packets.– Monitor data flow (check the total volume of the data flow).

Implementation structure

• PBS NSLP / GIST– Finite state machine

• FSM controls the state of each node.

– Message creation and parsing• Signaling messages are created and parsed at each node that has a PBS NSLP

functionality.

– Public key distribution• OpenSSL: X.509 certificate

– Signaling message authentication • OpenSSL: The public key cryptography for the message authentication

– GIST API• IPC (Unix socket): Communication between GIST and PBS NSLP

• Selection of UDP/TCP/TLS: channel reliability and security

March 2009 IETF 74 - NSIS 5

Implementation structure

• Authorization– State table

• Hashtable: permission state, IPsec state

• Traffic management– Userspace IPsec module: A modular IPsec stack which relies on user space

• netfilter queue module: get the packets (if a rule matches) to user space

• OpenSSL: public key cryptography for IPsec authentication field

– Netfilter/IPtables• libiptc: interface filter tables in the kernel space

• iptables: filter IP packets

– Linux kernel routing table• route: set up the data path (Linux kernel routing table is used).

March 2009 IETF 74 - NSIS 6

PBS implementation architecture

7

User level

Kernel level

On-path signaling

PBS NSLPProcessing(OpenSSL)

NTLP (GIST)Processing

Linux kernel routing table

(route)

Netfilter IP packet filtering(iptables)

Control and configurationData flowSignal flow

State table: permission state, IPsec state(Hashtable)

Userspace IPsec module(netfilter queue module, libiptc, OpenSSL)

Networkdevice

Networkdevice

Authorization

Traffic management

March 2009 7IETF 74 - NSIS

CPU usage

• AMD Opteron Processor 148• 2GB RAM• Single processor (2.2 GHz CPU)• Linux with kernel version 2.6.15

<Router> Kernel IP routing tableDestination Gateway Genmask Flags Iface192.168.20.0 * 255.255.255.0 U eth0192.168.21.0 * 255.255.255.0 U eth1

<Sender> Kernel IP routing tableDestination Gateway Genmask Flags Iface192.168.21.0 192.168.20.3 255.255.255.0 UG eth0

<Receiver> Kernel IP routing tableDestination Gateway Genmask Flags Iface192.168.20.0 192.168.21.3 255.255.255.0 UG eth0

Dest: 192.168.21.4

Dest: 192.168.21.5

Router Eth0

192.168.20.3

Router Eth1

192.168.21.3

Sender 1192.168.20.1

Sender 2192.168.20.2

Receiver 2192.168.21.5

Receiver 1192.168.21.4

CPU usage measurement

point

Testbed setup and network configuration

CPU usage of PBS NSLP

0

10

20

3040

50

60

70

400 500 600 700 800

Rate: # of (Q, P) messages/sec

CPU

usag

e (%

)

Q:UDP, P:UDP

Q:TCP, P:TCP

Q:UDP, P:TLS

Q:TCP, P:TLS

Q:TLS, P:TLS

CPU usage of GIST

0

10

20

30

40

50

400 500 600 700 800

Rate: # of (Q, P) messages/sec

CP

U u

sage

(%)

Q:UDP, P:UDP

Q:TCP, P:TCP

Q:UDP, P:TLS

Q:TCP, P:TLS

Q:TLS, P:TLS

0102030405060708090

400 500 600 700 800

CPU

usag

e (%

)

Rate: # of (Q, P) messages/sec

CPU usage of PBS (GIST and PBS NSLP)

Q:UDP, P:UDP

Q:TCP, P:TCP

Q:UDP, P:TLS

Q:TCP, P:TLS

Q:TLS, P:TLS

• Number of concurrent sessions that can be handled 600 (Q, P) messages /sec 36,000 concurrent flows with 60 sec refresh period with fair queue

Backup slides

March 2009 IETF 74 - NSIS 11

PBS architecture

12

Authorization

Traffic Management

Control and configuration

Data flow

Signal flow

PBS NSLPProcessing

NTLP (GIST)Processing

March 2009 IETF 74 - NSIS

On-path signaling

State - 1: Idle, 2: wait for P, 3: Permission state, 4: compare SV and AV

Send Q

Send QRecv P & P(AV!=N)|| apply IPsec for data

Send DataSV< AV

T.O. || change route& send Q

Recv P & P(AV=0)

SV > AV || remove permission state

TTL=0 OR recv P(AV = 0) ||remove permission state

Recv P (new security algorithm) ||Change the security algorithm for IPsec

Event || ActionQ: Query message, P: Permission message, T.O.: Time outAV: The number of bytes that the receiver allowsSV: The number of bytes that the sender has been sent

1

2

3

4

FSM: Sender

March 2009 13IETF 74 - NSIS

Recv Q

Grant || setup permission state & install SA& send P(AV!=0, shared key)

TTL =0 ORNo refresh || remove state and SA & send P(AV=0)

Recv Q (SV)

SV = RV ||Send P

Increase security|| send P(new security algorithm)

RV < AVRV > AV || remove state and SA& send P(AV=0)

IPsec verification failed || Drop

Recv Data

Decline ||Send P(AV=0)

IPsec verification success || calculate RV

SV != RV

Revoke permission||Remove state and SA& Send P(AV=0)

Event || ActionRV: The number of bytes that the receiver has been receivedState - 1: IDLE, 2: Permission decision, 3: Permission state, 4: IPsec verification, 5: compare RV and AV, 6: compare RV and SV, 7: Policy decision

1

2

3

4

5

6

7

FSM: Receiver

March 2009 14IETF 74 - NSIS

Recv Q || forward Q

IPsec verification success || calculate RV

Recv P (AV!=0) || setup permission state and SA

RV < AV || forward Data

IPsec verification failed || Drop Data

Recv Data

Recv P(AV=0)

Recv Q

RV > AV || Drop Data

TTL=0 OR recv P (AV = 0)OR No refresh ||remove state and SA

Recv P (new security algorithm) || Change the security algorithm for IPsec

Event || ActionRV: The number of bytes that the receiver has been received

State - 1: Idle, 2: Wait for P, 3: Permission state, 4: IPsec verification, 5: compare RV and AV

1

2

3

4

5

FSM: Router

March 2009 15IETF 74 - NSIS

16

Query (10MB, FID)

Sender R1 R2 Receiver

T

Permission (10MB, TTL, FID)

Permission Permission Permission

Query Query Query

Query (10MB, FID) Query (10MB, FID)

Permission (10MB, TTL, FID) Permission (10MB, TTL, FID)

Install permission state

Install permission state

PBS NSLP Signaling Message

March 2009 16IETF 74 - NSIS

Basic operation of prevention

17

Q (FID,PKey,Auth)

Sender R1 R2 Receiver

Data flow / IPsec

Attack flow

IPsec verification failed

P (10MB, FID, Pkey, Skey, Auth)

IPsec verification success

Data flow / IPsec Data flow / IPsec

Q ( FID,Pkey,Auth) Q (FID,Pkey,Auth)

P (10MB, FID,Pkey, Skey, Auth)P (10MB, FID, Pkey, Skey, Auth)

Auth verification

success

Auth verification success

March 2009 17IETF 74 - NSIS

PBS Detection Algorithm (PDA)

18

• Basic operation of PDA

Sender R1 R3 ReceiverSpoof sender’s address,and has the shared key

T

Data (size=1MB)/ IPsec (symm key)

Q

P (10MB)

Q (1MB)P (public key crypto)

Q (1MB) Q (1MB) Q (1MB)

Detect attack(1MB Vs 3MB)

Attack (size=2MB)IPsec (symm key)

Attack (size=2MB)IPsec (symm key)

P (public key crypto) P (public key crypto) P (public key crypto)

P (10MB) P (10MB) P (10MB)

Q Q Q

Total 3MB

Data (size=1MB)/ IPsec (symm key)

Data (size=1MB)/ IPsec (symm key)

Data (size=1MB)/ IPsec (symm key)

Data (size=1MB)/ IPsec (Public key)

Data (size=1MB)/ IPsec (Public key)

Data (size=1MB)/ IPsec (Public key)

Data (size=1MB)/ IPsec (Public key)

Total 1MB

March 2009 IETF 74 - NSIS

PBS Detection Algorithm (PDA)

19

• Detection of black hole attack

T.O.

R1 R3 ReceiverSender (Attacker, Drop attack)

Query Query

Change data flow path

March 2009 IETF 74 - NSIS

PBS Detection Algorithm (PDA)

20

• Detection of dropping data packets

ReceiverR3R1Sender

Data (size=1MB)

(Attacker, Drop attack)

T

Q (1MB)

P (change path)

Q

Q (1MB) Q (1MB) Q (1MB)

P (10MB)

Data (size=1MB)

Detect attack

(1MB Vs 0MB)

P (change path) P (change path) P (change path)

P (10MB) P (10MB) P (10MB)

Q Q Q

March 2009 IETF 74 - NSIS