SIP, Firewalls and NATs Oh My!. SIP Summit 2001 5.01.01 SIP, Firewalls and NATs, Oh My! Getting SIP...

SIP, Firewalls and NATsOh My!

www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, Firewalls and NATs, Oh My!

Getting SIP Through Firewalls

Firewalls Typically Statically Configured to Let Traffic in/out of Specific Ports/Addresses

SIP Itself Can Easily Be Let in/out Static port 5060 opened

But SIP Signals Media Sessions, Usually RTP

RTP Difficult to Isolate Uses dynamic UDP ports Not its own protocol No way to statelessly identify

Therefore, Media Sessions Will Not Flow Through SIP-unaware Firewall

Application Layer Gateway (ALG) function required


Getting SIP Through NATs Network Address Translation

(NAT) Creates address binding between

internal private and external public address

Modifies IP Addresses/Ports in Packets

Benefits Avoids network renumbering

on change of provider Allows multiplexing of multiple

private addresses into a single public address ($$ savings)

Maintains privacy of internal addresses

Problems Bindings for media sessions need

to be explicitly created IP addresses and ports written in

SIP packets will be wrong SDP From field To field Contact Record-route Via

ALG function required


Two Distinct Cases Case I: SIP Provider is the IP

Network Provider Enterprises which deploy SIP Carriers

Case II: SIP Provider is NOT IP Network Provider Residential NATs Users within enterprises Cable companies with NAT Airport lounges Hotels Internet cafes

FW/NAT

Proxy

Users

FW/NATProxy

Users

IP Provider

SIP Provider

IP Provider

SIP Provider


Proposed Solution for Case I Separate Application Layer

NAT/Firewall from IP Layer NAT/Firewall Like megaco decomposition

MG = packet filter MGC = Firewall Control Proxy

Same benefits Better scaling Faster Lower Cost Expertise problem solved Deployment paths for new apps Load balancing

IETF standard: MIDCOM Actual deployments today!

SIP

Control

RTP

Firewall Control Proxy

(FCP) Firewall/NATPacket Filter

Decomposed Firewall/NAT


What about Case II? Much harder problem!

No way to control firewall or NAT Huge installed based of SIP unaware devices Variable firewall and NAT behaviors

Proposed Solution: Make SIP “NAT Friendly”

Can work through existing NATs! NATs a bigger problem for case II than firewalls

Handle firewalls separately Send it all through TLS over port 443 Define well-known RTP ports + symmetric RTP = existing firewalls can be

configured with static rules to support VoIP


Basic Approach Find ways to ignore IP addresses in SIP/SDP wherever possible

Get the information from the transport connections themselves

Find ways to make a peer to peer application look like client server One side initiates Can send data back and forth

Don’t rely on DNS, since many clients won’t have domain names


Specific Problems to Address Response from proxy to caller

SIP Via header used for sending response

Sent to port in Via header Will be wrong! Must figure out how

to ignore ANSWER: TCP

Proxy to called party Proxy forwards request to IP

address and port in registration These will be wrong No address binding for them

RTP Addresses in SDP are used, these

are wrong No bindings for them

1

2

3


Contact Cookie Special contact value which

tells registrar “register my contact using the IP address and port where the register came from” Register comes from persistent

TCP connection to server Causes calls to be routed to UAS

through NAT!

Want to be explicit Call forward service

Contact “cookie” Special URL Sip:<user>@jibufobutbmpu

TCP Connectionthen REGISTER


Symmetric RTP

Today, RTP is unidirectional Two RTP sessions, one in each

direction Means both sides provide IP addresses

– BAD

Big Idea: What if one side “connects” to the other

by sending RTP packet Recipient sends RTP packets back to

source IP of received RTP packet Just like TCP operation, but over UDP

Conceptually, this is Symmetric RTP

Means only one side needs to provide IP address – just like client/server

Can use RTP translators in SIP network when both are behind NAT Caller

IP ACalleeIP B

NAT

Private Network

A->B A’->BSource = A’

B->A’B->A

A<->A’ bindingestablished

Sends to A’

RTP pkt

RTP pkt


Benefits of this Approach Requires relatively small

change to clients

Solves many other problems at the same time SIP Java applets can now be

written SOCKS now works Multihomed host configuration

problems disappear

Just the end-to-end argument Applications need to adapt to the

network conditions provided to them

Can design optimal, simplest approach

Status Presented to IETF in March Good support, moving forward

Information Resource Jonathan [email protected]

SIP, Firewalls and NATs Oh My!. SIP Summit 2001 5.01.01 SIP, Firewalls and NATs, Oh My! Getting SIP...

Documents

Transcript of SIP, Firewalls and NATs Oh My!. SIP Summit 2001 5.01.01 SIP, Firewalls and NATs, Oh My! Getting SIP...