Categories

CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Thursday, 23 January 2014

SIP firewall traversal and why does SIP Not Handle NAT so good?

The problem

Stacks and stacks of people run into trouble getting SIP to work in conjunction with NAT. One of the most typical problems that are caused by NAT is that inbound calls fail when connected to a SIP provider across the internet, whereas outbound  and internal calls work without any problems. 


I have seen this issue being raised numerous times on various forums. What I am aiming for in this post is to do an analysis on why SIP can be so troublesome when crossing a NAT boundary (a.k.a. Firewall traversal), and what can be put in place from a Cisco perspective to get it to work. Obviously with the multitude of various technologies and scenarios it is impossible that this post can offer a one fits all solution to SIP-NAT issue. But I will do my best to offer  more detailed insight into its challenges.

Let's take a very common scenario. A user with, for instance, FreePBX or CME and a SIP account connects to the internet and registers to his service provider for inbound and outbound telephony. Now that same router (or firewall) will have some sort of security, mainly for inbound initiation of traffic.   
Simply opening this router up on port 5060 (TCP or uUDP) and setting up a static NAT for these same ports using the IP address of your PBX or CME, is not going to cut the mustard. because SIP is essentially a signalling protocol to deliver media, one would need to do static NAT for a whole range of ports that RTP will use, and that are dynamically assign inside the SDP (RFC 2327part of the SIP packets.

The problem is not in the first place the SIP signalling itself, it is more related to the way it handles the set up and negotiation of RTP. 

The Theory

NAT is very simple mechanism; it translates source or destination IP addresses and ports either dynamically of statically. So really, all NAT does is re-write IP packet headers and leave the payload unchanged. In OSI model world; everything up to Layer 4 gets re-written. 

Signalling protocols, be it Skinny, SIP, MGCP, H323 or SIP do not operate at layer 4; they operate on an application level.Which means that IP address information is embedded in the IP packet's payload. You can see what is going to unfold here; it will break communications. Because protocols like Telnet, HTTP, NTP or NFS do not have any IP addressing embedded in their payload, they are far more sympathetic towards NAT.


In the case of RTP, the SIP message body contains the information that the endpoints need in order  to communicate directly with each other. This information is contained in the SDP message. The  end point clients fill in that information according to what they know about themselves and they are NOT aware of any NAT upstream. A SIP client knows only about its interal IP address and this is what it will put in the SDP body of the outgoing SIP message. When the destination endpoint wants to start sending packets to the  originating endpoint, it will use the received SDP information containing the internal IP and port of the originating endpoint and the packets never get there. 

Lets head over to an example.This example is a SIP invite received by a gateway, from a client behind a NAT boundary, and a proxy between the two gateways.


001  INVITE sip:12125551212@211.123.123.123 SIP/2.0
002  Via: SIP/2.0/UDP 211.21.21.21:5060;branch=a71b6d57-507c77f2
003Via:SIP/2.0/UDP10.0.0.1:5060;received=202.123.123.123;rport=12345
004  From: <sip:0387878787@211.123.123.123>;tag=108bcd14
005  To: sip: 0389898989@211.123.123.123
006  Contact: sip: 12125551212@10.0.0.1
007  Call-ID: 4c88fd1e-62bb-4abf-b620-a75659435b76@10.3.19.6
008 CSeq: 703141 INVITE
009 Content-Length: 138
010  Content-Type: application/sdp
011 User-Agent: XCP Client
012
013 v=0
014  o=dogtel 0 0 IN IP4 10.0.0.1
015  s=dogtel
016  c=IN IP4 10.0.0.1
017 t=0 0
018  m=audio 8000 RTP/AVP 4
019 a=ptime:90
020 a=x-ssrc:00aea3c0



In the example, the client that actually sent the INVITE (line 003) , has put in its own IP:port of 10.0.0.1:5060  however, the proxy has put in the received 202.123..123.123:12345. So the proxy is aware of the NAT-ed address of the client. This also means that the proxy is able to send the traffic back to the NAT-ed client. As you can see the the SDP portion of this packet still uses the client's real IP address and port.(lines 14 and 18). The result of this will be that a phone will ring, but there will be no voice, because RTP cannot be delivered end to end.


The Solutions:


There are 4 techniques that can be use to carry SIP across NAT boundaries:

-UPnP
-External Query
-STUN, TURN, ICE
-SIP Capable Firewalls (Inspection)


UPnP:

Universal Plug and Play is not directly related to the traditional definition of plug you device in and it just works. It is a set of networking protocols, which permit networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications, and entertainment. UPnP is intended primarily for residential networks without enterprise-class devices. In terms of NAT traversal, UPnP includes what is called the Internet Gateway Device Protocol (IGD Protocol), is implemented via UPnP. Many routers and firewalls expose themselves as Internet Gateway Devices, allowing any local UPnP control point to perform a variety of actions, including retrieving the external IP address of the device, enumerate existing port mappings, and add or remove port mappings. By adding a port mapping, a UPnP controller behind the IGD can enable traversal of the IGD from an external address to an internal client. But you can forget about this method, as Cisco does not use it. Think of this as the Microsoft method

External Query
An external query to find out the outside/public IP address:port is can be done, if no method of communication is available between gateway and client, such as in the UPnP case. Basically, it is like the client sending a probe to a server on the outside. That server will respond with something along the line like "he dude, I have just seen you source a packet from 213.10.10.10:12345". After the client receives that answer back it will start using that in its SIP SDP  body.


STUN , TURN, ICE

All these are protocols proposed by IETF for solving NAT Traversal. I do not want to go into too much detail as you will not come across this very often in a Cisco engineer capacity.

STUN (Simple Traversal of UDP through NAT) is a lightweight client-server is a network protocol. Its purpose is to allow an application running on client  to determine if it is behind a NAT boundary. In order to find out the client's public IP address and NAT type, it queries a public STUN server. This STUN  server responds with a success message that allows the client to obtain this information by looking at the success message's IP payload. This information is then used to set up UDP communication between two hosts that are both behind NAT routers. The STUN protocol is defined in RFC 3489. Clients that are STUN aware, can set their SDP packets accordingly. The STUN capable client will need to be made aware of the STUN server. 


All of the methods above and particularly STUN and External Queries, work really well when symmetric NAT is deployed.  Asymmetrical NAT;    not so good (Asymmetric NAT, where the NAT-ed source IP, depends on the destination IP).


SIP Capable Firewalls (SIP inspection)

Solving the problem, where it is created. Application layer inspection does just that and ASA 5500's have software engines to do this. Because the ASA will need to do deep packet inspection, the engines can adversely impact throughput. Please note that an ASA can also do H323, MGCP and SCCP inspection, but I will only focus on SIP, as this protocol is the most likely to traverse a firewall. For instance in a scenario where hosted voice is used. SIP inspection translates the SIP text-based messages, recalculates the content length for the SDP portion of the message, and recalculates the packet length and checksum. It dynamically opens media connections for ports specified in the SDP portion of the SIP message as address/ports on which the endpoint should listen. SIP inspection uses a database that indexes based on CALL_ID/FROM/TO, which it deducts from the SIP payload.



While reading up on SIP inspection, it appears that there are still a number of bugs an caveats that could make its behavior erratic, so by no means is sip inspection a self fulfilling prophecy. And make sure you run the latest software on your appliance.

If you decide NOT to use SIP inspect, you will need to turn it OFF explicitly, because it is on by default.




SDP example:

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
    s=SDP Seminar
    i=A Seminar on the session description protocol
    u=http://www.example.com/seminars/sdp.pdf
    e=j.doe@example.com (Jane Doe)
    c=IN IP4 224.2.17.12/127
    t=2873397496 2873404696
    a=recvonly
    m=audio 49170 RTP/AVP 0
    m=video 51372 RTP/AVP 99
    a=rtpmap:99 h263-1998/90000





More about SIP inspection configuration on the ASA: 


http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_voicevideo.html#wp1148989 


Application level gateways:

http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/iadnat-applvlgw.html#GUID-B17E8F63-49C9-41BC-8D50-572582E31E61

No comments:

Post a Comment