sip, firewalls and nats oh my!. sip summit 2001 5.01.01 sip, firewalls and nats, oh my! getting sip...
TRANSCRIPT
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
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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/NATProxy
Users
IP Provider
SIP Provider
IP Provider
SIP Provider
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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/NATPacket Filter
Decomposed Firewall/NAT
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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
Don’t rely on DNS, since many clients won’t have domain names
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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 Sip:<user>@jibufobutbmpu
TCP Connectionthen REGISTER
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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 ACalleeIP B
NAT
Private Network
A->B A’->BSource = A’
B->A’B->A
A<->A’ bindingestablished
Sends to A’
RTP pkt
RTP pkt
www.dynamicsoft.comSIP Summit 2001 5.01.01SIP, 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 [email protected]