march 2009ietf 74 - nsis1 implementation of permission-based sending (pbs) nslp: network traffic...
TRANSCRIPT
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
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