NAT traversal methods

Symmetric media streams
STUN protocol (also: Extended STUN for Symmetric NAT)
rport SIP extension
- See RFC 3581 - defines a new parameter for the Via header field, called "rport", this “allows a client to request that the server send the response back to the source IP address and port from which the request originated.”
OPTIONS request registration refresh - Causes the UA to send traffic out - thus refreshing the NAT bindings
Outgoing INVITE transaction refresh
Traversal using Relay NAT (TURN) - insert a server in the media and signaling path (to deal with Symmetric NATs)
Application Layer Gateway (ALG) - Here the NAT knows about SIP and “does the right thing”
Universal Plug and Play (UPnP) - Use UPnP to control the NAT to open a specific “pinhole” in the firewall
Manual Configuration - manually configure a set of addresses and ports for SIP to use
Tunnel - Tunnel the traffic - inside IPsec, HTTP (i.e., act like HTTP), …

Slide Notes

J. Rosenberg and H. Schulzrinne, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing”, RFC 3581, August 2003 http://www.ietf.org/rfc/rfc3581.txt Links to an external site.

Transcript

[slide371] Well, what could we do? We could think about extending STUN to handle the symmetric case. We could think about putting the port number that we're going to be using in our SIP message. We could think about exchanging option information in the SIP communication. Another approach is called TURN, Traversal Using a Relay NAT. And here the approach is that, well, we know that we can get to that external server, so we can get out through the NAT. What do we do? We simply introduce a proxy there that takes all of our traffic in and then sends it on to the real location. What's the problem with that? How does it scale? Well, we now have to have traffic coming in and we have to have the equal amount of traffic going out for this poor relay. So it's having to send a lot of traffic. And it has to do the reverse also. Because the only way the traffic can get back in is also via the relay. So it's very expensive if you're going to be a relay agent. What about privacy? Yes, the relay is seeing all the media going past in both directions. Now, of course, if we use SRTP, we can encrypt the media, so the relay can't actually see the contents, but it still has to carry all of that traffic. Another approach is we can actually change the NAT. We can make the NAT aware of both SIP and RTP. This is called the application layer gateway. So now it actually does the right thing. It sees the SIP message. It says, oh, I'm going to assign you this external IP address and you're going to have these ports. I'll just manipulate your SDP. Can it do that? To do that, it means that we can't have it inside S/MIME because it has to be readable by the NAT. If it's readable by the NAT, who else is it readable by? Everyone. Right? So there are problems with that. Another approach that some people like is universal plug-and-play. And some of you may have experienced this. Here the approach is, software is allowed to send messages to the firewall saying, hey, open up this port. The bad problem is, UPnP has no security. Any application can send a message to it, and if you've enabled UPnP, it'll open a hole in the [firewall for that] port. So suddenly, your firewall has holes in it. We can, of course, manually configure it, and of course we can tunnel the traffic. So not surprisingly, large numbers of people either use IPSec tunnels, or they use HTTP tunnels. So they actually take all of their multimedia traffic and make it look like HTTP. So, in the back. Why make it look like HTTP? [student's response is inaudible] Not to the users, but to all the networking devices, right? They're used to seeing HTTP traffic going by. Everybody's open holes in their firewalls for HTTP traffic, etc. So it'll sneak through by looking like HTTP traffic. But it's really not HTTP traffic. It's really voice-over-IP traffic. It's just masquerading as HTTP traffic to be able to get through the firewalls. OK.