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
20
Embed
March 2009IETF 74 - NSIS1 Implementation of Permission-Based Sending (PBS) NSLP: Network Traffic Authorization draft-hong-nsis-pbs-nslp-02 Se Gi Hong*,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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)
• 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)
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