Ki_simco-sctp_36454

INSTITUT FÜRNACHRICHTENVERMITTLUNG

UND DATENVERARBEITUNGProf. Dr.-Ing. Dr. h. c. mult. P. J. Kühn

Universität StuttgartINSTITUT FÜR

KOMMUNIKATIONSNETZEUND RECHNERSYSTEME

Prof. Dr.-Ing. Dr. h. c. mult. P. J. Kühn

Universität Stuttgart

Evaluation of SCTP as transport layerprotocol for firewall control

Sebastian Kiesel, Michael ScharfInstitute of Communication Networks and Computer Engineering

University of [email protected], [email protected]

Workshop "Neue Herausforderungen in der Netzsicherheit"an der Universität Duisburg-Essen

06/07.10.2005

Institute of Communication Networks and Computer Engineering University of Stuttgart

• Motivation

• Overview of problems with SIP and firewalls

• Introduction to IETF MIDCOM/SIMCO

• Overview of SCTP

• Testbed and measurement results

• Conclusions and future work

Outline


Next Generation Networks

• Carrier operated VoIP networks (SIP, RTP)

• Multi-operator scenarios

• Requirements

- Protection against denial-of-service attacks and VoIP spam

- Accountability

➥ Signaling and media path secured by firewalls

Firewalls

• "A firewall is a system or group of systems that enforces an accesscontrol policy between two networks."

• Realization by packet filter and/or proxies

➥ Firewalls in media path have to interact with session signaling

Motivation


SIP proxySIP user A SIP user B

SIP/RTP: basic call flow



A(+SDP)

INVITE (+SDP)

100 TRYING

180 RINGING180 RINGING

A

INVITE




B(+SDP )

A(+SDP)

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE




B(+SDP )

A(+SDP)

RTP/RTCP

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE




B(+SDP )

A(+SDP)

Parameter negotiation(Codec, bit rate,UDP port numbers,IP addresses, ...)

(+SDP )

(+SDP)A

B

RTP/RTCP

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE

SIP/RTP: dyn. cross-layer parameter negotiation


• Clouds: IP based Operator Networks (e.g., NGN)

• Network interconnection based on bilateral agreements,protected by means of firewalls

Firewalls and out-of-band signaling


SIP

SIPSIP

SIP



RTP

SIP

SIPSIP

SIP



Signaling messages may travel on different path through networkthan media streams do

➥ How to open pinholes in firewalls on media path?

ACL ACL? ?RTP

SIP

SIPSIP

SIP



Examples for path-coupled firewall signaling:

• RSVP

• IETF NSIS (Next Steps In Signaling) - NAT/FW NSLP

path−coupled FW signaling

ACL ACLRTP

SIP

SIPSIP

SIP



path−coupled FW signaling

ACL ACLRTP

SIP

SIPSIP

SIP

path−decoupled FW signaling

ACL ACLRTP

SIP

SIPSIP

SIP



Examples for path-decoupled firewall signaling:

• UPnP (home and small office LANs only)

• IETF MIDCOM (framework architecture) -> MIDCOM MIB or SIMCO

SIPproxy

PDPMIDCOM

SIP UA SIP UARTP

SIP

MIDCOM

specificimpl.repository

policy

user A user B

public network (e.g., Internet)private domain

MIDCOMprotocolinterface

protocolinterface

policy

packet filter("middlebox")

IETF MIDCOM - SIMCO


MIDCOM/SIMCO agent(e.g., SIP proxy)

Middlebox(e.g., packet filter)

IETF MIDCOM - SIMCO




Policy nableE ule(IP1, IP2, TCP/UDP/..., Port1, Port2, ...,

RLifetime)TID,

IETF MIDCOM - SIMCO




olicyP Enable ule ositivePR eplyR (TID,PID)


RLifetime)TID,

IETF MIDCOM - SIMCO




olicyP ifetimeL C hange (TID, PID, new Lifetime)

olicyP Lifetime C hange ositiveP eplyR (TID)



RLifetime)TID,

IETF MIDCOM - SIMCO




(TID)

(TID,

olicy Rule DeletionP

Policy ifetimeL hangeC PID,new Lifetime=0)

olicyP ifetimeL C hange (TID, PID, new Lifetime)

olicyP Lifetime C hange ositiveP eplyR (TID)



RLifetime)TID,

IETF MIDCOM - SIMCO



B(+SDP )

A(+SDP)

Parameter negotiation(Codec, bit rate,UDP port numbers,IP addresses, ...)

(+SDP )

(+SDP)A

B

RTP/RTCP

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE

SIMCO - Interaction with SIP/RTP



B(+SDP )

A(+SDP)

packet filter

RTP/RTCP

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE




B(+SDP )

A(+SDP)

BRTPPER RQ

PER PR

RTPA

PER RQ

PER PR

packet filter

RTP/RTCP

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE




B(+SDP )

A(+SDP)

Call setup delayBRTPPER RQ

PER PR

RTPA

PER RQ

PER PR

packet filter

RTP/RTCP

200 OK

ACK ACK

200 OK

INVITE (+SDP)

100 TRYING


A

INVITE



• Signaling protocol for Firewall and NAT control

• Implements (abstract) IETF MIDCOM architecture and semantics

• Policy Rules

- Generalized representation of packet filter rules, NAT bindings, etc.

- Soft state

• Messages

- Session management

- Create, modify, delete policy rules by means of transactions

- Status query transactions

- Asynchronous notifications

• Current status: Internet Draft

• Prototype Implementations: NEC Europe, Ltd., Uni Stuttgart/IKR

Summary SIMCO


SCTP (Stream Control Transmission Protocol, RFC 2960)

• Generic transport layer protocol optimized for signaling purposes,originally developed as part of the SIGTRAN stack for "SS7 over IP"

• Connection oriented: "SCTP association"

- Reliable transmission (checksums, flow-control, etc.)

- "TCP friendly" congestion control

- Message-oriented interface to upper layers (no continous byte-stream)

• Protocol mechanisms for deployment in high-reliability environments

- Multihoming, heartbeat/keepalive messages for automatic changeover

- Protection against "blind spoofing" and DoS attacks

• SCTP association subdivided in several "SCTP streams"

- Flow & congestion control applied to whole SCTP association

➥ More efficient than parallel TCP connections

- In-order delivery of messages ensured only within same stream

➥ Reduced head-of-line blocking

Stream Control Transmission Protocol


14 233

4

1

2

3

3

4

1

2

12343

4

3

2

1

1

2

4

3

TCP SCTP with 3 streams

• IP packet 3 lost or corrupted

➥ Retransmission

• Packet 4 has to wait inresequencing queue atreceiver until packet 3 isretransmitted

➥ Head-of-line blocking

• IP packet 3 lost or corrupted

➥ Retransmission

• Packets in other streams(e.g., packet 4) not affectedby head-of-line blocking

Head-of-line blocking: Illustration


Basic Question: how to leverage SCTP’s multiple streams feature?

Constraint: retain causality for SIMCO

Basic idea:

Agent and middlebox agree to use N bidirectional stream pairsupon session establishment

Distribution of messages to streams:

• SIMCO Agent ("client")

- Create new policy rules: use round-robin scheme to distribute requestson streams, once decided save mapping PID - stream ID

- Modify/Delete existing policy rule: reuse saved mapping

• Middlebox ("server")

- Send answer on same stream number than request was received on

Specification needs to consider some special cases

SIMCO over SCTP


ACK

SIP Proxy

SIP protocol entity

TCP SCTPUDP

transceiverSCTPTCP

transceiver

IP

SIMCO client

WAN

TCP SCTP

transceiverSCTPTCP

transceiver

packetfilterIP

Middlebox

SIMCO server

ruledeladd/

SIMCO over SCTP: Prototypical implementation


Emulator

Load Generator

Packet lossDelay,

responsetime

TCP SCTPUDP

transceiverSCTPTCP

transceiver

IP

SIMCO client

WAN

TCP SCTP

transceiverSCTPTCP

transceiver

packetfilterIP

Middlebox

SIMCO server

ruledeladd/

SIMCO over SCTP: Measurement testbed


Comparison of mean response time

➥ Several SCTP streams improve SIMCO response time

➥ Measured TCP performance much worse than SCTP

1 10Packet loss probability (in %)

10

100

1000M

ean

SIM

CO

res

pons

e tim

e (in

ms)

TCP

Theoretical lower bound

SCTP

1 stream

4 str.

8 streams

System load

• 30 ms call IAT (neg.-exp.)

• 180 s call duration(neg.-exp.)

• Equiv. to 120,000 userswith 0.05 Erl.

➥ 100 transactions/s

Network

• 20 ms RTT

• 10 Mbps data rate

• Random packet loss

Linux 2.6.11 TCP/SCTP

Measurement results


Response time distribution

➥ More than 8 SCTP streams will not significantly improve performance

10 100 1000SIMCO response time (in ms)

0.001

0.01

0.1

1C

ompl

. cum

ul. d

istr

. fun

ctio

n (C

CD

F)

TCPTheoreticallower bound

SCTP

1 stream4 str.8

System load

• 30 ms call IAT (neg.-exp.)

• 180 s call duration(neg.-exp.)

• Equiv. to 120,000 userswith 0.05 Erl.

➥ 100 transactions/s

Network

• 20 ms RTT

• 10 Mbps data rate

• Random packet loss

Linux 2.6.11 TCP/SCTP

4% packetloss

Measurement results


Conclusions

• Firewalls in VoIP networks to achieve PSTN-like security model

• SIMCO is a signaling protocol for path-decoupled firewall control

• SCTP is beneficial as transport protocol for SIMCO

- Less implementation complexity

- Protocol mechanisms for high-reliability environments

- Reduced head-of-line blocking

• Measurements with prototype implementation show that smallnumber of SCTP streams is sufficient

Future Work

• Performance impact of actually controlling a packet filter withSIMCO middlebox entity (e. g., Linux netfilter)

➥ Performance optimization by rule grouping/reordering possible?

• Explanation of observed TCP performance problems

Conclusions


Documents

Ki_simco-sctp_36454