Internet Draft 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 | | / | | | / | | | / +--------+ | / | / +------+ +------+ +------+ / | |<---| |<---| || | -->| | +------+ +------+ +------+ | 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]