Internet Draft B. Biggs Expiration Date: August 2000 3COM March 2000 A SIP Application Level Gateway for Network Address Translation draft-biggs-sip-nat-00.txt 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 describes an Application Level Gateway (ALG) for the Session Initiation Protocol (SIP) by which IP addresses in the SIP message and in the SDP body are statically mapped from one group to another. The SIP ALG is a specific case of an Application Level Gateway as described in [1]. Transparent use of SIP-based devices in a Network Address Translation (NAT) scenario requires that modifications be made to the SIP messages. These modifications are performed by the ALG. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Scope and Requirements . . . . . . . . . . . . . . . 3 3. Translating IP Addresses in SIP Messages . . . . . . . . . . 4 B. Biggs Internet Draft [Page 1] Internet-Draft SIP Application Level Gateway March 2000 3.1 Outgoing SIP Message Mangling . . . . . . . . . . . . . . . 4 3.1.1 Modifying the Topmost Via Header . . . . . . . . . . . . . . 5 3.1.2 Modifying the Contact Header . . . . . . . . . . . . . . . . 5 3.1.3 Modifying the SDP Body . . . . . . . . . . . . . . . . . . . 5 3.1.4 Modifying the Content-Length Header . . . . . . . . . . . . 5 3.2 Incoming SIP Message Mangling . . . . . . . . . . . . . . . 6 4. Example Message Translation . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 6. Current Implementations . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The need for IP address translation arises when a network's internal IP addresses cannot be used outside the network either for security reasons or because they are invalid for use outside the network. Use of network address translation devices allows local hosts on such private networks to transparently access the external global Internet and enables access to selective local hosts from the outside. This solution is becoming widely popular due to the scarcity of IPv4 addresses. The Session Initiation Protocol (SIP) [1] is a signalling protocol for the setup of multimedia sessions across the Internet. The protocol itself makes extensive use of network addresses located inside the message body, making it impossible to use SIP through basic network address translation without an Application Level Gateway (ALG). Full support of SIP by a firewall or NAT device is a difficult task. It requires near full message parsing, and knowledge of call state to know when to terminate media flow. It requires full encryption and authentication support, and possibly the ability to generate its own responses. However, in many situations this is neither feasible nor required. This document describes an implementation of a minimal SIP ALG for the purpose of allowing simple SIP sessions to pass through a NAT device. Rather than attempt to tackle the full SIP specification, we have chosen a subset of the functionality which we feel is sufficient for typical use. In section 2, we outline what scenarios we believe that this method will be appropriate. Section 3 describes in sufficient detail what tasks a SIP ALG must perform. B. Biggs Internet Draft [Page 2] Internet-Draft SIP Application Level Gateway March 2000 Note that this ALG is currently only discussing an implementation for UDP SIP traffic, and that the modifications required to support TCP are currently unknown. As well, this ALG only describes modifications for implementations which use SDP to describe the media stream. 2. Problem Scope and Requirements | | +-----+ +----+ +-----+ | SIP | | FW | | SIP | | UA | +----+ | Svr | +-----+ | +-----+ | inside | outside | Network X | Network Y Figure 1: External Service [2] The ALG framework described is designed to specifically solve the problem of SIP User-Agents behind a firewall communicating with SIP entities located outside of the firewall. In this document, we refer to outgoing messages as being messages from inside the private network traveling outside to the public Internet, and incoming messages as the opposite. This scenario is described in the SIP Firewalls draft [2] as 'External Service'. A SIP message is identified by the ALG by using port 5060 as the destination. Most NAT implementations identify the type of traffic they will modify by using the port as an identifier, so this restriction seems practical. It is assumed that in a typical NAT situation, if a host on the internal network attempts to send a UDP message at random to a host located on the public Internet, that the packet will be modified to appear as if it came from the firewall host and sent unmodified on its way. This seems to be the typical scenario for most NAT environments. This assumption is important because it implies that we do not need to setup mappings to allow for media to be sent from B. Biggs Internet Draft [Page 3] Internet-Draft SIP Application Level Gateway March 2000 internal hosts to external SIP agents. In cases where the above assumption is not valid, note that incoming SDP must be modified and an additional port mapping be created. 3. Translating IP Addresses in SIP Messages This section describes the areas of the SIP message which need to be checked for addresses requiring translation. A general SIP ALG must be capable of modifying the data in both the incoming and outgoing packets. Specifically, for outgoing SIP messages the headers which must be modified are the Via, Contact and Content-Length headers. If the body of the data is of type 'application/sdp'. then it must also be modified. For incoming messages, the only required modification is the SDP body. In general, the NAT device maintains a table of port mappings which allow ports on the globally routable address to map back to hosts and ports behind the device. For SIP messages, we propose that an ALG designate a single port for each SIP device behind the firewall, and setup mappings as required for media which flows through. 3.1 Outgoing SIP Message Modifications When an outgoing SIP message is encountered, the ALG must first lookup to see if there already exists a port mapping for the SIP UA. A complete ALG should do a lookup based on the address listed in the maddr field of the Via, and otherwise the address of origin of the packet, and the port listed in the Via. If a port mapping does not already exist, a port must be chosen to allow for incoming SIP responses and future requests to be sent back to the SIP UA behind the firewall. Due to the nature of SIP, this port mapping must not be associated with a remote IP address. Any external host must be able to use the port mapping to reach the SIP UA behind the Firewall. Most NAT implementations use a timeout for UDP port mappings. In the case of this SIP signalling port, the timeout must be increased to an appropriate amount. We believe that a timeout of at least one hour is sufficient to allow most phones to send a REGISTER message to the B. Biggs Internet Draft [Page 4] Internet-Draft SIP Application Level Gateway March 2000 external proxy. 3.1.1 Modifying the Topmost Via Header If the outgoing message is a SIP request, the Via must first be modified such that responses to the request will get sent to the NAT host on a port which is mapped to the appropriate client. This involves modifying the port listed in the topmost Via. If the Via contains an maddr field, this must be replaced by the IP address of the NAT device. Otherwise, it is usually safest to modify the IP address in either the received tag if one exists, or simply the address in the sent-by. 3.1.2 Modifying the Contact Header The Contact header must also be modified to reflect the NAT mapping to ensure that future SIP requests will get sent to the appropriate SIP UA. 3.1.3 Modifying the SDP Body If the body of the SIP request is of type 'application/sdp', then it must be checked for address information to be modified. This first involves modifying the 'c=' line to reflect the IP address of the NAT device. Note that if the address listed in the 'c=' line is the null address (0.0.0.0), then this signifies that the call is on hold, and no mangling needs to be performed on the SDP. For each 'm=' line in the body, a port mapping must be setup for incoming packets and the port changed in the SDP message. The timeout on these ports must last for at least a few minutes to allow for a reasonable delay in call setup. The port mapping must not be bound to any external IP address, since media can come from anywhere. It's also important to note that RTP port mappings must be on an even numbered port on the NAT host, and that the port numbered one higher must also be forwarded for RTCP. As with the SIP signalling port mapping, the mapping setup for incoming media must not impose future restrictions on where media is to come from. Other hosts on the Internet must be able to send to the same port on the NAT device and reach the same destination behind the firewall. 3.1.4 Modifying the Content-Length Header If the SDP body has changed due to a port mapping being setup, then B. Biggs Internet Draft [Page 5] Internet-Draft SIP Application Level Gateway March 2000 the Content-Length header of the SIP message must be changed to reflect the new length. 3.2 Incoming SIP Message Mangling An optimization can occur when two SIP User Agents both behind the firewall make a call to each other. In order to avoid having media between two internal hosts flow through the NAT host, incoming SIP messages must be checked to ensure that the address of the NAT host is not present in the SDP body. If the body of the SIP message is of type 'application/sdp', then the NAT host should check for its own address listed in the 'c=' line. If it is a match, then each 'm=' line should be checked to find existing port mappings. When a match is found, the 'c=' line and all 'm=' lines should be modified to reflect the internal hosts. 4. Example Message Translation In the following message example, we will only show some of the relevant headers for address translation purposes. In this example, a client 10.0.0.99 attempts to call a phone on the Internet at address billy@3com.com. In this example, C is the client, P is the proxy on the Internet. C->P: INVITE sip:billy@3com.com SIP/2.0 Via: SIP/2.0/UDP 10.0.0.99 Call-ID: 30309090808@10.0.0.99 Contact: Content-Type: application/sdp Content-Length: 107 v=0 o=username 0 0 IN IP4 10.0.0.99 c=IN IP4 10.0.0.99 t=0 0 m=audio 4330 RTP/AVP 0 This message is the intercepted by the ALG with an address of 149.112.117.203, which sets up a port mapping at port 60080 to map back to the phone behind it for SIP messages, and also sets up a port mapping on port 60082 to allow for incoming media to be sent again back to the phone. A port mapping on port 60083 for RTCP is also created. It then translates the packet to look as follows: B. Biggs Internet Draft [Page 6] Internet-Draft SIP Application Level Gateway March 2000 N->P: INVITE sip:billy@3com.com SIP/2.0 Via: SIP/2.0/UDP 149.112.117.203:60080 Call-ID: 30309090808@10.0.0.99 Contact: Content-Type: application/sdp Content-Length: 114 v=0 o=username 0 0 IN IP4 10.0.0.99 c=IN IP4 149.112.117.203 t=0 0 m=audio 60082 RTP/AVP 0 N represents the NAT host. Note that the address in both the Call-ID and the 'o=' line of SDP do not need to be changed to reflect the mapping, since they are only used for global uniqueness. It is assumed that uniqueness will more than likely be preserved anyways. 5. Security Considerations There are many security concerns about NAT systems in general, especially ones which require that port mappings be setup allowing any Internet host to send random UDP traffic through a firewall. Attackers from the Internet could inflict denial of service attacks to many phones simply by blasting traffic at a range of ports known to likely map back to SIP devices. Since no remote IP address can be set on media streams, a malicious user can blast unsolicited audio at many phones simply by directing its attack on a range of ports known to be reserved for NAT. 6. Current Implementations A basic SIP ALG was implemented at 3Com using the Linux IP masquerading system. Source code for this module is available at: http://www.sip-happens.com/masquerade/ 7. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. B. Biggs Internet Draft [Page 7] Internet-Draft SIP Application Level Gateway March 2000 [2] J. Rosenberg, D. Drew, H. Schulzrinne, "Getting SIP through Firewalls and NATs," Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. Acknowledgements Thanks goes to Rick Dean, Jacek Grabiec, Jerry Mahler, and Guido Schuster. Authors' Addresses Billy Biggs 3COM 3800 Golf Rd Rolling Meadows, IL USA Phone: +1 847 262-2561 EMail: Billy_Biggs@3com.com URI: http://www.3com.com/ B. Biggs Internet Draft [Page 8]