|
Enabling NATs And Firewalls With SIP
By: Karl Erik Stahl
It is expected that real-time person-to-person communication, like IP
telephony (VoIP), presence, instant messaging, voice, video, and data
collaboration will be the next big step of Internet usage. The Internet standard
for such communication is SIP. To be part of this accelerating SIP user
community, it is important that your network is prepared for it. To have
universal connectivity across the Internet, NATs and Firewalls need to be SIP
capable, which is currently uncommon.
Person-To-Person Communication
Internet started as a defense,
research, and university network. There are two applications that have spread
the Internet usage to almost all companies and persons in the world: e-mail and
Web surfing. However, these applications do not direct real-time communication
between individuals, a capability that is becoming highly useful as more and
more individuals have broadband or a fixed connection to the
Internet.
Therefore, the next big step of Internet usage will include
person-to-person communication such as:
• Voice (of which IP telephony is
but one component);
• Video;
• Presence;
• Instant Messaging;
•
Conferencing with voice, video and data collaboration, and more…
Several
forms of person-to-person communication over the Internet have already been in
use for a few years. However, it is just now, when a general standard has been
established, that these types of applications will become more available and
more widely used. SIP is the Internet standard for such applications and
currently has a strongly accelerating growth.
A powerful driving force
for SIP is that Microsoft has announced that all future real time communication
(RTC) will be based on the SIP standard. Windows Messenger, which can be
downloaded at no charge, already has a SIP mode that provides the user with
telephony, voice, video, presence, and instant messaging. And, Microsoft is set
to launch Greenwich, the RTC services for the Windows 2003 server. Greenwich
includes a SIP server for safe enterprise usage and a programming API, which is
expected to result in numerous SIP applications. With the market impact of
Microsoft, there could easily be tens of millions of SIP users.
IP
TELEPHONY -- JUST ONE PART
SIP is also used for “ordinary telephony,”
i.e., voice with 3 kHz bandwidth and common number dialing, over IP networks.
For this application, the SIP standard is taking over from the earlier H.323,
which is a protocol from the standardisation organisation of the telecom world,
the ITU-T. H.323 has been used to build islands of VoIP, but most often without
interoperability on the IP level between the different operators. Another
protocol is MGCP, or the related H.248/MEGACO, that sometimes is used to control
IP phones on a low level in order for operators to connect these to the old
telephone network, the PSTN.
It should be noted that IP telephony --
where ordinary telephony is emulated over IP -- is only a small part of
person-to-person communication for which SIP was created. Real time
person-to-person communication is expected to be the next big step in Internet
usage following e-mail and Web surfing.
FIREWALLS, NATs,
ROUTERS
When connecting a PC to the Internet, you do not want it to be
accessible for everyone or vulnerable to attacks from hackers. That is
especially important if you are constantly connected, for example via broadband
or a fixed line. A firewall protects the PC by only allowing approved traffic
and by rejecting attacks and illegal data packets.
On a local-area
network (LAN), where several PCs or other equipment is connected, it is common
to have private IP addresses on the LAN and a single common public IP address to
the Internet. That is called NAT (Network Address Translation) and is often an
integrated part of the firewall.
Firewalls and NAT-routers are designed for data traffic that is initiated
from the inside of the private network. If instead the data traffic is initiated
from the outside, and even worse, must reach a specific user on the private
network, serious problems occur.
This is exactly what is happening with person-to-person communication via
SIP. Therefore, it is highly important that all new firewalls and NAT routers
now being installed are designed to support SIP properly and
securely.
A TICKING TIME BOMB?
Most firewalls installed today do not handle
SIP in an adequate way. The problem occurs for all similar protocols (e.g.,
H.323) where a person on a private LAN is to be contacted. Ordinary firewalls
are simply not designed for such data traffic. It is a common misunderstanding
that well known firewalls can be configured to handle SIP traffic, but that is
not the case. One problem is that the media streams (e.g., voice and video
packets) are transferred over dynamically assigned UDP ports that are generally
closed. Another problem is that the SIP clients inside the firewall cannot be
reached by IP addresses since these most often are private and local to the LAN.
It simply does not work, unless there is specific SIP support in the
firewall.
The same applies to routers that are switching the address
space, NATs. NAT routers are used when several users share a common Internet
connection with a single IP address. There are also operators only offering
private IP addresses to their customers.
SIP NAT/FIREWALL
TRAVERSAL
It is of course a fundamental problem that person-to-person
communication does not reach the users on the LANs. Various methods and
equipment have been suggested to solve this problem in a number of situations,
but the most general one is to eliminate the problem where it occurs -- in the
firewall itself. Firewalls including a SIP server (with a SIP proxy and SIP
registrar) that dynamically controls the firewall are currently
available.
A number of firewall vendors are planning to introduce models
including a SIP ALG (Application Layer Gateway). These ALGs usually work at a
lower level than a proxy, adjusting the data packets “on-the-fly.” Cisco is
planning to introduce such ALGs that also handle incoming calls to multiple
users, while other more simple implementations may only support a single SIP
user on the LAN. A common limitation of the ALG architecture is that it cannot
handle secure SIP signaling via TLS (Transport Layer Security). TLS is strongly
recommended by Microsoft to be used with their Greenwich SIP enterprise
solution.
SIP capable firewalls are not more expensive than ordinary
firewalls and should be considered for all new installations of firewalls and
NATs. If not, there is a high risk that even newly installed firewalls and NATs
have to be exchanged in the near future.
Other methods are also proposed
for SIP firewall and NAT traversal.
STUN is a method for getting SIP through existing NATs. It works through
keeping holes open in the NAT by dummy traffic and having the SIP clients
emulate their “looks” from the outside of the protected LAN. STUN will not work
for all NATs and not for real secure firewalls, and may have some scalability
and security issues. The SIP client has to implement STUN and integrate it in
the SIP stack to make it work.
There are also various tunneling
approaches, creating a tunnel through the firewall and then having an ALG in a
central place at the “SIP operator” to cope with the separate address space of
the private LANs and their individual users. Special equipment is therefore
required at the SIP operator and sometimes, special equipment and software are
required on the LAN or in the SIP clients. With this approach, the users get
locked into a specific SIP operator. This approach can normally not handle
complex configurations, such as inter-working between an operator and the
Microsoft Greenwich architecture, where a local SIP server on the LAN is
used.
For home users, Microsoft has suggested an extension to UPnP
(Universal Plug and Play) to allow Windows to control the NAT or firewall.
Several small inexpensive NATs have implemented these UPnP extensions, and thus
allow SIP traversal for Windows Messenger (which is SIP based). However, it is
not secure to allow every PC on the LAN to open the firewall, so UPnP is not
acceptable for a proper firewall that should protect the LAN (In the Greenwich
architecture, even Microsoft recommends that UPnP be disabled for high
security). Another limitation is of course that UPnP control from Windows
clients will not help other SIP products (e.g., SIP phones) to traverse a NAT or
firewall.
CONCLUSION
In all new installations of firewalls and NAT routers,
proper SIP support should be assured to allow the users on the LANs to utilize
real time person to person communication, the next big usage of the Internet. Of
the various methods proposed for firewall and NAT traversal, the most general
and reliable is to solve the problems where it occurs, in the firewall or NAT
itself. By including a SIP proxy and a SIP registrar for controlling the NAT and
firewall, it is possible to handle complex SIP scenarios and to use TLS for
secure and private signaling.
Links:
www.ingate.com
www.jasomi.com
www.hotsip.com
www.draytek.com
www.voip-forum.se
http://www.intoto.com
http://www.koepke.se
Sökmotoroptimering utförd av Resulatmedia
|
