SIP, Firewalls and NATs Oh My!

SIP Summit SIP, 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

SIP Summit SIP, Firewalls and NATs, Oh My! 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

SIP Summit SIP, Firewalls and NATs, Oh My! 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/NAT Proxy Users IP Provider SIP Provider IP Provider SIP Provider

SIP Summit SIP, Firewalls and NATs, Oh My! 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/NAT Packet Filter Decomposed Firewall/NAT

SIP Summit SIP, Firewalls and NATs, Oh My! 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

SIP Summit SIP, Firewalls and NATs, Oh My! 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 Dont rely on DNS, since many clients wont have domain names

SIP Summit SIP, Firewalls and NATs, Oh My! 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

SIP Summit SIP, Firewalls and NATs, Oh My! 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 TCP Connection then REGISTER

SIP Summit SIP, Firewalls and NATs, Oh My! 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 A Callee IP B NAT Private Network A->B Source = A B->A A A binding established Sends to A RTP pkt

SIP Summit SIP, Firewalls and NATs, Oh My! 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 Rosenberg