Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Permission-Based Sending (PBS) Signaling Architecture for network traffic authorization Se Gi Hong*, Henning Schulzrinne*, Swen Weiland** *Columbia University,

Similar presentations


Presentation on theme: "1 Permission-Based Sending (PBS) Signaling Architecture for network traffic authorization Se Gi Hong*, Henning Schulzrinne*, Swen Weiland** *Columbia University,"— Presentation transcript:

1 1 Permission-Based Sending (PBS) Signaling Architecture for network traffic authorization Se Gi Hong*, Henning Schulzrinne*, Swen Weiland** *Columbia University, ** University of Goettingen

2 Internet –Any one can inject any IP packets into the network –Resource are shared by all users –Denial-of-Service (DoS) attacks are possible DoS attacks –Aim to disrupt the service provided by a network or server –Attacker might spoof the source address –Botnets: The attacker controls the compromised computer by IRC channel Botnet –The attacker controls the compromised computer by IRC (Internet Relay Chat) channel –SYN flood, ICMP flood and HTTP flood Attack 2 DoS attack Attack DATA Attack DATA

3 DoS attacks 3 From 40,000 sensors monitoring networks in over 180 countries through Symantec products and services and third-party sources.  The largest DDoS attack size: 40 Gb/sec, 2007  Cyberweapons  Political and military conflicts  Political fight between Estonia and Russia, 2007  Georgian-Russian war, 2008  “Internet Attacks Grow More Potent”, NY Times, Nov 9, 2008

4 4 DoS attack Attack typesAttacks Protocol-based attackBased on specific weaknesses of the Internet protocols TCP-SYN flood: vulnerability of the TCP three-way handshake ICMP flood: ICMP echo request packets directed to IP broadcast addresses Application-based attackTo force the target to execute expensive operations HTTP request flood to a target server SIP Invite packet flood with spoofed source IP address Reflector attackTo obscure the sources of attack Use third parties (reflectors) to relay attack traffic to the victim Infrastructure attackTo disable the services of critical components of the Internet Attack on DNS root servers Tao Peng and Christopher Leckie and Kotagiri Ramamohanarao, "Survey of network-based defense mechanisms countering the DoS and DDoS problems," ACM Computing Survey, Vol. 39, No. 1, Article 3, 2007.

5 Existing solutions Proactive approaches –Source address filtering Ingress filtering Prevent source address spoofing Problems –Universal deployment problem –Cannot prevent source address spoofing in the same subnet –Compromised router can inject and drop packets in Byzantine network –Capability-based approaches SIFF and TVA Capabilities –filter unauthorized flow Problems –Compromised router can break the system (weak in the Byzantine network) –Weak at changes of states (e.g., router changes)

6 Existing solutions Proactive approaches –Overlay-based approaches SOS and Mayday Overlay structure to verify the legitimacy of packets Problems –The overlay structure can be the target of the attack –Compromised overlay node can inject and drop packets –Expensive media relaying through the overlay

7 Existing solutions Reactive approaches –Filtering-based mechanism Pushback and StopIt Install filtering based on the detection of misbehavior of users Problems –Suffer from false positive –Compromised router can drop the packets –Traceback Probabilistic marking by router and reconstructing the data path Problems –Implementation problem »No specific field for tracking purposes in IPv4. –Spoofed marking field  mislead the path reconstruction –Overwrite marking filed  reduce probability to mark

8 Existing solutions Approach es solutionsBenefitDrawbackPossible attacks Implementation & deployment problem ProactiveIngress filtering SIFF, TVA SOS  Network resources are restricted, so attacks are prevented before harming the network.  If the attacker breaks the system, the attack is possible  On- path attacks are still possible in both approac hes  Traceback: No specific field for tracking purposes in IPv4  TVA: only for TCP  Ingress filtering: universal deployment problem  StopIt: modify BGP packets ReactivePushback Traceback StopIt  Monitoring attack traffic allows the system to react against the attacks dynamically.  Network resources are open to all users including attackers  suffer from false positive

9 Existing solutions Approac hes solutionsBenefitDrawbackPossible attacks Implementation & deployment problem ProactiveIngress filtering SIFF, TVA SOS  Network resources are restricted, so attack are prevented before harming the network.  If the attacker breaks the system, the attack is possible  On- path attacks are still possible in both approac hes  Traceback: No specific field for tracking purposes in IPv4  TVA: only for TCP  Ingress filtering: universal deployment problem  StopIt: modify BGP packets ReactivePushback Traceback StopIt  Monitoring attack traffic allows to react against the attacks dynamically.  Network resources are open to all users including attackers  False positive Prevention of attacks cannot be done by a single approach, so we need hybrid approach We need a solution to prevent on-path attack We need an integrated and practical solution

10 10 Overview of PBS Objective –Preventing DoS attacks and other forms of unauthorized traffic. Network traffic authorization –Permission is granted by the intended receiver. –Permission represents the authority to send data. Deny-by-default –Unauthorized traffic without permission is dropped at the first router by default. May I send? Yes, total 10 MB DATA Attack Yes, total 10 MB

11 11 Overview of PBS Hybrid approach –Proactive approach Explicit permission by on-path signaling –Reactive approach Monitoring traffics Secure mechanism –Secure permission state setup –Protect the authentication of data packets.

12 On-path signaling: PBS NSLP Next Steps in Signaling (NSIS) protocol suite Signaling application-specific functions (packet filter, NAT setting, etc) NSLP for QoS NSLP for NAT/firewall GIST (General Internet Signaling Transport) Transport layer security UDPTCPSCTPDCCP IP layer security IP PBS NSLP for network traffic authorization NTLP GIST API NSLP Control plane for signaling: NSIS

13 13 PBS NSLP Signaling Message Two-way handshake –Query message Sent by a sender to request permission. –Permission message Sent by a receiver. Set up (grant), remove (revoke) and modify permission state. Triggers reaction mechanism against the attacks. Soft-state –Robustness of the system –Periodic refreshing of the permission state Peer-to-Peer delivery –The signaling messages are delivered in peer-to-peer fashion between the nodes that have PBS functionality

14 14 Query (10MB, FID) Sender R1 R2 Receiver T Permission (10MB, TTL, FID) Permission Query Query (10MB, FID) Permission (10MB, TTL, FID) Install permission state PBS NSLP Signaling Message FID: 5-tuple based flow identification TTL: permission state time limit for the flow T: Soft-state period

15 Security What if an attacker sends bogus signaling message by spoofing the address? –Authentication and integrity problem of signaling message What if an attacker spoofs the sender’s address to send attack data? –Authentication problem of data packets

16 Security 16 Security to protect permission setup (signaling message) –Authentication and integrity for end-to-end communication encrypt signaling message fields by public key cryptography –Public key distribution signaling message carries the public key (X.509 certificate) Security to protect data packet –Authentication and integrity of data packets IPsec Authentication Header (AH) In the trustworthy network, symmetric key cryptography (HMAC) In the Byzantine network, public key cryptography (RSA, ECC) –Shared key distribution for IPsec Permission message carries the key Transport layer security (TLS/DTLS) for hop-by-hop communication –Security association and management of key Manual SA/Key management by Permission message

17 Basic operation of prevention 17 Q (FID,PKey,Auth) SenderR1 R2 Receiver Data flow / IPsec Attack flow (w/o IPsec) IPsec verification failed P (10MB, FID, Pkey, Skey, Auth) IPsec verification success Data flow / IPsec Q ( FID,Pkey,Auth) P (10MB, FID,Pkey, Skey, Auth) Auth verification success Pkey: public key Auth: authentication field for the signaling message Skey: shared key for Ipsec

18 PBS Detection Algorithm (PDA) What if a compromised router (that has the shared key for IPsec) inject attack packets? –Packet addition attack (on-path attack) What if a compromised router drops the incoming packets? –Black hole attack (on-path attack) Monitoring mechanism –PBS Detection Algorithm (PDA) –Detect on-path attack which breaks the permission state –Signaling (Query) message carries the information of volume of data that the sender has sent. –Use soft-state mechanism to periodically monitor the data flow.

19 PBS Detection Algorithm (PDA) 19 Sender R1R3Receiver Spoof sender’s address, and has the shared key T Data (size=1MB)/ IPsec (symm key) Q P (AV = 10MB) Q (v = 1MB) P (public key crypto) Q (v = 1MB) Detect attack (1MB Vs 3MB) Attack (size=2MB) IPsec (symm key) Attack (size=2MB) IPsec (symm key) P (public key crypto) P (AV = 10MB) QQQ 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 AV: allowed volume that is granted by the receiver V: total volume of data that the sender has sent

20 PBS Detection Algorithm (PDA) 20 Detection of black hole attack T.O. R1R3ReceiverSender (Attacker, Drop attack) Query Change data flow path

21 PBS Detection Algorithm (PDA) 21 Detection of dropping data packets Receiver R3R1 Sender Data (size=1MB) (Attacker, Drop attack) T Q (v = 1MB) P (change path) Q Q (v = 1MB) P (AV = 10MB) Data (size=1MB) Detect attack (1MB Vs 0MB) P (change path) P (AV = 10MB) QQQ

22 22 PBS 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 granting 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 messages. –IP packet filter drops the unauthorized packets. –Monitor data flow (check the total volume of the data flow).

23 PBS implementation structure 23 User level Kernel level On-path signaling PBS NSLP Processing (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) Network device Network device Authorization Traffic management 23

24 Testbed AMD Opteron 2.2GHz CPU and 2GB RAM Linux kernel version 2.6.23 24

25 Traffic overhead (signaling message overhead) Signaling message overhead ratio BW usage and signaling overhead ratio 4GB video streaming whose running time is 90 minutes (permission state life time is 90 minutes) Soft-state period is 60 seconds 25 Parameters for public keyBW (kbits/sec)Overhead ratio RSA-10240.3760.000062 DSA-10240.4030.000066 ECC-1920.3130.000051

26 Traffic overhead (data packet overhead) Data packet overhead ratio –Data packet carries IPsec header IPsec AH size and overhead ratio 26 Parameters for IPsec authentication field IPsec AH (bytes)Overhead ratio HMAC-SHA1280.021 RSA-1024320.085 DSA-1024840.037 ECC-1921400.042

27 CPU usage for signaling 27 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

28 Memory overhead Session key storage –(Session key size) x (number of concurrent sessions N) State table recording –(size of state record per flow) x (number of concurrent sessions N) –100 bytes x 10,000 = 1 MB 28 ParametersHMAC-SHA1RSA-1024DSA-1024ECC-192 Key size20 bytes128 bytes 24 bytes Key storage size (when N = 10,000) 0.2 MB1.28 MB 0.24 MB

29 Signaling message processing delay Signaling message processing delay based on public key cryptography GIST handshake delay 29 ParametersQuery message (msec)Permission message (msec) NULL0.1310.134 RSA-10240.4230.436 DSA-10241.6741.701 ECC-1921.8681.892 UDPTCPTLS GIST handshake (msec)0.41110.05723.383 NULL: no cryptography algorithm is applied to signaling messages

30 IPsec processing delay Data packet (with and without IPsec) processing delay 30 ParametersIPsec processing delay (msec) Without userspace IPsec module0.010 NULL encryption0.057 HMAC-SHA10.067 RSA-10240.198 DSA-10241.411 ECC-1921.649 Userspace IPsec module: capture packet from kernel to user level to process the IPsec, and then sends back the packet to the kernel Null encryption: No IPsec verification

31 Deployment and application At the edge routers –Edge routers at the sender’s area Drop the attack packets from the off-path attacker –Edge routers at the receiver’s area Drop the attack packets that are generated in the backbone Close-network –All end-users have PBS functionality –Deny-by-default –Short stream flows, such as DNS and ICMP Flow state setup delay and signaling message overhead Rate limited Open-networks –Some end users do not have PBS functionality The packets from the sender which does not have PBS functionality will be rate-limited. 31

32 Conclusion Signaling architecture for network traffic authorization Hybrid approach –Proactive approach: Explicit permission by signaling –Reactive approach: PBS detection algorithm (PDA) Secure system –The authentication and integrity of signaling message: Public key cryptography algorithm –The authentication and integrity of data packets: IPsec AH Practical and deployable system DoS defense mechanism –Off-path/on-path attacks 32

33 Backup slides 33

34 Existing solutions Proactive approaches –Source address filtering Ingress filtering Allow packets whose IP address in the expected IP address range Prevent source address spoofing Deployment problem –Universal deployment problem Attack that cannot be prevented –IP address spoofing in the same subnet –Compromised router can inject and drop packets (on-path attack) –Capability-based approaches SIFF and TVA Permission (capability): filter unauthorized flow Breakable system –Compromised router gives bogus capability –Compromised router announces the capability to the upstream nodes Attack that cannot be prevented: on-path attack –Compromised router can use the capability to inject attack flow. –Compromised router can drop packets  Not guaranteed for delivery

35 Existing solutions Proactive approaches –Overlay-based approaches SOS and Mayday Overlay structure to verify the legitimacy of packets Breakable system –The overlay structure can be the target of the attack Attack that cannot be prevented –Compromised overlay node can inject and drop packets Expensive media relaying.

36 Existing solutions Reactive approaches –Filtering-based mechanism Pushback and StopIt Detection of misbehavior of users  request filtering Suffer from false positive Attack that cannot be prevented: on-path attack –cannot guarantee the delivery of legitimate packet –Traceback Probabilistic marking by router / reconstruct the path Implementation problem –No specific field for tracking purposes in IPv4. Breakable system –Spoofed marking field  mislead the path reconstruction Attack that cannot be prevented: on-path attack –Overwrite marking filed  reduce probability to mark

37 Delay Round-trip delay of signaling message before sending data packets –Measure signaling message processing delay –Measure GIST handshake delay 37 GIST handshake SenderR1Receiver Permission Query Permission RTT Query processing delay GIST handshake Permission processing delay GIST delay Query

38 State - 1: Idle, 2: wait for P, 3: Permission state, 4: compare SV and AV Send Q Recv P & P(AV!=N) || apply crypto for data based on S value of P Send Data SV< 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 || 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 1 2 3 4 FSM: Sender 38

39 Recv Q Grant || setup permission state & install SA & send P(AV!=0, shared key) TTL =0 OR No 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 || 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 1 2 3 4 5 6 7 FSM: Receiver 39

40 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 || 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 1 2 3 4 5 FSM: Router 40

41 Implementation structure Signaling (PBS NSLP / GIST) –PBS NSLP on GIST implementation using FreeNSIS implementation http://user.informatik.uni-goettingen.de/~nsis/ –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 Unix socket: Communication between GIST and PBS NSLP Selection of UDP/TCP/TLS: channel reliability and security 41

42 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 of 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. 42

43 Security analysis of PBS Trustworthy networks –Attack without spoofing address 5-tuple based IP packet filtering –Attack with spoofing source address PDA can detect IPsec: Symmetric key cryptography Byzantine networks –Off-path attacks 5-tuple / PDA IPsec: Symmetric key cryptography –On-path attack: packet addition PDA can detect the attack IPsec: public key cryptography –On-path attack: packet dropping Signaling message and PDA can detect the attack Change the path Sender attack –Black and white list –Permission request gives the precise behavior profile of a sender 43

44 Detection delay and number of attack flows Detection delay –As attack flows are detected quickly, the number of attack flows decreases –Detection delay depends on the soft-state period of signaling messages Assumption –Legitimate flow arrival rate and attack flows arrival rate follow Poisson distribution –Expected lifetime of all the flows Attack flow lifetime: legitimate flow lifetime: –Attack flow ratio Ratio of attack flow arrival rate over total flow arrival rate, Soft-state period, 44

45 45 Detection delay and number of attack flows Attack flow arrival rate is 0.8, but actual number of attack flows are reduced since detection shortens the attack flow’s lifetime


Download ppt "1 Permission-Based Sending (PBS) Signaling Architecture for network traffic authorization Se Gi Hong*, Henning Schulzrinne*, Swen Weiland** *Columbia University,"

Similar presentations


Ads by Google