SIP, Firewalls and NATs

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

3
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

4
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
IP Provider
Proxy
SIP Provider
Users
Users
Proxy
FW/NAT
IP Provider
SIP Provider
5
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!

Decomposed Firewall/NAT
Firewall Control Proxy (FCP)
Firewall/NATPacket Filter
Control
SIP
RTP
6
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

7
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

8
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

2
1
3
9
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
• Sipltusergt_at_jibufobutbmpu

TCP Connection then REGISTER
10
Symmetric RTP
Private Network

• 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

Alt-gtA binding established
A-gtB
A-gtB
Source A
RTP pkt
B-gtA
B-gtA
Sends to A
RTP pkt
NAT
Caller IP A
Callee IP B
11
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

12
Information Resource
Jonathan Rosenberg 1.973.952.5000jdrosen_at_dynamic
soft.com