Transcript snom technology Presentation

Running SIP behind NAT
Dr. Christian Stredicke, snom technology AG, [email protected]
Miami, USA, February 2002
2
Some Statistics First…
• Who made a cell phone call here?
• Who made a SIP call here?
– Who tried?
– Who succeeded?
• Who has a SIP phone at home?
• The Pulver Report - January 16, 2003 Issue:
– “2003: The Year of Consumer Communications“
– Looks like we have to change a couple of things
V1.0
3
• Router needs hint for security
checking
– Accept packets from any
destination
– Accept packets only from
associated host
– Accept packets only from
associated host and port
V1.0
192.168.0.1
• Router needs information
where to send packets in
private network
– Map port to private address
and port
– By default packets will be
rejected or sent to DMZ
123.123.123.123
Which information does a client has to set up for
port forwarding in NAT equipment?
Client
Client
Router
4
How did other applications solve the problem?
• HTTP, telnet, …
– Using TCP
• DNS, others
– “Digging holes”: Set up association when client
sends out packet from unmapped port for 15-60
seconds
– Security policy hardwired by vendor
– Some offer a DNS proxy (application layer gateway)
• ftp
– Does not work!
– Inexperienced users use http instead
– Some routers offer applications layer gateway
• Heterogeneous environment
– Every vendor does it in a different way
– “Digging holes” is common denominator
V1.0
5
Application layer gateways (ALG) solve the
problem in the business area
• Business customers have different requirements than
home users
– Many phones
– Want to run proxies, media servers, application servers
behind their firewall
– These applications probably will not have UPnP or STUN
• Therefore, firewalls will probably include SIP-aware
ALG
• Commercial products e.g. from Cisco, Intertex, Ingate,
Jasomi, …
V1.0
6
STUN uses the digging hole trick to set up port
associations
• Initialization procedure checks environment
– Goal: Check if STUN is needed
– Type of NAT does actually not really matter because user
is not interested in failure reason
• SIP port kept alive by sending packets every 15-60 s
• RTP ports are allocated dynamically when starting a
call
– Otherwise keep-alive traffic would be double
– RTCP port can not be allocated because next port
allocation is unlikely
– Long ringing and putting caller on hold is problematic (no
port refresh during this time)
V1.0
7
TURN works in symmetrical NAT environment, but
has too many problems
• Set up a “mirror” in the public Internet
– Forward all packets to the “hole”
• Scalability
– TURN server becomes “media server”
– Every call generates about 50 packets per second
• Delay
– Sending packets over media server increases transport
delay significantly
– E.g. local call in Tokyo when TURN server is in Frankfurt
V1.0
8
The 90 % Problem: STUN works fine in 90 % of
the cases
• Some routers do not run STUN without user interaction
– Stateful inspection
– Trying to be smart
– Users must set up DMZ
• 10 % support calls are intolerable
• STUN can only be „gap-filler“
– “Best Effort”
– No support
• Need clear indication if VoIP will work
– Clear technical specification under which circumstances
customers can expect setup to work
– UPnP is good candidate for this
V1.0
9
UPnP is the right approach.
• Generic protocol to allocate ports on router
– Works with SIP, can be used with other applications as
well
– Can be integrated with firewalls
– Not too hard to implement
• Microsoft Messenger uses UPnP
– “De facto standard”
– Many DSL router vendors offer UPnP now
• Problem: Old Equipment
– Software Updates!
– Use STUN
– Maybe use TURN, even if call duration is terrible
– Instruct customers to set up ports manually
V1.0
10
How does port forwarding in UPnP work?
• Find the Internet access device
– Broadcast messages (no user setup required)
– Download the description of the UPnP device via http
• Retrieve the public IP address from the router
• Set up port mapping explicitly
– http requests using XML (SOAP) attachments
• Other commands also available
– UPnP is much more than setting up port forwarding on
routers
V1.0
11
With the increasing availability of UPnP, most
home customers can be addressed
Beginning of 2003
End of 2003
STUN
STUN
UPnP
• Software Updates
• New Equipment
V1.0
UPnP
12
Calling phones in the same network requires
ancillary information*
1a) Phone A sends to
public address of B
1b) Router will not
forward packet, call
will fail
2) A knows B is in the same NAT and
sends packet to private address instead
V1.0
* If no ALG is involved
13
Ancillary information must be placed in contact
URI and in SDP*
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 218.230.0.59:5060;branch=z9hG4bK-6rms4e9tmtsz
Max-Forwards: 70
From: <sip:[email protected]>;tag=16z5zw9lqt
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060;srcadr=192.168.0.4%3A5060;transport=udp;line=1>
Content-Type: application/sdp
Content-Length: 311
v=0
o=root 19211 19211 IN IP4 218.230.0.59
s=SIP Call
c=IN IP4 218.230.0.59
t=0 0
m=audio 10004 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=x-private:192.168.0.4:10004 218.230.0.59:10004
V1.0
* Non-standardized example
14
Multi-tier NAT requires a list of private addresses
and a STUN/UPnP server between the NATs
STUN
When using STUN,
a STUN server is
required between
the layers
STUN
123.123.123.123
10.0.0.1
10.0.0.2
NAT1
10.0.0.3
NAT2
NAT3
192.168.0.1
192.168.0.1
Phone A
192.168.0.2
V1.0
A has three identities:
1. 192.168.0.2:5060
2. 10.0.0.2:1234
3. 123.123.123.123:5678
Phone B
192.168.0.2
B has three identities:
1. 192.168.0.2:5060
2. 10.0.0.3:1234
3. 123.123.123.123:5679
15
How should a phone boot up?
Try UPnP
UPnP available
Use UPnP
Try to Register
Registrar
complains about
private address
Use STUN
V1.0
No response (5 seconds)
or not available
This step can be done even
without STUN, as the registrar
returns the response quick
No problem: either
public address, ALG or
total private
environment
Use Given Identity
16
Is UPnP secure? A possible man-in-the-middle
attack scenario…
1. A opens RTP
forwarding port
2. B retrieves
forwarding table
3. B rearranges
port forwarding
Phone A
V1.0
4. B receives all RTP
from the IAD and forwards
it to A (after recording it)
Phone B
• Same attack can be done with signaling
• Can be solved with TLS and SRTP
17
Security is ok for home networks, but for business
networks some enhancements are needed
• How much security needs a home?
– Son listens to call of daughter
– Son listens to call of father doing telephone banking
– Son using packet sniffer, son is listening on the door
• STUN is also not secure
– ARP attacks can also redirect the packet flow (however
that’s not so easy)
• Attacks from the outside
– Orphan bindings may give access to private devices
– Devices should be able to deal with this anyway
• Security enhancements in UPnP Version 2
• Businesses should use ALG which takes care about it
V1.0
18
To make UPnP more reliable, clients need to
allocate bandwidth
• Don’t allocate bandwidth “just in case”
– Allocating ports in the beginning is easy and can set
scheduling priorities
– But when too many VoIP calls are done, all of them suffer
• Ask for bandwidth before a call starts
– Sending busy is better than having stuttering calls
– Phone needs to know when bandwidth is available again
so that call completion can be indicated
– Notification when bandwidth is available
• Could be added to current allocation requests
– Bandwidth indication
– Insufficient bandwidth as denial reason
V1.0
19
Conclusion: You must choose what to tell the
customer about NAT
• If you can, use an ALG
– Works will all SIP-compliant equipment
– Most expensive solution, but complete functionality
• Else if you can, use UPnP
– Works with all SIP- and UPnP-compliant equipment
– “MS Messenger” solution, routers for 65 $ available
– Problems making calls within the private network
• Else if you dare, use STUN
– Works with all SIP- and STUN-compliant equipment if the
routers are not inspecting packets
– Could become support-headache
– Also problems in the private network
• If you also want to support the rest, think about TURN
– Works with all SIP-, STUN/TURN-compliant equipment and
the 99% of the NAT routers
V1.0
sip:[email protected]
© 2003 snom technology Aktiengesellschaft
Written by:
Dr. Christian Stredicke
Version: 1.0
The author has made his best effort to prepare this document. The content is
based upon latest information whenever possible. The author makes no
representation or warranties of any kind with regard to the completeness or
accuracy of the contents herein and accept no liability of any kind including but
not limited to performance, merchantability, fitness for any particular purpose,
or any losses or damages of any kind caused or alleged to be caused directly or
indirectly from this document.
For more information, mail [email protected], Pascalstr. 10E, 10587 Berlin,
Germany.
22
192.168.0.1
123.123.123.123
124.124.124.124
In cases when NAT is symmetrical, TURN could be
a solution
Client
3. SIP/Media
Client
STUN/TURN Server
V1.0
Router