1

Permission-Based Sending (PBS)Signaling Architecture for network traffic authorization

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

• 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

AttackAttack

2

DoS attack

AttackAttack

AttackAttack

Attack

Attack

DATADATA AttackAttack

AttackAttack DATA

DATA

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

CyberweaponsPolitical and military conflictsPolitical fight between Estonia and Russia, 2007Georgian-Russian war, 2008“Internet Attacks Grow More Potent”, NY Times, Nov 9, 2008

4

DoS attack

Attack types Attacks

Protocol-based attack •Based 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 attack •To force the target to execute expensive operations•HTTP request flood to a target server•SIP Invite packet flood with spoofed source IP address

Reflector attack •To obscure the sources of attack•Use third parties (reflectors) to relay attack traffic to the victim

Infrastructure attack •To 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.

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)

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

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

Existing solutions

Approaches

solutions

Benefit Drawback Possible attacks

Implementation & deployment problem

Proactive

•Ingress 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 approaches

Traceback: No specific field for tracking purposes in IPv4 TVA: only for TCP Ingress filtering: universal deployment problem StopIt: modify BGP packets

Reactive •Pushback•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

Existing solutions

Approaches

solutions Benefit Drawback Possible attacks

Implementation & deployment problem

Proactive

•Ingress 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 approaches

Traceback: No specific field for tracking purposes in IPv4 TVA: only for TCP Ingress filtering: universal deployment problem StopIt: modify BGP packets

Reactive

•Pushback•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

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?

May I send?

May I send?May I send? May I send?

May I send?

Yes, total 10 MBYes, total 10 MB

Yes, total 10 MB

Yes, total 10 MB

DATADATA

DATADATADATADATA

AttackAttack

Yes, total 10

MBYes, total 10

MB

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.

On-path signaling: PBS NSLP

• Next Steps in Signaling (NSIS) protocol suite

Signaling application-specific functions (packet filter, NAT setting, etc)

NSLP for QoSNSLP for

NAT/firewall

GIST(General Internet Signaling Transport)

Transport layer security

UDP TCP SCTP DCCP

IP layer security

IP

PBS NSLP for network trafficauthorization

NTLP

GIST API

NSLP

Controlplane forsignaling:NSIS

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

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

FID: 5-tuple based flow identificationTTL: permission state time limit for the flow T: Soft-state period

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

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

Basic operation of prevention

17

Q (FID,PKey,Auth)

Sender R1 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 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

Pkey: public keyAuth: authentication field for the signaling messageSkey: shared key for Ipsec

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.

PBS Detection Algorithm (PDA)

19

Sender R1 R3 ReceiverSpoof 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) Q (v = 1MB) 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 (public key crypto) P (public key crypto)

P (AV = 10MB) P (AV = 10MB) P (AV = 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

AV: allowed volume that is granted by the receiverV: total volume of data that the sender has sent

PBS Detection Algorithm (PDA)

20

• Detection of black hole attack

T.O.

R1 R3 ReceiverSender (Attacker, Drop attack)

Query Query

Change data flow path

PBS Detection Algorithm (PDA)

21

• Detection of dropping data packets

ReceiverR3R1Sender

Data (size=1MB)

(Attacker, Drop attack)

T

Q (v = 1MB)

P (change path)

Q

Q (v = 1MB) Q (v = 1MB) Q (v = 1MB)

P (AV = 10MB)

Data (size=1MB)

Detect attack(1MB Vs 0MB)

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

P (AV = 10MB) P (AV = 10MB) P (AV = 10MB)

Q Q Q

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

PBS implementation structure

23

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

23

Testbed

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

24

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

signal

signals LL

LR

Parameters for public key

BW (kbits/sec)

Overhead ratio

RSA-1024 0.376 0.000062

DSA-1024 0.403 0.000066

ECC-192 0.313 0.000051

flow for the messages signaling totalof size:

flow theof packets data totalof size:

signalL

L

Traffic overhead (data packet overhead)

• Data packet overhead ratio– Data packet carries IPsec header

• IPsec AH size and overhead ratio

26

sec

sec

ip

ipd LL

LR

Parameters for IPsec authentication field

IPsec AH (bytes) Overhead ratio

HMAC-SHA1 28 0.021

RSA-1024 32 0.085

DSA-1024 84 0.037

ECC-192 140 0.042

flow theofheader ipsec totalof size:

flow theof packets totalof size:

secipL

L

CPU usage for signaling

27

CPU usage of PBS NSLP

0

10

20

3040

50

60

70

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

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

usa

ge (%

)

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

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

Parameters HMAC-SHA1

RSA-1024 DSA-1024 ECC-192

Key size 20 bytes 128 bytes 128 bytes 24 bytes

Key storage size (when N = 10,000)

0.2 MB 1.28 MB 1.28 MB 0.24 MB

Signaling message processing delay

• Signaling message processing delay based on public key cryptography

• GIST handshake delay

29

Parameters

Query message (msec)

Permission message (msec)

NULL 0.131 0.134

RSA-1024 0.423 0.436

DSA-1024 1.674 1.701

ECC-192 1.868 1.892

UDP TCP TLS

GIST handshake (msec)

0.411 10.057 23.383

NULL: no cryptography algorithm is applied to signaling messages

IPsec processing delay

• Data packet (with and without IPsec) processing delay

30

Parameters IPsec processing delay (msec)

Without userspace IPsec module

0.010

NULL encryption 0.057

HMAC-SHA1 0.067

RSA-1024 0.198

DSA-1024 1.411

ECC-192 1.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

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

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

Backup slides

33

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

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.

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

Delay

• Round-trip delay of signaling message before sending data packets– Measure signaling message processing delay– Measure GIST handshake delay

37

GIST handshake

Sender R1 Receiver

Permission

Query

Permission

RTT

Query processing delay GIST handshake

Permission processing delay

GIST delay

Query

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

Send Q

Send QRecv P & P(AV!=N)|| apply crypto for data based on S value of P

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

38

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

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

40

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

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

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

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

la

][][][ ll

aa

L TETETE

2)1(][

][

][

][

rr

r

TE

TE

NE

NER

L

aaa

ar

l

P

TT

aT lT

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