idnits 2.17.1 draft-biggs-sip-nat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2000) is 8809 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 322, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '3') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft B. Biggs 2 Expiration Date: August 2000 3COM 3 March 2000 5 A SIP Application Level Gateway for Network Address Translation 6 draft-biggs-sip-nat-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an Application Level Gateway (ALG) for the 32 Session Initiation Protocol (SIP) by which IP addresses in the SIP 33 message and in the SDP body are statically mapped from one group to 34 another. The SIP ALG is a specific case of an Application Level 35 Gateway as described in [1]. 37 Transparent use of SIP-based devices in a Network Address Translation 38 (NAT) scenario requires that modifications be made to the SIP 39 messages. These modifications are performed by the ALG. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 44 2. Problem Scope and Requirements . . . . . . . . . . . . . . . 3 45 3. Translating IP Addresses in SIP Messages . . . . . . . . . . 4 46 3.1 Outgoing SIP Message Mangling . . . . . . . . . . . . . . . 4 47 3.1.1 Modifying the Topmost Via Header . . . . . . . . . . . . . . 5 48 3.1.2 Modifying the Contact Header . . . . . . . . . . . . . . . . 5 49 3.1.3 Modifying the SDP Body . . . . . . . . . . . . . . . . . . . 5 50 3.1.4 Modifying the Content-Length Header . . . . . . . . . . . . 5 51 3.2 Incoming SIP Message Mangling . . . . . . . . . . . . . . . 6 52 4. Example Message Translation . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 54 6. Current Implementations . . . . . . . . . . . . . . . . . . 7 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 59 1. Introduction 61 The need for IP address translation arises when a network's internal 62 IP addresses cannot be used outside the network either for security 63 reasons or because they are invalid for use outside the network. 64 Use of network address translation devices allows local hosts on 65 such private networks to transparently access the external global 66 Internet and enables access to selective local hosts from the 67 outside. This solution is becoming widely popular due to the 68 scarcity of IPv4 addresses. 70 The Session Initiation Protocol (SIP) [1] is a signalling protocol 71 for the setup of multimedia sessions across the Internet. The 72 protocol itself makes extensive use of network addresses located 73 inside the message body, making it impossible to use SIP through 74 basic network address translation without an Application Level 75 Gateway (ALG). 77 Full support of SIP by a firewall or NAT device is a difficult task. 78 It requires near full message parsing, and knowledge of call state to 79 know when to terminate media flow. It requires full encryption and 80 authentication support, and possibly the ability to generate its own 81 responses. However, in many situations this is neither feasible nor 82 required. 84 This document describes an implementation of a minimal SIP ALG for 85 the purpose of allowing simple SIP sessions to pass through a NAT 86 device. Rather than attempt to tackle the full SIP specification, we 87 have chosen a subset of the functionality which we feel is sufficient 88 for typical use. In section 2, we outline what scenarios we believe 89 that this method will be appropriate. Section 3 describes in 90 sufficient detail what tasks a SIP ALG must perform. 92 Note that this ALG is currently only discussing an implementation for 93 UDP SIP traffic, and that the modifications required to support TCP 94 are currently unknown. As well, this ALG only describes 95 modifications for implementations which use SDP to describe the media 96 stream. 98 2. Problem Scope and Requirements 100 | 101 | 102 +-----+ +----+ +-----+ 103 | SIP | | FW | | SIP | 104 | UA | +----+ | Svr | 105 +-----+ | +-----+ 106 | 107 inside | outside 108 | 109 Network X | Network Y 111 Figure 1: External Service [2] 113 The ALG framework described is designed to specifically solve the 114 problem of SIP User-Agents behind a firewall communicating with SIP 115 entities located outside of the firewall. In this document, we refer 116 to outgoing messages as being messages from inside the private 117 network traveling outside to the public Internet, and incoming 118 messages as the opposite. 120 This scenario is described in the SIP Firewalls draft [2] as 121 'External Service'. 123 A SIP message is identified by the ALG by using port 5060 as the 124 destination. Most NAT implementations identify the type of traffic 125 they will modify by using the port as an identifier, so this 126 restriction seems practical. 128 It is assumed that in a typical NAT situation, if a host on the 129 internal network attempts to send a UDP message at random to a host 130 located on the public Internet, that the packet will be modified to 131 appear as if it came from the firewall host and sent unmodified on 132 its way. This seems to be the typical scenario for most NAT 133 environments. This assumption is important because it implies that 134 we do not need to setup mappings to allow for media to be sent from 135 internal hosts to external SIP agents. 137 In cases where the above assumption is not valid, note that incoming 138 SDP must be modified and an additional port mapping be created. 140 3. Translating IP Addresses in SIP Messages 142 This section describes the areas of the SIP message which need to be 143 checked for addresses requiring translation. 145 A general SIP ALG must be capable of modifying the data in both the 146 incoming and outgoing packets. Specifically, for outgoing SIP 147 messages the headers which must be modified are the Via, Contact and 148 Content-Length headers. If the body of the data is of type 149 'application/sdp'. then it must also be modified. For incoming 150 messages, the only required modification is the SDP body. 152 In general, the NAT device maintains a table of port mappings which 153 allow ports on the globally routable address to map back to hosts and 154 ports behind the device. 156 For SIP messages, we propose that an ALG designate a single port for 157 each SIP device behind the firewall, and setup mappings as required 158 for media which flows through. 160 3.1 Outgoing SIP Message Modifications 162 When an outgoing SIP message is encountered, the ALG must first 163 lookup to see if there already exists a port mapping for the SIP UA. 164 A complete ALG should do a lookup based on the address listed in the 165 maddr field of the Via, and otherwise the address of origin of the 166 packet, and the port listed in the Via. 168 If a port mapping does not already exist, a port must be chosen to 169 allow for incoming SIP responses and future requests to be sent back 170 to the SIP UA behind the firewall. Due to the nature of SIP, this 171 port mapping must not be associated with a remote IP address. Any 172 external host must be able to use the port mapping to reach the SIP 173 UA behind the Firewall. 175 Most NAT implementations use a timeout for UDP port mappings. In the 176 case of this SIP signalling port, the timeout must be increased to an 177 appropriate amount. We believe that a timeout of at least one hour 178 is sufficient to allow most phones to send a REGISTER message to the 179 external proxy. 181 3.1.1 Modifying the Topmost Via Header 183 If the outgoing message is a SIP request, the Via must first be 184 modified such that responses to the request will get sent to the 185 NAT host on a port which is mapped to the appropriate client. 186 This involves modifying the port listed in the topmost Via. If the 187 Via contains an maddr field, this must be replaced by the IP address 188 of the NAT device. Otherwise, it is usually safest to modify the IP 189 address in either the received tag if one exists, or simply the 190 address in the sent-by. 192 3.1.2 Modifying the Contact Header 194 The Contact header must also be modified to reflect the NAT mapping 195 to ensure that future SIP requests will get sent to the appropriate 196 SIP UA. 198 3.1.3 Modifying the SDP Body 200 If the body of the SIP request is of type 'application/sdp', then it 201 must be checked for address information to be modified. 203 This first involves modifying the 'c=' line to reflect the IP address 204 of the NAT device. Note that if the address listed in the 'c=' line 205 is the null address (0.0.0.0), then this signifies that the call is 206 on hold, and no mangling needs to be performed on the SDP. 208 For each 'm=' line in the body, a port mapping must be setup for 209 incoming packets and the port changed in the SDP message. The 210 timeout on these ports must last for at least a few minutes to allow 211 for a reasonable delay in call setup. The port mapping must not be 212 bound to any external IP address, since media can come from anywhere. 214 It's also important to note that RTP port mappings must be on an even 215 numbered port on the NAT host, and that the port numbered one higher 216 must also be forwarded for RTCP. 218 As with the SIP signalling port mapping, the mapping setup for 219 incoming media must not impose future restrictions on where media is 220 to come from. Other hosts on the Internet must be able to send to 221 the same port on the NAT device and reach the same destination behind 222 the firewall. 224 3.1.4 Modifying the Content-Length Header 226 If the SDP body has changed due to a port mapping being setup, then 227 the Content-Length header of the SIP message must be changed to 228 reflect the new length. 230 3.2 Incoming SIP Message Mangling 232 An optimization can occur when two SIP User Agents both behind the 233 firewall make a call to each other. In order to avoid having media 234 between two internal hosts flow through the NAT host, incoming SIP 235 messages must be checked to ensure that the address of the NAT host 236 is not present in the SDP body. 238 If the body of the SIP message is of type 'application/sdp', then the 239 NAT host should check for its own address listed in the 'c=' line. 240 If it is a match, then each 'm=' line should be checked to find 241 existing port mappings. When a match is found, the 'c=' line and all 242 'm=' lines should be modified to reflect the internal hosts. 244 4. Example Message Translation 246 In the following message example, we will only show some of the 247 relevant headers for address translation purposes. 249 In this example, a client 10.0.0.99 attempts to call a phone on the 250 Internet at address billy@3com.com. In this example, C is the 251 client, P is the proxy on the Internet. 253 C->P: INVITE sip:billy@3com.com SIP/2.0 254 Via: SIP/2.0/UDP 10.0.0.99 255 Call-ID: 30309090808@10.0.0.99 256 Contact: 257 Content-Type: application/sdp 258 Content-Length: 107 260 v=0 261 o=username 0 0 IN IP4 10.0.0.99 262 c=IN IP4 10.0.0.99 263 t=0 0 264 m=audio 4330 RTP/AVP 0 266 This message is the intercepted by the ALG with an address of 267 149.112.117.203, which sets up a port mapping at port 60080 to map 268 back to the phone behind it for SIP messages, and also sets up a port 269 mapping on port 60082 to allow for incoming media to be sent again 270 back to the phone. A port mapping on port 60083 for RTCP is also 271 created. It then translates the packet to look as follows: 273 N->P: INVITE sip:billy@3com.com SIP/2.0 274 Via: SIP/2.0/UDP 149.112.117.203:60080 275 Call-ID: 30309090808@10.0.0.99 276 Contact: 277 Content-Type: application/sdp 278 Content-Length: 114 280 v=0 281 o=username 0 0 IN IP4 10.0.0.99 282 c=IN IP4 149.112.117.203 283 t=0 0 284 m=audio 60082 RTP/AVP 0 286 N represents the NAT host. Note that the address in both the Call-ID 287 and the 'o=' line of SDP do not need to be changed to reflect the 288 mapping, since they are only used for global uniqueness. It is 289 assumed that uniqueness will more than likely be preserved anyways. 291 5. Security Considerations 293 There are many security concerns about NAT systems in general, 294 especially ones which require that port mappings be setup allowing 295 any Internet host to send random UDP traffic through a firewall. 297 Attackers from the Internet could inflict denial of service attacks 298 to many phones simply by blasting traffic at a range of ports known 299 to likely map back to SIP devices. Since no remote IP address can be 300 set on media streams, a malicious user can blast unsolicited audio at 301 many phones simply by directing its attack on a range of ports known 302 to be reserved for NAT. 304 6. Current Implementations 306 A basic SIP ALG was implemented at 3Com using the Linux IP 307 masquerading system. Source code for this module is available at: 309 http://www.sip-happens.com/masquerade/ 311 7. References 313 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 314 "SIP: session initiation protocol," Request for Comments 315 (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 316 1999. 318 [2] J. Rosenberg, D. Drew, H. Schulzrinne, "Getting SIP through 319 Firewalls and NATs," Internet Draft, Internet Engineering Task 320 Force, Feb. 2000. Work in progress. 322 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 323 (NAT) Terminology and Considerations", RFC 2663, August 1999. 325 Acknowledgements 327 Thanks goes to Rick Dean, Jacek Grabiec, Jerry Mahler, and Guido 328 Schuster. 330 Authors' Addresses 332 Billy Biggs 333 3COM 334 3800 Golf Rd 335 Rolling Meadows, IL 336 USA 338 Phone: +1 847 262-2561 339 EMail: Billy_Biggs@3com.com 340 URI: http://www.3com.com/