Subject: [SIP] NAT, SOCKS 5 proxies, win proxies

From: "Ashhar Farhan" <[email-masked]>
Date: 8 Feb 2001 13:26:52 -0000

there are several issues that arise out of NAT and socks 5 traversals and there have been several suggestions about overcoming them.

it is very important that we are able to traverse these proxies as most of the enterprises are behind them.

1. most of the schemes and papers submitted on the traversal issues have been suggestions to modify NAT and SOCKS behaviour to fit our shoe. i don't think that this is a workable approach. there are virtually hundreds of NAT and SOCKS implementations all over and if we are aiming at ubiquity, we need to comply with their existing architectures rather than suggesting some of our own. therefore, my suggestion will be to see if it is possible to make SIP work with the existing NAT, SOCKS 5 proxies as well as WinSock proxies.

2. a central problem to all proxy traversals (including that of NAT) is that we can never definitely know the UDP port associate opened by the proxy on behalf of a client behind the proxy server. therefore, the SIP protocol will have to work with an unknown UDP port.

3. The second issue is that RTP too will have to work in conjunction with SIP. therefore, the problem is to correctly identify the UDP port that to be specified in SDP for RTP (and for the purists, even the RTCP).

4. finally, not all clients behind a proxy will be able to open out the 5060 for themselves.

5. a clean approach to these problems is to write an application that co-hosts a state-ful proxy with an RTP relay, that uses the call states maintained within the SIP proxy to correctly route the RTP packets. This application sits on the same machine as the intranet proxy server.

the trouble with this approach is that your network admin has to be a fan of RFC2543 to agree to installing a SIP/RTP proxy that of all the horrors relays UDP packets for all (s)he cares.

6. The other option is to coax SIP itself to work with the current NAT/proxy architectures. Let me propose a scheme which is a little too bitter.

Recommendations:
a) SIP and RTP should be able to work from a single UDP port. By examining the SIP /RTP header, it should be possible to figure out which is which and accordingly process that datagram. this is a pretty radical thing. i am essentially saying the SIP should be able to work as an in-band signalling mechanism.
b)If the port and ip address in Contact does not match the actual IP and port address from which a UDP is received, then there should be mechanism of being able to repy back to the address/port from which the request came in.
c) The UDP port association may die within a minute, therefore, REGISTER has to be more frequent than 5 minutes.
d) In case of NAT, under this scheme, only out going calls will be possible. In order to accept incoming calls, clients behind NAT will have to work through a SIP/RTP proxy that is not necessarily locate on the Intranet.

The most important points to consider here are:
1. single port to be used for SIP and RTP, SIP and RTP streaming to be directed to the same address/port from where the original request/response was received. Thus, SIP should be able to indicate "use the port i am talking to you from" to the other side.
2. in case of using a proxy, the port association maybe different for different out-bound destinations, therfore, the media streaming too has to be proxied from the same port as where the SIP is being proxied.

- farhan@hotfoon.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 09 Feb 2001 23:24:24 -0600

There are a couple of questions to be posed here, in my mind.

Do we develop firewalls to provide "transparent" end to end communications
or do we develop protocols to support firewalls?

Creating application level gateways to facilitate the "transparent"
functionality is a common task that vendors typically perform to increase
the functionality as well as the value of the product.

Creating protocols to support firewalls is worse than a hasty work-around,
IMHO.

More comments below,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ashhar Farhan
> Sent: Thursday, February 08, 2001 7:27 AM
> To: [email-masked]
> Subject: [SIP] NAT, SOCKS 5 proxies, win proxies
>
>
> there are several issues that arise out of NAT and socks 5
> traversals and there have been several suggestions about
> overcoming them.
>
> it is very important that we are able to traverse these
> proxies as most of the enterprises are behind them.
>
> 1. most of the schemes and papers submitted on the traversal
> issues have been suggestions to modify NAT and SOCKS
> behaviour to fit our shoe. i don't think that this is a
> workable approach. there are virtually hundreds of NAT and
> SOCKS implementations all over and if we are aiming at
> ubiquity, we need to comply with their existing architectures
> rather than suggesting some of our own. therefore, my
> suggestion will be to see if it is possible to make SIP work
> with the existing NAT, SOCKS 5 proxies as well as WinSock proxies.
>

NAT and SOCKS wsa developed to support the enterprise in a secure manner and
to provide functional translation when necessary. The very functions they
provide lend themselves for modification, in combination with application
level gateways.

> 2. a central problem to all proxy traversals (including that
> of NAT) is that we can never definitely know the UDP port
> associate opened by the proxy on behalf of a client behind
> the proxy server. therefore, the SIP protocol will have to
> work with an unknown UDP port.
>
We can and do knowthe listening port, as well as the source IP address of
the client. Typically, when dealing with RTP firewalls ALG's are created
aware of the associated RTCP requirements.

> 3. The second issue is that RTP too will have to work in
> conjunction with SIP. therefore, the problem is to correctly
> identify the UDP port that to be specified in SDP for RTP
> (and for the purists, even the RTCP).
>
see above. as for RTCP it is always the next highest odd port number, thus
ther is no need to identify rather pinhole accordingly.

> open out the 5060 for themselves.
This can be defined. Typically if the call is established from within it is
allowed access out by the firewall, if configured to do this.

> 5. a clean approach to these problems is to write an
> application that co-hosts a state-ful proxy with an RTP
> relay, that uses the call states maintained within the SIP
> proxy to correctly route the RTP packets. This application
> sits on the same machine as the intranet proxy server.
>
Now this may be another valid approach to pursue, if nothing more than to
prove vibility.
> the trouble with this approach is that your network admin has
> to be a fan of RFC2543 to agree to installing a SIP/RTP proxy
> that of all the horrors relays UDP packets for all (s)he cares.
>
I believe that if SIP functinality is being considered it is most likely out
of the hands of the administrator to decide if they are a fan of SIP or not.

> 6. The other option is to coax SIP itself to work with the
> current NAT/proxy architectures. Let me propose a scheme
> which is a little too bitter.
This is where I get heartburn. The first and foremost job of a firewall is
to provide a "transparent" end-to-end solution without disrupting the
functionality of the Internet Protocols traversing it. It is setup to
provide protection and accountability, to not re-write of IP protocols.

>
> Recommendations:
> a) SIP and RTP should be able to work from a single UDP port.
> By examining the SIP /RTP header, it should be possible to
> figure out which is which and accordingly process that
> datagram. this is a pretty radical thing. i am essentially
> saying the SIP should be able to work as an in-band
> signalling mechanism.
This would require even more processing by the firewall, because without
parsing the packet just about anything could be entering the network, now we
would be building a method of circumventing security policies through
friewalls. By combining the two protocols we would be developing a stronger
vulnerability for DoS type attacks.

> b)If the port and ip address in Contact does not match the
> actual IP and port address from which a UDP is received, then
> there should be mechanism of being able to repy back to the
> address/port from which the request came in.
This would actually be a good idea for the RTP packets, something that my
associate brought up the other day. If the clients were set up to send and
receive on the same port it could simplify the access permissions on the
firewall.

> c) The UDP port association may die within a minute,
> therefore, REGISTER has to be more frequent than 5 minutes
> d) In case of NAT, under this scheme, only out going calls
> will be possible. In order to accept incoming calls, clients
> behind NAT will have to work through a SIP/RTP proxy that is
> not necessarily locate on the Intranet.
>
This may not be necessary due to the fact that, depending on the NAT method
used, internal clients may be assigned unique "listening" ports on the
outside, or split DNS may be implemented. There are several methods that
could be looked into closely on this point.

> 1. single port to be used for SIP and RTP, SIP and RTP
> streaming to be directed to the same address/port from where
> the original request/response was received. Thus, SIP should
> be able to indicate "use the port i am talking to you from"
> to the other side.
> 2. in case of using a proxy, the port association maybe
> different for different out-bound destinations, therfore, the
> media streaming too has to be proxied from the same port as
> where the SIP is being proxied.
>
> - farhan@hotfoon.
>

This is a solution that may have possibilities as an alternative solution, I
believe that there is a draft that describes something similiar to this SIP
scenario, in combination with MGCP,
ftp://ftp.ietf.org/internet-drafts/draft-thernelius-sip-firewall-solution-00
.txt
\

Christopher A. Martin
SR. Security Integration Engineer
IP Communications Engineering, WorldCom
972-729-4569