1 / 20

Se Gi Hong*, Henning Schulzrinne*, Swen Weiland**

This draft outlines the implementation of Permission-Based Sending (PBS) NSLP to address DoS attacks and unauthorized traffic in network communication. It covers signaling messages, architecture, implementation structure, authorization processes, and CPU usage analysis.

kenat
Download Presentation

Se Gi Hong*, Henning Schulzrinne*, Swen Weiland**

An Image/Link below is provided (as is) to download presentation 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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. IETF 74 - NSIS

  3. PBS NSLP Signaling Message • 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 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). IETF 74 - NSIS

  5. 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 IETF 74 - NSIS

  6. 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). IETF 74 - NSIS

  7. PBS implementation architecture On-path signaling Authorization PBS NSLP Processing (OpenSSL) State table: permission state, IPsec state (Hashtable) Traffic management NTLP (GIST) Processing Userspace IPsec module (netfilter queue module, libiptc, OpenSSL) Network device Netfilter IP packet filtering (iptables) Linux kernel routing table (route) Network device User level Kernel level Signal flow Data flow Control and configuration IETF 74 - NSIS 7

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

  9. Testbed setup and network configuration Receiver 2 192.168.21.5 Router Eth0 192.168.20.3 Router Eth1 192.168.21.3 Sender 1 192.168.20.1 Dest: 192.168.21.4 Dest: 192.168.21.5 Receiver 1 192.168.21.4 CPU usage measurement point Sender 2 192.168.20.2 <Sender> Kernel IP routing table Destination Gateway Genmask Flags Iface 192.168.21.0 192.168.20.3 255.255.255.0 UG eth0 <Router> Kernel IP routing table Destination Gateway Genmask Flags Iface 192.168.20.0 * 255.255.255.0 U eth0 192.168.21.0 * 255.255.255.0 U eth1 <Receiver> Kernel IP routing table Destination Gateway Genmask Flags Iface 192.168.20.0 192.168.21.3 255.255.255.0 UG eth0

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

  11. Backup slides IETF 74 - NSIS

  12. PBS architecture On-path signaling PBS NSLP Processing Authorization NTLP (GIST) Processing Traffic Management Data flow Signal flow Control and configuration IETF 74 - NSIS

  13. FSM: Sender 1 Send Q Recv P & P(AV=0) 2 TTL=0 OR recv P(AV = 0) || remove permission state T.O. || change route & send Q Recv P & P(AV!=N) || apply IPsec for data Send Q 3 Recv P (new security algorithm) || Change the security algorithm for IPsec Send Data SV< AV 4 SV > AV || remove permission state Event || Action Q: Query message, P: Permission message, T.O.: Time out AV: The number of bytes that the receiver allows SV: The number of bytes that the sender has been sent State - 1: Idle, 2: wait for P, 3: Permission state, 4: compare SV and AV IETF 74 - NSIS

  14. FSM: Receiver 1 Decline || Send P(AV=0) TTL =0 OR No refresh || remove state and SA & send P(AV=0) Recv Q 2 Grant || setup permission state & install SA & send P(AV!=0, shared key) 3 Recv Q (SV) IPsec verification failed || Drop 4 6 Recv Data SV = RV || Send P IPsec verification success || calculate RV SV != RV 5 7 Revoke permission|| Remove state and SA & Send P(AV=0) RV > AV || remove state and SA & send P(AV=0) RV < AV Increase security|| send P(new security algorithm) Event || Action RV: The number of bytes that the receiver has been received State - 1: IDLE, 2: Permission decision, 3: Permission state, 4: IPsec verification, 5: compare RV and AV, 6: compare RV and SV, 7: Policy decision IETF 74 - NSIS

  15. FSM: Router 1 Recv Q || forward Q TTL=0 OR recv P (AV = 0) OR No refresh || remove state and SA Recv P(AV=0) 2 Recv P (AV!=0) || setup permission state and SA Recv Q 3 IPsec verification failed || Drop Data Recv P (new security algorithm) || Change the security algorithm for IPsec Recv Data 4 IPsec verification success || calculate RV 5 RV > AV || Drop Data RV < AV || forward Data Event || Action RV: 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 IETF 74 - NSIS

  16. PBS NSLP Signaling Message 16 R1 Receiver R2 Sender Query (10MB, FID) Query (10MB, FID) Query (10MB, FID) Permission (10MB, TTL, FID) Permission (10MB, TTL, FID) Permission (10MB, TTL, FID) Install permission state Install permission state T Query Query Query Permission Permission Permission IETF 74 - NSIS

  17. Basic operation of prevention 17 Sender R1 Receiver R2 Auth verification success Q (FID,PKey,Auth) Q ( FID,Pkey,Auth) Q (FID,Pkey,Auth) P (10MB, FID, Pkey, Skey, Auth) P (10MB, FID,Pkey, Skey, Auth) P (10MB, FID, Pkey, Skey, Auth) Data flow / IPsec Data flow / IPsec Data flow / IPsec Auth verification success IPsec verification success Attack flow IPsec verification failed IETF 74 - NSIS

  18. PBS Detection Algorithm (PDA) Spoof sender’s address, and has the shared key R1 R3 Receiver Sender Q Q Q Q P (10MB) P (10MB) P (10MB) P (10MB) Data (size=1MB)/ IPsec (symm key) Data (size=1MB)/ IPsec (symm key) Data (size=1MB)/ IPsec (symm key) Data (size=1MB)/ IPsec (symm key) Total 1MB T Attack (size=2MB) IPsec (symm key) Attack (size=2MB) IPsec (symm key) Total 3MB Q (1MB) Q (1MB) Q (1MB) Q (1MB) P (public key crypto) P (public key crypto) P (public key crypto) P (public key crypto) Detect attack (1MB Vs 3MB) Data (size=1MB)/ IPsec (Public key) Data (size=1MB)/ IPsec (Public key) Data (size=1MB)/ IPsec (Public key) Data (size=1MB)/ IPsec (Public key) Basic operation of PDA IETF 74 - NSIS

  19. PBS Detection Algorithm (PDA) (Attacker, Drop attack) Sender R1 R3 Receiver Query Query T.O. Change data flow path Detection of black hole attack IETF 74 - NSIS

  20. PBS Detection Algorithm (PDA) Sender (Attacker, Drop attack) Receiver R1 R3 Q Q Q Q P (10MB) P (10MB) P (10MB) P (10MB) Data (size=1MB) Data (size=1MB) T Detect attack (1MB Vs 0MB) Q (1MB) Q (1MB) Q (1MB) Q (1MB) P (change path) P (change path) P (change path) P (change path) Detection of dropping data packets IETF 74 - NSIS

More Related