One document matched: draft-rosenberg-sip-firewalls-00.txt
Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,D.Drew,H.Schulzrinne
draft-rosenberg-sip-firewalls-00.txt dynamicsoft,Level 3,Columbia U.
February 22, 2000
Expires: July, 2000
Getting SIP through Firewalls and NATs
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document discusses the interaction of the Session Initiation
Protocol (SIP) with with Network Address Translators (NATS) and
firewalls. We show the difficulties in SIP traversing these devices,
and we compare the solutions that might be used.
1 Introduction
The Session Initiation Protocol (SIP) [1] is a general purpose tool
for the initiation, modification, and termination of sessions. As a
core part of its functionality, SIP must carry around the ports, IP
addresses and domain names needed to describe the sessions it
controls. It also causes session traffic to be established (for
example, RTP [2] streams with audio and video), often on dynamic UDP
ports. As such, there are two issues in getting SIP to traverse NATs
J.Rosenberg,D.Drew,H.Schulzrinne [Page 1]
Internet Draft SIP Firewalls February 22, 2000
and firewalls. The first is getting SIP itself through, and the
second is getting the media sessions it initiates through. The latter
is byfar the harder problem.
Section 6.40.1 of RFC 2543 briefly discusses some of these issues,
but not in detail. This document serves to fill that void by
discussing the problems at length, and by proposing numerous
architectural solutions, all of which are already enabled by SIP. In
Section 2, we define what we mean by firewalls and NATs. In Section
3, we discuss the two scenarios in which SIP and firewalls may
interact - internal service, whereby the private network has SIP
deployed, and external service, where it does not. Then, in section
4, we identify the numerous problems in getting SIP to traverse a NAT
or firewall. Section 5 discusses the two configurations that can be
used to address those problems. Section 6 goes through the detailed
SIP processing required in both configurations. Finally, Section 7
discusses what we believe are "non-solutions" to the problem.
2 Definitions
2.1 Firewalls
Our definition of a firewall parallels that defined by N. Freed in
[3]. A firewall as a device with two interfaces - one on the "inside"
and one on the "outside". Its function is generally to protect
devices on the inside from those on the outside, and to sometimes
prevent users on the inside from connecting to, or accessing,
services on the outside.
Firewalls generally come in two flavors. Protocol-end-point firewalls
(also known as application firewalls) act as entities for a
particular set of application layer protocols. This means they
terminate an application layer protocol on one interface, and re-
initiate it on another. Application layer firewalls are generally
required to implement some subset of the protocol. Their function in
this capacity is to implement some safe subset of the protocol,
perform validity checks, and possibly authenticate users at the
application layer.
The second flavor of firewall is a packet filter firewall. These
firewalls do not attempt to terminate application layer protocols.
They operate purely at the IP and UDP/TCP layer. A packet filter
firewall applies a set of rules and policies to packets received on
both interfaces to selectively discard packets. There is no standard
set of rules and policies - they are at the discretion of the
firewall administrator. However, we observe that several policies
tend to be common:
J.Rosenberg,D.Drew,H.Schulzrinne [Page 2]
Internet Draft SIP Firewalls February 22, 2000
o The firewall lets no UDP packets in or out. TCP packets are
not allowed in unless they are destined for specific servers
designated to handle the protocol (for example, the designated
http server can receive TCP packets on port 80). TCP packets
are allowed out, so that users on the inside can connect to
servers on the outside. TCP packets coming in that are
associated with a connection opened from inside the firewall
are also allowed in.
o Same as the previous, except that only specific TCP port
numbers are allowed out; typically this includes SMTP, FTP,
telnet and HTTP.
o Same as the previous, except that only specific connections
with given TCP port numbers from specific hosts are allowed
out. This means that users must connect to HTTP proxies inside
of the firewall, and that SMTP is allowed only from designated
mail relays, for example.
2.2 NATs
A NAT is a logical function, usually embedded in a border router
which straddles a public and private network, that translates IP
address information from packets which traverse the boundary. Its
main application is to hide internal IP addresses of the private
network. This is done to avoid renumbering the private network when
providers change, to allow a large address space inside the private
network to be mapped to a smaller set of addresses on the outside, or
to provide privacy. NATs have become popular tools, especially within
home networks and small corporate enterprises which cannot afford to
purchase large public address spaces.
NATs are stateful devices. They generally require a table to be
established listing the active sessions. For each session, the
particular bindings and translations are stored. Sessions are either
removed explicitly through packets (a TCP FIN, for example, removes
TCP session state), or are timed out after an extended period (as is
always the case for UDP services).
Since NATs operate at the IP and transport layers, they fail when
application layer protocols include IP addresses and ports within
their payloads. In these cases, Application Layer Gateways (ALGs)
must be deployed instead. These devices have awareness of the
particular application, and can translate addresses within message
bodies.
The address mappings provided by NAT can be dynamic or static. In
dynamic mappings, the set of available addresses is stored in a
J.Rosenberg,D.Drew,H.Schulzrinne [Page 3]
Internet Draft SIP Firewalls February 22, 2000
table. As new sessions are established, they are assigned one of
these addresses. When the session terminates, the address is returned
to the free table. In static mappings, there is a one to one
correspondence of internal, private addresses, with external, public
ones.
NATs come in a variety of types, with each type providing different
services and functions. RFC 2663 [4] overviews these different types.
We review them here, briefly, to facilitate subsequent discussion.
The types of NATs are:
Traditional NAT: Also known as outbound NAT, these NATs allow
communications that are initiated from the private network
to the external network. These devices generally translate
the source IP address (and possibly port) of outgoing
packets, and the destination address (and possibly port) of
packets coming back into the private network for the same
session.
Basic NAT: A Basic NAT is a type of traditional NAT. It only
translates IP addresses, not ports.
Network Address Port Translator (NAPT): NATPs also translate the
source port for outgoing packets and destination port for
incoming. This allows multiple sessions to be mapped into a
single IP address by using the source port as a session
identifier. This type of device is extremely useful for
home networks connected to a cable modem or DSL line that
provides a single IP address.
Bi-Directional NAT: Also known as two-way NAT, these devices
allow hosts in the external network to initiate sessions to
hosts on the internal network. This is accomplished by
deploying a DNS ALG which creates address bindings when
external hosts contact DNS for the address of an internal
host.
Twice NAT: Twice NAT is used when the address space within the
private network overlaps with the address space of public
addresses on the external network. With twice NAT, sessions
initiated from inside the private network require
translation of both the source and destination IP
addresses. They also require a DNS ALG. See RFC 2663 [4]
for more details.
A related technology, called Realm Specific IP (RSIP) [5] also allows
a private network with private addresses to communicate with external
J.Rosenberg,D.Drew,H.Schulzrinne [Page 4]
Internet Draft SIP Firewalls February 22, 2000
hosts. Unlike NAT, RSIP requires clients to be aware of the differing
address realms internally and externally. Whenever they wish to
contact and external host, clients connect to an RSIP server to
obtain an address within the external name space.
In the discussions which follow, we do not consider twice NAT or
Realm Specific IP.
3 Scenarios with SIP
A SIP network consists of proxies, redirect servers, registration
servers and user agents. For the purposes of discussion, we
collectively call redirect, registration and proxy servers "SIP
servers". The distinction between the three is not particularly
relevant for purposes of the firewall discussion. In order to receive
calls, a user must generally be a customer of a "SIP Provider"; this
SIP provider allows the user to register with a SIP server, and
receive incoming calls through the SIP server. Outgoing calls may
also be made through this server, but it is possible for a user to
make outgoing calls without a SIP provider. A user can even receive
calls without a SIP provider, but this requires the calling party to
know the IP address or hostname of the called party. This knowledge
is unlikely in real deployments.
A SIP provider is not necessarily the same as the network access
provider for a particular user. In fact, for residential customers,
there is a strong trend towards the separation of access services
(provided through traditional ISPs like MCI and AT&T Worldnet), and
application services, such as email, web, and instant messaging,
provided by application service providers (ASPs) like Yahoo and AOL
(of course AOL is also an ISP). VoIP service, enabled by SIP, is
another example of an application an ASP might provide.
The problem of getting SIP through firewalls and NATs generally only
occurs when the user's access provider is a corporate network.
Residential ISPs almost never deploy firewalls, nor do universities
[1] which follow, we assume that the access provider is a corporate
network.
Given this, there are two configurations of interest when getting SIP
through a firewall. The first is when the user wishes to use SIP
services from some ASP, independently of whether their corporate
network or ISP is providing SIP services. We call this first scenario
external service. The second scenario is when the corporate network
_________________________
[1] The authors strongly recommend changing ISPs if
your residential ISP has a firewall.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 5]
Internet Draft SIP Firewalls February 22, 2000
is also acting as a SIP ASP (we call this internal service).
3.1 External Service
The configuration for external service is shown in Figure 1.
|
|
+-----+ +----+ +-----+
| SIP | | FW | | SIP |
| UA | +----+ | Svr |
+-----+ | +-----+
|
inside | outside
|
Network X | Network Y
Figure 1
This scenario arises when a user is connected through some network X
(usually a corporate intranet), and wishes to use SIP services from
some SIP ASP Y, external to X, and X is using a firewall. Generally,
firewalls are deployed in corporate enterprises, and enterprise users
tend not to make use of external ASPs for services. Rather, these
services are available inside of the firewall, so that they can be
managed by the enterprise. This configuration therefore occurs in
cases where the enterprise has not deployed the service, but
employees of the enterprise wish to make use of it through external
providers. It also occurs when individual users, for non-business
reasons, wish to access service from an outside provider even though
it is provided as a service inside the enterprise.
As it turns out, providing SIP services in this scenario, without
adding SIP awareness to the firewall, is nearly impossible (without
seriously hacking protocols, at least) with any but the most
forgiving firewall. The reason is not SIP itself, but the media
sessions which are initiated by SIP. Unless the firewall is willing
to act as a proxy for external services (see Section 5.1), the
firewall is not likely to let the media in or out of the firewall.
This scenario is best solved using a proxy co-located with a
firewall, described below in Section 5.1.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 6]
Internet Draft SIP Firewalls February 22, 2000
3.2 Internal Service
The second configuration occurs when SIP is deployed within the
corporate network. In this case, the SIP servers for the user exist
on the inside of the firewall, and other network servers belonging to
other providers are on the other side. This configuration is shown in
Figure 2.
|
+-----+ +-----+ +----+ +-----+
| SIP | | SIP | | FW | | SIP |
| UA | | Svr | +----+ | Svr |
+-----+ +-----+ | +-----+
|
inside | outside
|
Network X | Network Y
Figure 2
This scenario can be handled with either a proxy co-located with the
firewall/NAT, or with a firewall/NAT controlling proxy.
4 Problems in Traversing Firewalls and NATs
Numerous issues need to be considering when using SIP through a
firewall or NAT. Both devices come in two general types - network
layer or application layer. Network layer devices do not look at the
application protocol. Their rules and processing are purely based on
IP and/or UDP/TCP processing. Application layer devices operate based
on detailed knowledge of the application layer protocol. Many of the
issues in getting application layer protocols to traverse NATs are
discussed in [6]. This document refers to application layer NAT
devices as Application Layer Gateways, or ALGs.
Based on the guidelines in [6], there are numerous problems in
getting SIP through a NAT without an ALG, many of which also pertain
to firewalls.
These issues are discussed in the subsections which follow.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 7]
Internet Draft SIP Firewalls February 22, 2000
4.1 Session Bundling
The NAT friendly application design guidelines [6] recommends against
protocols which provide session bundling; that is, they use a single
session as a control channel for other sessions.
SIP, fundamentally, is a control channel for establishing other
sessions (namely, the media sessions). These kinds of protocols (of
which FTP is another example) cause problems for NATs, since the
addresses for the established sessions are in the body of the
application layer messages.
When used with SDP [7], SIP messages carry the IP addresses and ports
that will be used for the media sessions. There may be multiple media
sessions within a particular SIP call. Since SDP carries IP addresses
and not host names, the external UA will send media to an IP address
that is not globally routable. Therefore, media will not flow in the
direction of external to internal.
A nearly identical problem exists for firewalls. When a user inside
the firewall sends media to an address outside the firewall, it will
be dropped by the firewall unless a rule is established to allow it
to traverse.
Unfortunately, SIP does not mandate that SDP be used exclusively
(although all implementations must support it). Future session
description formats may be defined.
4.2 IP addresses within Packets
Numerous SIP headers contain fields that can carry either IP
addresses or domain names. These can cause problems for both
firewalls and NATs.
The Contact header in SIP requests and responses contains a SIP URL.
SIP URLs can contain an IP address or a hostname. This address is
used for signaling in the reverse direction which is part of the same
SIP call. In the case of a NAT, if an IP address is present, the
signaling will not be routed correctly from the external network to
the private network. If a hostname is present, standard DNS ALGs can
provide a translated address through the DNS query, avoiding the need
for translation within SIP. If a firewall is in use rather than a
NAT, the signaling may not traverse if a rule is not established in
the firewall to allow the SIP messages through. In the case of
internally provided SIP services, it is easy to configure such a
rule. This rule would allow all UDP and TCP traffic on port 5060 to
the IP address(es) of the proxies. These proxies form a "buffering
zone", performing various checks and validations on the SIP messages,
J.Rosenberg,D.Drew,H.Schulzrinne [Page 8]
Internet Draft SIP Firewalls February 22, 2000
and acting as a buffer for DoS attacks. However, in the case of
external services, the firewall rule cannot include a destination IP
address. This significantly worsens the protection provided.
The Record-Route and Route headers in SIP requests have the same
issues as the Contact header. When present, they indicate routing
instructions for subsequent messaging. Should these include SIP URLs
that contain IP addresses from the private network, signaling will
not be routed correctly from the external network to the private
network in the case of a NAT. In the case of a firewall, rules
allowing traffic to be sent to the proxy must be installed.
The Request URI in SIP requests contains a SIP URL. This may contain
an IP address. For calls made from the internal network to outside
the network, there is no problem, as this address refers to an
external host with a public address [2] external network internally,
the request URI will usually not contain an IP address (most users do
not publish IP addresses within SIP URLs). If an IP address were
present, it would have to have been the result of a domain name
lookup external to the network. If a NAT were in use, a DNS ALG will
allow queries for the IP address of a host within the network to
return a globally routable IP address. This implies that special
processing, beyond DNS ALGs, is not needed for request URI handling.
Similarly, a firewall will need to be configured to allow SIP traffic
destined for a proxy internal to the network, in the case of
internally provided service.
The Via headers in SIP requests contain IP addresses. These addresses
are used to forward responses. Fortunately, SIP supports receiver
tagged via fields. If a request arrives from a host, and the source
IP address in the packet containing the request does not match the
address in the Via field, the proxy tags the Via field with the
source IP address. This address is used to send responses. This
feature means that the Via field does not need to be translated
through NATs. However, the responses are sent to the port in the Via
field, *not* the source port of the message. This means that changes
to the port numbers, made by NAPTs, will cause responses to be
misrouted. To traverse a firewall, it is configured with a rule that
allows SIP traffic in destined for the proxy on the inside of the
network, as in the cases above.
The Call-ID in a SIP request is required to be globally unique. It is
constructed by appending some identifier to the IP address or
hostname of the machine where the call originated. This address
_________________________
[2] We do observe that this is a potential problem
for twice NAT, however
J.Rosenberg,D.Drew,H.Schulzrinne [Page 9]
Internet Draft SIP Firewalls February 22, 2000
itself is never needed for message routing. However, if the internal
network is using one of the three private address spaces (10/8,
172.16/12 or 192.168/16), it is possible that the Call-ID won't be
globally unique. This is because hosts within other private networks
might use the same IP addresses. Should two users in two different
private networks, both using the same private address, choose the
same identifier, and then call the same user, incorrect call handling
will take place. The SIP specification does mandate that if the host
portion of the Call-ID is not globally routable, the local
indentifier must be globally unique, so this should hopefully never
happen.
The To and From fields in SIP requests contain SIP URLs, which may
contain IP addresses. If a Contact header is not present in the
INVITE from a host in the private network, the From field will be
used for routing subsequent requests from the called party. If the
URL in the From field contains an IP address, these will not be
routed properly in the case of NAT. However, most implementations do
place a Contact header in the INVITE. Furthermore, since the From and
To fields are used for identification of the parties, they generally
contain domain names and not IP addresses. Of course, the protocol
does not guarantee this.
4.3 Lifetime Issues
When an INVITE message passes through a NAT (and an address binding
is established for it) or through a firewall (and rules are created
for the media streams), state is established. This state must
eventually be cleaned up. For applications that run over TCP, closure
of the TCP connection is usually a good indicator of the termination
of the application. However, SIP can run over UDP. Thus,
determination of when it is safe to destroy state must be done
through application level awareness. Unfortunately, an INVITE
transaction can last a very long time, as can a call. As a result, it
is possible that some state is destroyed before the transaction
and/or call actually completes.
In the case of a NAT, the most problematic case for SIP itself (as
opposed to the media session) is the IP addresses in the Via field.
The received-by parameter in the Via header is populated with the
address that will be used to send the response. This address is only
valid for the lifetime of the binding. If the binding should expire
before the response arrives, the transaction will fail. However,
INVITE transactions do not last for more than a minute in the general
case. A sufficiently long timeout should ensure this is not a
problem.
SIP calls, however, can be for a very long duration (on the order of
J.Rosenberg,D.Drew,H.Schulzrinne [Page 10]
Internet Draft SIP Firewalls February 22, 2000
hours). Using a set timeout is likely to cause the binding to be lost
before the call is complete. If this happens, the name to address
bindings obtained from the DNS ALG will be stale. If the DNS ALG
returns addresses with very small TTLs, this problem disappears. In
that case, the usage of UDP is not problematic; IP address bindings
can be re-established for each request (assuming all fields in the
SIP message are domain names and not IP addresses).
For the media session, if a NAT times out the address binding, or a
firewall removes the rule that allows the media to pass, but the call
is not over, the media will not flow and the call will appear as some
kind of defect to the user.
SIP can also run over TCP. NATs assume that the IP address bindings
have a lifetime equal to that of the TCP connection. In SIP, clients
are allowed (and most do) to close the TCP connection to the server
once the transaction is complete, even though the call is still in
progress. This means that the first problem identified above, whereby
the receiver tagged Via fields become invalid if the binding changes
before the transaction completes, is avoided with TCP. However, the
NAT must be application aware and know not to time out the bindings
until the call is actually over.
4.4 Multicast
D.Senie [6] indicates that multicast does not run well through NAT,
and an ALG is required. SIP can make use of multicast for both
registrations (its most useful application) and INVITE messages.
Generally these run on a well known multicast address, 224.0.1.75.
4.5 Security
SIP is secured through both hop-by-hop mechanisms and end-to-end
mechanisms. RFC2543 does not mandate a particular hop-by-hop security
mechanism; both IPSec and TLS are mentioned. As pointed out in [6],
IPSec does not traverse NATs, and TLS is recommended. Therefore,
implementations using IPSec for SIP will fail, with or without an
ALG. IPSec for SIP through a firewall should work, however, the
firewall will not be able to determine the ports used for the media,
in order to open up holes in the firewall.
The end-to-end mechanisms in SIP provide both authentication and
encryption. Both are problematic for NATs, including ALGs. The
authentication mechanisms are not a problem for firewalls, but the
end to end encryption is a problem for NAT.
The authentication mechanisms, in particular PGP, sign several fields
of the SIP request, including the body. The body, usually SDP,
J.Rosenberg,D.Drew,H.Schulzrinne [Page 11]
Internet Draft SIP Firewalls February 22, 2000
contains the IP addresses and ports used for the media session. A NAT
acting as an ALG will need to change the IP addresses in the SDP.
Unfortunately, this will cause the signature to become invalid, and
the message to be rejected.
As a fix for this, SIP allows for messages to be resigned. The re-
signing party removes the Authorization and Proxy-Authorization
headers, resigns them, resulting in new headers, and inserts these
into the message. The re-signer then includes their identifier (as a
URI) which can be used to obtain the re-signer's certificate. A NAT
handling outgoing requests should generally resign the message using
the key of the organization itself. This not only solves the
authentication problem; it also makes signature verification more
realistic. It's much more likely an individual will have access to
the certificate for an organization than an individual within that
organization.
However, signatures on responses to outgoing requests are very
problematic. As responses are forwarded to the internal network by
the NAT ALG, the headers may need to be replaced. This would be
necessary if the From field or Record-Route in the request was
replaced, in which case the original version needs to be put back in
the response. Though the NAT ALG could resign the response, this
doesn't make sense, since it is not from the same organization as the
originator of the response.
End-to-end encryption is much more problematic. It will cause several
key headers and the body to be hidden from intermediate systems,
including the SIP NAT ALG or firewall. This means the IP addresses
cannot be determined or re-written, and holes in firewalls cannot be
opened.
As a result, the use of end-to-end encryption means that
SIP will fail through any type of NAT or firewall.
4.6 Conclusion
The conclusion of the analysis of this section is that SIP has
several difficulties traversing NATs and firewalls. Most paramount
among them is the presence of IP addresses for the media session in
the bodies. Additionally, the possibility of IP addresses in the
Contact, To, From, Record-Route and Route headers also means an ALG
is needed to guarantee operation.
5 Architectural Solutions
As a direct of the discussion in the previous section, there are two
J.Rosenberg,D.Drew,H.Schulzrinne [Page 12]
Internet Draft SIP Firewalls February 22, 2000
solutions possible for allowing SIP through firewalls and NATs. One
is to use an application layer firewall/NAT which understands SIP,
and the other is to use a packet filtering firewall/NAT under the
control of a proxy.
5.1 Colocation of Proxy and Firewall/NAT
In this solution the firewall/NAT actually is co-located with a SIP
proxy. This is shown in Figure 3.
|
+--------+
| +----+ | +-----+
| | FW | | | Net |
| | NAT| | | SIP |
| +----+ | | Svr |
| SIP | +-----+
| PROXY |
+--------+
|
+-----+ +-------+ |
+-----+| +-------+| |
+-----+|| +-------+|| |
| SIP ||| | SIP ||| |
| UAs || |Proxies|| |
+-----+ +-------+ |
|
INSIDE | OUTSIDE
|
Network X | Network Y
Figure 3
Since the proxy and firewall/NAT are colocated, the proxy can have
direct control over the firewall/NAT through some kind of internal
API. This configuration is advantageous in that it need not rely on
the existence of SIP servers within the network. Although Figure 3
shows proxies inside, the solution allows SIP to work when such
proxies do not exist. This makes it the ideal solution for the
J.Rosenberg,D.Drew,H.Schulzrinne [Page 13]
Internet Draft SIP Firewalls February 22, 2000
external services configuration. A corporate intranet can purchase a
SIP enabled firewall, turn on the SIP support, and corporate
employees can make use of external SIP services without deploying
them internally, while still securing the internal network.
5.2 Firewall/NAT Controlling Proxy
The solution of Section 5.1 has the drawback of burdening the
firewall with an application layer protocol. As more applications get
deployed, the firewall/NAT needs to become aware of all of them. This
eventually may become difficult to manage and difficult to support
within an enterprise network.
As an alternative solution, the proxy and firewall/NAT can be
separated, but a control protocol or API can be used between them.
This protocol would allow the proxy to instruct a firewall to open
and close holes for the media stream. It would allow the proxy to
query a NAT for address bindings. This allows application layer
information to be externalized from the NAT and firewall. This
architecture is shown in Figure 4.
|
............... |
. +-----+ . +----+ +-----+
. |Proxy|xxxxxxxxxxxxxxxx| FW | | Net |
. | | . control | NAT| | SIP |
. +-----+ . protocol +----+ | Svr |
. . | +-----+
. Buffer Zone . |
............... |
|
+-----+ +-------+ |
+-----+| +-------+| |
+-----+|| +-------+|| |
| SIP ||| | SIP ||| |
| UAs || |Proxies|| |
+-----+ +-------+ |
|
INSIDE | OUTSIDE
Figure 4
J.Rosenberg,D.Drew,H.Schulzrinne [Page 14]
Internet Draft SIP Firewalls February 22, 2000
By placing the application layer awareness in the proxy rather than
firewall NAT, several advantages are obtained:
o Since the NAT/firewall is focused on a single task - network
layer forwarding and filtering, its performance can be
optimized. It is not burdened with application layer
processing.
o As new applications are deployed, the NAT/firewall does not
need to be upgraded. The application servers can control the
NAT/firewall as well.
This configuration also requires the firewall to have holes opened
permanently for the SIP messaging itself from the proxy out, and from
the outside in. This can be accomplished by configuring the proxies
with a rule which only allows UDP and TCP on port 5060 to and from
the IP address of the proxy (or proxies) inside the firewall. Such a
configuration guarantees that the proxy inside the firewall is always
the first point of contact for incoming messaging, and the last point
of contact for SIP messages before they leave the network. These
proxies are effectively part of a "Buffer Zone (BZ)" which exists on
the inside of the network, granting access to users and services
within.
In the case of a NAT, the proxy in the BZ will need to reachable from
outside. This is accomplished by using a DNS ALG that gives out
globally routable IP addresses for the proxy when queries for its
domain name are given. It is desirable for these addresses to be
based on long lived bindings.
The usage of a SIP BZ offers numerous advantages. First, it is a
protection against DoS attacks involving flooding of messages. The BZ
ensures that all SIP messages hit specially engineered proxy servers,
rather than any machine within the network. These proxies can be
configured with load checkers which cause error handling to take
place when call volumes to any particular host within the network
become too high. This error handling might involve rejecting all
requests using a stateless mode. This prevents build up of state
within the proxy and also protects the internal network.
An additional advantage of the BZ is protection against spam. Certain
URLs, known to be from malicious callers, can be rejected outright
without bothering internal users at all.
Finally, the BZ allows for message validation. Overly long requests
can be rejected. Messages with mailicous Java applets can be detected
and rejected. Poorly formed requests can be rejected, particularly
ones with very long values for certain fields.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 15]
Internet Draft SIP Firewalls February 22, 2000
Clearly, this solution only applies when SIP servers are deployed
within the corporate network.
Several possibilities exist for the control protocol between the
proxies and a firewall. One is SOCKS, specified in RFC 1928 [8] which
is engineered for exactly this purpose. We know of no equivalent for
NAT control, however.
An additional level of scalability can be achieved by introducing an
additional server, which we call a session manager. This device
actually stores the call state and other information needed by the
proxy servers. In this way, numerous proxy servers can be deployed
rather than one. They access the session manager when they need
access to call state. The precise way in which this is done requires
further investigation.
6 Proxy/Firewall/NAT Operation
Independently of whether the proxy and firewall/NAT are co-resident,
there are specific goals to be achieved by the system:
1. Ensure that only authorized users inside the network may
make outgoing calls.
2. Ensure that legitimate users outside the network may make
calls into the network.
3. Ensure that calls make from outside the network to inside
are not malicious or harmful to systems inside the network.
4. Ensure that any bodies carried in SIP messages (such as
Java applets or Word documents) are virus free and not
harmful to the system.
5. Ensure that media streams for the call are allowed to flow
in and out of the network for the duration of the call
only.
6. Ensure that users cannot be contacted without having SIP
requests routed through the firewall.
The operational procedures required to meet these objectives are
outlined in the subsections below.
6.1 Outgoing Calls
When a user makes a call, the proxy acts as a local outbound proxy.
This can be accomplished by explicitly or automatically configuring
J.Rosenberg,D.Drew,H.Schulzrinne [Page 16]
Internet Draft SIP Firewalls February 22, 2000
(through DHCP [9], SLP [10] or ACAP [11]) the local outbound proxy in
user agents within the enterprise. This only works when SIP services
are provided internally. Alternatively, when SIP services are
external, the firewall/proxy can intercept SIP requests not
explicitly destined for the firewall/proxy. Doing so requires care.
The request needs to still be delivered to the server the user agent
sent the request to. To accomplish this, the proxy/firewall notes the
destination IP address in the request when the request is captured.
When the request is forwarded, rather than determining the next hop
server by looking up the host name in the request URI (the normal
procedure if the request was actually sent directly to the
proxy/firewall), the request is sent to the IP address that was noted
previously.
When an INVITE is received by the proxy from a host within the
private network, and SIP service exists internally, it authenticates
the caller by sending a 407 response. The UAC resubmits the request.
If the credentials are valid, the firewall/proxy can check its policy
database to determine if the user is authorized to make outgoing
calls, and if so, forward the request based on normal SIP procedures.
If SIP services are external, no authentication is performed; the
request is simply forwarded by the proxy/firewall. In either case,
the proxy also adds the Record-Route header. The proxy also remembers
the SDP in the INVITE, and extracts the port numbers and IP addresses
for each of the media streams.
If NAT is in use, additional operations are performed by the proxy.
The IP addresses and ports in the SDP are removed. A binding is
created, mapping these address/ports to globally routed ones. This
binding is created locally if the NAT and proxy are co-resident.
Otherwise, some kind of query is needed to allow the proxy to ask the
NAT for a binding. Assuming this is done, the globally routed
addresses are inserted into the SDP. This may require the request to
be resigned. If the Contact, From, or Record-Route headers contain IP
addresses, bindings are created for those addresses as well (these
may end up using the same bindings as the IP addresses in the SDP,
but not necessarily. As an example, for a megaco [12] decomposed
gateway, they will not), and the globally routed ones are placed into
the message. If these fields contain hostnames, bindings of those
hostnames to globally routed addresses must be done, and a DNS ALG
configured to return those addresses when queries are made. The proxy
inserts a Via header containing a globally routable IP address and
port. If the From, Contact or Record-Route headers were replaced,
these must be stored by the proxy. They must be reinserted into the
response.
When a response to the INVITE arrives from the external network, it
goes through the firewall or NAT (assuming the previous steps have
J.Rosenberg,D.Drew,H.Schulzrinne [Page 17]
Internet Draft SIP Firewalls February 22, 2000
been followed) and is examined by the proxy. If it is a 200 OK with
SDP, the proxy analyzes the SDP, comparing with the one from the
INVITE. For all media streams which were accepted by the UAS (the
connection address is nonzero), the proxy notes the IP address and
port indicated in the SDP in both the INVITE and 200 OK. The response
is then forwarded.
The proxy also opens holes in the firewall, if one is in use, to let
the media traffic in and out on the ports and addresses obtained from
the SDP in the INVITE and 200 OK. In particular, if the INVITE
contained address A and port B for some media stream, and the 200 OK
contained address X and port Y for the same media stream, the
proxy/firewall allows UDP destined for address X and port Y from the
inside to the outside of the firewall. Similarly, it allows UDP
traffic from the outside to the inside if it is destined for address
A and port B. The firewall may further restrict the source addresses;
for example, allowing UDP traffic from the outside to the inside if
its destined for address A and port B and is from address X. However,
this assumes that the called party is using the same machine and
interface to both send and receive media. This assumption is not
valid for multi-homed hosts, or for multimedia systems with different
components running on different hosts. Recent discussions on the SIP
mailing list have proposed adding a source address to SDP in order to
construct more restrictive firewall rules.
In the case of a NAT, the original From, Contact and Record-Route
headers are placed back into the response (note the Record-Route
headers placed back will only replace a subset of those in the
response). Nothing is done to the SDP for NAT. Replacing headers will
invalidate signatures and the Authorization header must be removed,
if present.
Recent extensions to SIP allow for "early media" to be opened by
including SDP in provisional responses [13] which are sent reliably
[14]. As a result, the proxy will also need to look for these
responses. The mechanism used to transmit these reliably is based on
a new PRACK request. This request can also contain SDP. The firewalls
will also need to look for these messages, extract the ports and IP
addresses, and open holes based on them or create bindings for them,
just as was done for the INVITE. PRACK messages are forwarded based
on Record-Route headers returned in provisional responses; this means
that the proxy will receive the PRACK messages so long as it inserted
the Record-Route in the outgoing INVITE request (which it must do).
The proxy can use proxy authentication to verify the authenticity of
the PRACK messages as well, if SIP services exist internally.
As a final complication, SIP allows for the INVITE to contain no
media information. Rather, the 200 OK contains the receive
J.Rosenberg,D.Drew,H.Schulzrinne [Page 18]
Internet Draft SIP Firewalls February 22, 2000
capabilities of the called party, and the ACK contains a trimmed
subset, representing the capabilities and accepted media streams of
the calling party. This requires the proxy to open the holes for
media (or create bindings for them) on receipt of the ACK, rather
than on receipt of the 200 OK as discussed above.
6.2 Incoming Calls
The initial processing for incoming calls (from the external network
to the internal network) depends on whether SIP services exist
internally or not.
6.2.1 Incoming Calls for Internal Services
The scenario for incoming calls is largely the reverse of the
scenario for outgoing calls. The name space and DNS records must be
configured so that all incoming requests for users within the private
network arrive at the proxy. If the company is named foo.com, this
implies that the SIP URLs published externally for employees of
foo.com should be of the form sip:user@foo.com. DNS records must be
configured so that a lookup of foo.com (using SRV and/or A records)
results in the address of the firewall proxy (or proxies, when there
are more than one to support load balancing and backups). SIP URLs
are "published externally" through their placement on business cards
and personal communications; managing this is outside the scope of
this document. However, SIP URL's are also effectively "published"
automatically through SIP REGISTER messages. Therefore, users must be
prevented from sending external registrations to other servers
listing Contact addresses that do not correspond to the address of
the proxy/firewall. This is discussed in more detail in Section 6.7.
Assuming the naming and records have been managed properly, an INVITE
arrives at the proxy when a call is to be set up to a user inside the
network. In the case of NAT, the NAT will have done nothing but
rewrite the destination IP address of the packet to the private
address of the proxy. All of the SIP level details regarding NAT
processing are done in the proxy. Proxy authentication is probably
not viable for incoming calls. This is because the domain of the
caller is not the same as the domain of the called party. There is
unlike to exist any kind of shared secrets between a server in one
domain and a user in another. Widespread deployment of a PKI will
enable proxy authentication for incoming calls, but it does not exist
at the moment.
6.2.2 Incoming Calls for External SIP Service
The scenario for incoming calls is very similar to outgoing calls.
The external SIP server will receive requests destined for the user
J.Rosenberg,D.Drew,H.Schulzrinne [Page 19]
Internet Draft SIP Firewalls February 22, 2000
inside the firewall/NAT. It sends those requests to the user
directly. These requests are intercepted by the firewall/NAT, which
passes them to the proxy component.
6.2.3 Finishing Incoming Call Setup
The proxy can validate the message, and make sure it is not malicious
in nature (for example, ensure it has bodies that are not too long).
Once validated, it notes the port numbers and IP addresses in the SDP
in the INVITE, but does not open holes in the firewall at this time,
nor are address bindings created for the media streams in the case of
a NAT. The proxy adds the Record-Route header, which must contain a
globally routable IP address for the proxy. Location services are
invoked (possibly resulting in next hops with private IP addresses).
A NAT will not need to modify any of the fields of the message, as
they should all contain globally routable addresses, including the To
and Request-URI. The request is then forwarded.
When a 200 OK response (or any provisional response with SDP) arrives
from inside, the proxy examines the SDP and notes the IP addresses
and ports for each media session. If the 200 OK is signed, the
proxy/firewall can verify the signature as an additional security
mechanism.
In the case of a firewall, the 200 OK is forwarded as is normally
done. At this point, the proxy opens up holes in the firewall for
traffic to and from the ports and addresses in the SDP to enable
media in both directions.
In the case of NAT, the proxy requests a binding for the private
addresses in the SDP in the response. The globally routable addresses
obtained from the binding request are placed into the SDP. Note that
it is OK for the response to contain Contact or Record-Route headers
with private addresses or domain names, so long as the proxy itself
is record-routing. Thats because these addresses or names will only
be needed by the proxy or other servers from within the private
network.
When the ACK arrives for the 200 OK, it will pass through the
firewall/NAT, and arrive at the proxy. If this ACK contains SDP, the
proxy should ensure that the IP address and port have not changed
from the INVITE. If they have, new holes in the firewall need to be
opened. No special processing is required for the NAT. The ACK is
then forwarded.
6.3 Forwarded calls
An interesting case, depicted in Figure 5, arises when a user outside
J.Rosenberg,D.Drew,H.Schulzrinne [Page 20]
Internet Draft SIP Firewalls February 22, 2000
the network (user A), calls a user inside the network (user B), but
this call is forwarded to a user outside the network (user C). When
the INVITE from A arrives at the proxy, the procedures for incoming
calls apply. However, when the INVITE hits the forwarding logic for
user B (present in either B's software or in a proxy server within
the network) B, and is forwarded out to user C, hitting the
firewall/proxy again [3] , different rules apply than the ones
outlined in Section 6.1 for outgoing calls. Although this case
appears like an outgoing call (INVITE message from within the network
to outside), it is not. The difference is that the From field does
not correspond to a user within the corporate network.
+--------+
| | |
| | A |
| / | |
| / | |
| / +--------+
| /
| /
+------+ +------+ +------+ /
| |<---| |<---| |</
| B | |Proxy | |FW/NAT|
| |--->| | -->| |
+------+ +------+ +------+
| INV C
|
|
| +--------+
| | |
| | C |
| > | |
| | |
| +--------+
|
|
Inside | Outside
|
_________________________
[3] The astute reader will note that this case
appears to be a loop according to RFC2543, although it
really isn't. This problem has been identified and a
fix has been drafted for the next version of SIP
J.Rosenberg,D.Drew,H.Schulzrinne [Page 21]
Internet Draft SIP Firewalls February 22, 2000
Figure 5
Specifically, unlike outgoing calls, proxy authentication should not
take place for internal service. The call originator is not inside
the network. In addition, the proxy does not need to record route, or
even be stateful. No holes in the firewall need to be opened for the
call, since the media will flow directly between user A and user C
(assuming the call is accepted), neither of which is within the
enterprise. Neither do address bindings need to be established. It is
our recommendation that proxies act statelessly in this
configuration.
6.4 Termination
A call is terminated with a BYE message. If the BYE comes from the
private network, the proxy can use proxy authentication to
authenticate the originator of the request if the service is
internal. However, the holes in the firewall are not closed yet, and
NAT address bindings are not released. If the original INVITE was
generated by a host within the private network, and the From field
was replaced as it contained a local address, the global address must
be replaced in the BYE. This is identical to the procedure for the
INVITE itself, and applies to re-INVITES too. When a 200 OK arrives,
the proxy closes the holes in the firewall and releases any address
bindings in use by the NAT.
If the BYE comes from the external network, the NAT must replace the
To field if the From field was modified in the original INVITE from
the private network. When the 200 OK arrives for the BYE, the proxy
can verify the signature on the 200 OK (assuming mutual
authentication was used).
It is preferable to close the holes in the firewall and release
address bindings on the response to the BYE, rather than the BYE
itself. In unusual circumstances, the BYE might be rejected and the
call remains established. The 200 OK confirms termination of the
call.
6.5 Re-INVITEs
SIP allows parameters of the session to be changed through re-
INVITEs. These re-INVITEs can add new media sessions to the call, in
which case new holes need to be opened in the firewall, and new
address bindings may need to be created. This process follows the
procedure for original call setup. Similarly, re-INVITEs can remove
J.Rosenberg,D.Drew,H.Schulzrinne [Page 22]
Internet Draft SIP Firewalls February 22, 2000
media sessions from the call, meaning the holes in the firewall need
to be closed and bindings released.
The procedure for opening or closing holes or establishing bindings
for re-INVITEs is identical to opening holes for new INVITEs. In
fact, since SIP INVITE messages carry the entire session state, the
proxy can simply close all the holes associated with the original
INVITE, and re-open ones for this INVITE as if it were the first. For
NATs, this will not work. If a media stream is removed as a result of
a re-INVITE, that address binding, and that one alone, is released.
6.6 Session Timer
As described above, the proxy relies on the SIP BYE message to know
when it is safe to close a hole in the firewall or release an address
binding in the NAT. However, relying on these messages completely can
be problematic for several reasons:
o End system crashes may result in calls ending without BYE
being sent.
o Malicious users may never send BYE in order to attack a proxy.
o Poor implementations may not process Record-Route and thus the
proxy/firewall may never see a BYE.
o Network failures may cause a BYE that is sent to never reach
the proxy.
The solution to this is for the proxy to make use of the session
timer extension for SIP [15]. This will allow the proxy to receive
keepalives for the call. If the keepalives stop arriving, the proxy
can close the holes in the firewall or release the NAT address
bindings.
6.7 Registrations
Special consideration must be given to registrations going into, and
leaving, the network in the case of internal service. There are
legitimate reasons for both to occur. For external service, REGISTER
messages are intercepted and then forwarded towards the final
destination without any local processing (except to determine that
this is a REGISTER message).
In the case of a NAT, note that address bindings are never created
upon receipt of registrations. Rather, they are triggered when an
INVITE arrives that makes use of that registration.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 23]
Internet Draft SIP Firewalls February 22, 2000
6.7.1 Outgoing Registrations
Registrations leave the network (i.e., flow from inside to outside)
when a user on the inside registers with some external server. A
legitimate application of this is when an employee is travelling on
business, and has instructed their SIP server within the corporate
network to forward all calls to the main server for the facility the
employee is visiting (say, bar.com). This registration does not leave
the network. However, in order to receive calls at bar.com, the
employee may need to instruct bar.com to forward calls to the
specific building he is visiting, bldg12.bar.com. This will require a
registration sent to the server at bar.com, indicating bldg12.bar.com
in the registration. This REGISTER message is sent externally.
An additional case where registrations may leave the network is if a
customer has an external SIP forwarding service, perhaps from an
organization like acm.org, and they wish to have all calls for them
forwarded to work. This requires a registration to be sent from
inside the firewall, to the acm.org server, listing their work URL,
sip:user@foo.com, in the Contact header.
In all cases, the registrations must be such that calls forwarded to
the private will always reach the internal proxy that is controlling
the firewall or NAT. This results in the following rule:
Firewall and NAT controlling proxies should allow SIP
registration messages to leave the enterprise. However, if
the domain in any of the Contacts is within the corporate
network, but the domain of the To field is not, the URLs in
the Contact headers MUST contain the firewall/proxy's
public IP address or domain name in the host part. If the
domain in the To field is within the corporate network, any
address, including private IP addresses, are allowed in the
Contact headers. Registrations not conforming to this
should be rejected with a 600 class response.
Like INVITE messages, it is also recommended that proxies perform
proxy authentication on outgoing registrations.
6.7.2 Incoming Registrations
Incoming registrations allow a user outside the network to establish
forwarding state within a proxy on the inside of the network. The
scenario arises when an employee of the company is travelling, and is
now logged in through some external network. They wish to have calls
for them forwarded from work to their new location. This may require
a registration to be sent from outside the network, to a registration
J.Rosenberg,D.Drew,H.Schulzrinne [Page 24]
Internet Draft SIP Firewalls February 22, 2000
server inside the network. We say "may", since if the user is
connected externally through a VPN service, the registrations will
not pass through the firewall, and will be effectively the same as
purely internal registrations.
As such, if a corporate intranet has VPN services deployed, and
roaming users make use of these services, it is recommended that
firewalls disable registrations coming in to the network from the
outside. This is accomplished by rejecting, with a 600 response, all
registrations which arrive from the external interface.
If VPN services are not enabled, registrations should be forwarded or
processed when arriving externally if:
1. The registrations are authenticated, and come from a known
user of the network,
2. The To field in the registrations corresponds to a valid
URL within the corporate enterprise
Registrations not meeting these criteria should be rejected.
6.8 Call Cancellation
When a call is cancelled, the proxy forwards the CANCEL according to
the rules in RFC 2543. The only additional operation to consider is
that a provisional response may have been sent for this call, and
this provisional response may have opened up holes in the firewall
for early media, or may have created address bindings for them. In
this case, a cancellation may require the holes to be closed and
bindings released for the early media. Before releasing the
firewall/NAT resources, the proxy should wait for a certain period
for a final 200 OK response to the INVITE which may have crossed the
CANCEL on the wire. If none comes, or if a 487 or other non-200
response arrives instead, the holes in the firewall should be closed.
6.9 Additional Messaging
SIP defines additional requests, in particular OPTIONS, which do not
come into play in the sections above. Extensions have been developed
which specify new requests, such as INFO [16]. Since these requests
don't alter call or session state, they should be forwarded normally,
possibly after proxy authentication.
6.10 Call Flow: Outgoing call
The call flow in Figure 6 shows an example of an outgoing call setup
through a proxy controlling firewall, in the case of a private
J.Rosenberg,D.Drew,H.Schulzrinne [Page 25]
Internet Draft SIP Firewalls February 22, 2000
network with internal SIP service. In the diagram, "INV A B" means an
INVITE message with SDP whose IP address in the c line is A, and
whose port in a single m line is B. Similarly, "200 OK A B" means a
200 OK response with SDP whose IP address in the c line is A, and
whose port in a single m line is B. "auth?" is an authorization
request to a local authentorization server (such as a RADIUS [17]),
or a query to a database server, such as SQL or LDAP.
INSIDE
Auth
Server/
UAC Proxy/FW DB UAS
| ------------------------> | auth? |
| INV 1.2.3.4. 55 |--------------->| |
| |<-------------- | |
| <------------------------ | fail | |
| 407 | | |
| | | |
| ------------------------> | | |
| ACK | | |
| ------------------------> | auth? | |
| |--------------->| |
| |<-------------- | |
| | OK |
| INV 1.2.3.4 55 |----------------------------> | (ringing)
| Proxy-Authorization:.. | INV 1.2.3.4 55 |
| | Record-Route:.. |
| | |
| (open)| <--------------------------- | (answer)
| | 200 OK 5.6.7.8 66 |
| <-------------------------| |
| 200 OK 5.6.7.8 66 | |
| | |
| ------------------------->| |
| ACK | |
| | ---------------------------->|
| | ACK |
| | |
| ..........................|..............................|
| RTP | |
| | |
| | |
| | <--------------------------- |
| <------------------------ | BYE |
| BYE | |
J.Rosenberg,D.Drew,H.Schulzrinne [Page 26]
Internet Draft SIP Firewalls February 22, 2000
| ------------------------> |(close) |
| 200 OK |----------------------------> |
| | 200 OK |
open: Allow UDP, port 55, destination IP 1.2.3.4 into firewall from
outside. Allow UDP, port 66, destination IP 5.6.7.8, out of
firewall from inside.
close: Do not allow UDP, port 55, destination IP 1.2.3.4 into firewall
from outside. Do not allow UDP, port 66, destination IP
5.6.7.8, out of firewall from inside.
Figure 6
7 Non-Solutions
Two alternate solutions have been proposed for allowing SIP to get
through firewalls. Both are primarily aimed at solving the external
services configuration. We do not consider these to be viable long
term solutions for the problem. They are:
1. Run SIP over port 80, which is used by HTTP [18]. Since SIP
is "close" to HTTP, this may fool firewalls into letting
SIP requests out of the firewall.
2. Have the user agents open a TCP connection out through the
firewall to its SIP server. Call invitations for the user
are sent over the open TCP connection. Since many firewalls
allow outgoing TCP connections, SIP messaging can flow.
The first of these is explicitly frowned upon administrators learn
that people are muxing other applications on port 80, and then
additional capabilities in firewalls are turned on to block messages
based on their content. Furthermore, it is fundamentally a means to
bypass administrator policy. It is our belief that the approach for
getting SIP through firewalls is to do so cooperatively, where the
firewall administrator knows about SIP messaging and explicitly
allows it. This is the only solution which can persist long term.
Furthermore, although the first solution may succeed in getting SIP
out through the firewall, SIP messages won't be forwarded externally
into the private network (most firewalls won't let HTTP requests on
port 80 into the network to arbitrary hosts). Furthermore, since the
media is sent on dynamic UDP ports, the media won't flow through the
firewall in all likelihood.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 27]
Internet Draft SIP Firewalls February 22, 2000
The second solution is similar in concept to the first. It is less
antagonistic towards firewall administrators, though. Rather than
fooling the administrator, it attempts to fit the service into one of
the allowed configurations. It improves upon the first by allowing
incoming requests. However, the same problem exists with media
streams. Some kind of TCP to UDP translator may be needed in this
case.
8 To Do
1. More detail on NAT operation, particularly creation of
bindings and detailed message flows.
2. Mention rejecting requests by the proxy that don't contain
SDP, as a way to avoid problems associated with chaning the
session description format.
9 Author's Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
Dale Drew
Director of Security Engineering
Level(3) Communications
1450 Infinite Drive
Louisville, Colorado, 80027
email: dale.drew@level3.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
10 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
J.Rosenberg,D.Drew,H.Schulzrinne [Page 28]
Internet Draft SIP Firewalls February 22, 2000
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments
(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.
[3] N. Freed, "Behavior of and requirements for internet firewalls,"
Internet Draft, Internet Engineering Task Force, June 1999. Work in
progress.
[4] P. Srisuresh and M. Holdrege, "IP network address translator
(NAT) terminology and considerations," Request for Comments
(Informational) 2663, Internet Engineering Task Force, Aug. 1999.
[5] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm
specific IP: a framework," Internet Draft, Internet Engineering Task
Force, Dec. 1999. Work in progress.
[6] D. Senie, "NAT friendly application design guidelines," Internet
Draft, Internet Engineering Task Force, Feb. 1999. Work in progress.
[7] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet Engineering
Task Force, Apr. 1998.
[8] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones,
"SOCKS protocol version 5," Request for Comments (Proposed Standard)
1928, Internet Engineering Task Force, Apr. 1996.
[9] G. Nair and H. Schulzrinne, "DHCP option for SIP servers,"
Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in
progress.
[10] J. Kempf and J. Rosenberg, "Finding a SIP server with SLP,"
Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in
progress.
[11] C. Newman and J. G. Myers, "ACAP -- application configuration
access protocol," Request for Comments (Proposed Standard) 2244,
Internet Engineering Task Force, Nov. 1997.
[12] F. Cuervo, C. Huitema, K. Kelly, B. Rosen, P. Sijben, and E.
Zimmerer, "MEGACO protocol proposal," Internet Draft, Internet
Engineering Task Force, Mar. 1999. Work in progress.
[13] S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, and A.
Roach, "SIP 183 session progress message," Internet Draft, Internet
J.Rosenberg,D.Drew,H.Schulzrinne [Page 29]
Internet Draft SIP Firewalls February 22, 2000
Engineering Task Force, Oct. 1999. Work in progress.
[14] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
Jan. 2000. Work in progress.
[15] S. Donovan, "SIP session timer," Internet Draft, Internet
Engineering Task Force, Oct. 1999. Work in progress.
[16] S. Donovan, "The SIP INFO method," Internet Draft, Internet
Engineering Task Force, Jan. 2000. Work in progress.
[17] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote
authentication dial in user service (RADIUS)," Request for Comments
(Proposed Standard) 2138, Internet Engineering Task Force, Apr. 1997.
[18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
Request for Comments (Draft Standard) 2616, Internet Engineering Task
Force, June 1999.
J.Rosenberg,D.Drew,H.Schulzrinne [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-24 01:16:46 |