Network Working Group C. Martin Internet Draft A. Johnston Expires: January 2002 WorldCom Category: Informational July 2001 SIP Through NAT Enabled Firewall Call Flows draft-martin-network-sip-natfw-callflows-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[1]. 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 informational draft outlines the operation of a SIP enabled NAPT (often referred to as PAT)/firewall ALG which makes modifications to SIP (Session Initiation Protocol)[2] headers and SDP (Session Description Protocol)[3] fields. Both inbound and outbound detailed call flows are included. Table of Contents Introduction 3 Overview of NAT 3 Assumptions 4 Scenario Topology 5 Call Scenario 5 Security Considerations and Implications 5 Transparency vs. SIP Proxy Functionality 6 High Level Tasks 6 SIP Signaling 6 Resulting media 6 Media control and status 6 Termination of SIP and Resulting Media 7 Typical Enterprise Application 7 Call Flow LEGEND 7 Outbound SIP through NAT Call Flow Scenario 8 Outbound Call Flow Illustration 8 Outbound Call Flow Detail 8 Inbound SIP Through NAT Call Flows 22 Inbound Call Flow Illustration 22 Inbound Call Flow Detail 22 References 32 Authors' Addresses 33 Copyright Notice 33 Introduction This document is intended to define the basic minimum requirement for the operation of the session initiation protocol (SIP)[2] traversal through NAPT and/or firewalls; both call flow, as well as firewall and NAT functionality will be addressed. The underlying intent is to identify specific considerations to the IETF for the development of SIP compliant middle-boxes for the rapid deployment of SIP. It does not address control by external proxies or firewall control mechanisms, or DNS host naming conventions between private and public realms. However, these flows do give an idea of the interaction necessary between the middle-box, specifically NAPT and firewall functionality, to be referred to as firewall in the remainder of this text. Consideration of "end-to-end" communications between hosts to maintain internal network integrity to the enterprise through proper packet modifications will also be addressed. Overview of NAT As described in RFC 1683[5], NAT and RFC 2663[6], IP Network Address Translator Terminology and Considerations, the following assumptions can be made, for our purposes, as it relates to NAT, some of these statements are included word for word from the RFCs: "The need for IP Address translation arises when a network's internal IP addresses cannot be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network." [6] In this case the scenario pertains to an enterprise scenario which implements a firewall performing NAT as well as the method of using one global IP address also commonly known as network address port translation (NAPT) or PAT. Throughout this document we will discuss a minimum requirement for "transparent" modifications to SIP packets in a PAT environment. "A Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as External network during NAT/PAT discussions." [6] "A private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT/PAT router." [6] Along these lines, the call flows in this document refer to a global address as a Global Address (GA); a private network address is referred to as a Local Address (LA). Remote global addresses, in relation to the firewall, are referred to as Remote Addresses (RA). "In addition to modifying the IP address, NAT/PAT must modify the IP checksum and the TCP checksum. Remember that TCPs checksum also covers a pseudo header, which contains the source and destination address. NAT must also look out for ICMP and FTP and modify the places where the IP address appears. There are undoubtedly other places, where modifications must be done." [5] Now we can add SIP to the list of protocols requiring the modification features associated with NAT. "The NAT function cannot by itself support all applications transparently and often must co-exist with application level gateways (ALGs) for this reason. People looking to deploy NAT based solutions need to determine their application requirements first and assess the NAT extensions (i.e., ALGs) necessary to provide application transparency for their environment." [6] This document attempts to address the functional areas relating to the network layer (IP, for our purposes), and transport layer (UDP in our example), if necessary. For the purpose of future SIP communications there may be a requirement for an ALG to create the appearance of transparent routing for end-to-end communications via the firewall, as well for modification of key header fields. For now developing a basic functionality for providing "transparent" SIP signaling and media flows through firewalls should be considered a key to facilitating multimedia communications over IP. Assumptions Throughout this call flow document the firewall is implemented as the gateway of last resort (default gateway) for the private network. All communications within this document are via UDP transport. The SIP proxy (NS) is utilized by the enterprise to provide additional SIP services not available between ordinary SIP clients, such as conferencing and voice mail. UserA is on a private network protected by a firewall with NAT enabled. UserB is a SIP client located on an unprotected public network located externally in relation to the outside firewall interface. The SIP proxy is located on the public network as well. Both UserA and UserB must communicate via the proxy server; hence the end users never communicate directly during signaling. Scenario Topology +---------+ |SIP Proxy| +---------+ | | +----------+ | +--------+ | Firewall |---IP Cloud---| User B | +----------+ +--------+ | +----------+ | User A | +----------+ Figure 1 Call Scenario If UserA wishes to place a SIP phone call they must go through the firewall, as seen in Figure 2. If UserB wishes to place a call to UserA, the firewall must be listening on port 5060 to act on the incoming INVITE, as seen in Figure 3. The firewall must be able to recognize and act on SIP packets as they flow through it. To facilitate this figure 1 and 2 give detailed call flow progression with notes to describe the modifications, pinhole creation, etc., which must occur to provide the illusion of transparency to the end users. For incoming requests the firewall will need a method to resolve the internal host's IP address by the "Via:", "Contact:", or c= fields found in the initial INVITE and 200 OK message bodies. Relevant fields related to firewall modifications MAY include some or all of the following headers/fields: Via, Record-Route, Route, Contact, Call-ID, o=, c=, and m=, and any other fields that may contain an IP address instead of hostname. Security Considerations and Implications Consideration should be made to ensure that internal private topology information not be divulged in the signaling packets. Consideration should also be made to reduce information-gathering attacks that utilize SIP enabled scanning tools (which may inevitably be created as the protocol gains increased exposure). The following lines; Via, Record-Route, Route, Contact, Call-ID, To, From, and Call-ID found in SIP, as well as o=, and c= found in SDP, MAY include an IP version of those fields that could heighten the risk of topology leaks if not addressed during development of firewall solutions. There are many other security aspects not included in this document but just as important, such as trust relationships, authentication, firewall control mechanisms, host resolution behind firewalls, etc. Transparency vs. SIP Proxy Functionality To keep things simple, initially, it is recommended that the SIP functionality of the firewall act as an outbound proxy (B2BUA), when dealing with the Via, Route, and Record-Route header, in addition to the function of hiding internal addresses in all other fields where required. This is both to protect internal topology as well as to reduce the number of tables required to provide "transparency". High Level Tasks SIP Signaling For initiation of SIP sessions the firewall MUST create a NAT table entry for the SIP session, that SHOULD require the inclusion of Call-ID and tag to identify the session. Resulting media Before describing RTP and RTCP level tasks we will include the following excerpt from RFC 1889, regarding RTP, this is only to illustrate the level of RTP operation required by this document. "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for use as the RTP port, it should replace this number with the next lower (even) number.", from RFC 1889 [7] . Based on this comment the firewall should create a NAT table entry for RTP that requires IP address port translation of local and global address. There should be a mechanism to allow creation of a dynamic firewall access list that allows NAT source entries and source port to NAT destination entries and source port, which SHOULD be based on SDP information, for each direction and associated with the SIP session by Call-ID and tag. Mechanisms SHOULD also be in place to ensure that RTP ports utilize even numbering, as stated in RFC 1889 [7]. Media control and status The firewall MUST create a NAT table entry for RTCP, if the packet requires IP address and/or port translation of local and global address. There MUST be a mechanism to create dynamic firewall access rules that allows NAT source entries and source port+1 to NAT destination entries and source port+1, which SHOULD be based on SDP information, for each direction and associated. This entry SHOULD be associated with the SIP session by Call-ID and tag. There SHOULD also be mechanisms to ensure that RTCP ports remain the next odd numbered ports in relation to the related RTP port number. Termination of SIP and Resulting Media Upon receipt of Bye, Cancel, Transfer, or timeout, the firewall SHOULD remove NAT translations, and the firewall access rules (pinholes) MUST be removed. Typical Enterprise Application The typical enterprise solution for connectivity to the Internet that is through a firewall implementation with NAT enabled, utilizing one external global IP address that represents all internal IP addresses (PAT), in combination with dynamic or static port assignment to each internal machine. It is important that incoming and outgoing sessions have the ability to operate in this type of scenario SIP UA to SIP UA if necessary. It is also recommended that the firewall behave as a Back-To-Back User Agent (B2BUA)[8], in order to provide the appropriate level of transparency as well as to maintain state of the sessions traversing it. Another possible alternative may be to utilize an internal SIP proxy to work in tandem with the firewall to create the B2BUA behavior, this text describes the firewall/B2BUA approach. Call Flow LEGEND UserA Local Private Address (LA)= 10.1.1.221 UserB Remote Global Address (RA) = 192.168.1.10 SIP Proxy Server (NS)= 63.81.221.88 Firewall(NAT) global address = 192.168.221.1 Each Packet is enclosed in the following manner: "=============================================" Headers and fields modified by the firewall have a "*" added at the end of the line, and detailed notes will be included after each relevant packet. In this document all packets contain an IP header field to clarify the operation of NAT throughout the call flow. Outbound SIP through NAT Call Flow Scenario Outbound Call Flow Illustration UserA NAT NS UserB 10.1.1.221 192.168.221.1 63.88.221.88 192168.1.10 | | | | |----F1 INVITE---->|--F2 INVITE->| | | | |--F5 INVITE->| |<---F4 100--------|<-F3 100-----| | | | | | | | |<--F6 180----| |<---F8 180--------|<-F7 180-----| | | | | | | | |<--F9 200 OK-| |<---F11 200 OK----|<-F10 200 OK-| | | | | | |----F12 ACK------>|---F13 ACK-->| | | | |--F14 ACK--->| | | | | |<---F15 2WAY RTP->|<-------F16 2WAY RTP------>| | | | | |----F17 BYE------>|-F18 BYE---->| | | | |--F19 BYE--->| | | | | | | |<-F20 200 OK-| |<---F22 200 OK----|<-F21 200 OK-| | | | | | Figure 2 Outbound Call Flow Detail ============================================= F1 INVITE USERA->NAT ------ IP Header --------------------------- IP Source Address: 10.1.1.221 IP Destination Address: 63.81.221.88 -------- SIP Message ------------------------ INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.221:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 123456@10.1.1.221 CSeq: 1 INVITE Contact: sip:UserA@10.1.1.221 Authorization:Digest username="UserA", realm="MCI WorldCom SIP", nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="", uri="sip:63.81.221.88", response="b3f392f9218a328b9294076d708e6815" Content-Type: application/sdp Content-Length: 143 v=0 o=UserA 2890844526 2890844526 IN IP4 UserA.customerA.com s=- t=0 0 c=IN IP4 10.1.1.221 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 =============================================== UserA prepares to receive data on port 49170 from the network. The fields containing IP addresses, in outbound packets, SHOULD be considered for modification by the firewall. Note: Call-ID and tag, should be used, in addition to the To:, From:, and additionally, in the case of the firewall acting as an outbound proxy (or B2BUA) and external SIP Proxy; Record Route and associated tags as specified in the SIP specification[1], should be used to identify this session. =============================================== F2 INVITE NAT -> NS ------ IP Header --------------------------- IP source address: 192.168.221.1 IP Destination Address: 63.81.221.88 -------- SIP Message ------------------------ INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 192.168.221.1:5060 * From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.221.1 * CSeq: 1 INVITE Contact: sip:UserA@192.168.221.1 * Authorization:Digest username="UserA", realm="MCI WorldCom SIP", nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="", uri="sip:63.81.221.88", response="b3f392f9218a328b9294076d708e6815" Content-Type: application/sdp Content-Length: 149 * v=0 o=UserA 2890844526 2890844526 IN IP4 UserA.customerA.com s=- t=0 0 c=IN IP4 192.168.221.1 * m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ================================================= For SIP, NAT may create an IP Header and transport header translation entry mapping UserA local IP address to the global address of the firewall, as necessary. All fields for all methods, tags, and parameters must be translated if they contain an IP address. The use of such a mapping can facilitate this. This table shows the Call-ID translation as an example of a field that requires modification. Examples are presented throughout this call flow, though they are redundant, with indications of what needs to be modified and what the method, tag, parameter performs. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | L | G | L | G | L/G | L/G | L/G | |IP Address| IP Address | Call-ID | Call-ID |List.| Dst | TAG | | | | | |Prot |Port | | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |10.1.1.221|192.168.221.1|1234500@ | 1234500@ | UDP |5060 |abcde| | | |10.1.1.221|192.168.221.1| | | | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 1: IP/Call-ID Translation All subsequent packets can use this mapping for SIP communications. Optionally some solutions may assign a static source port number to identify internal users. If this is the operation of the firewall's NAT features the firewall MUST modify the Via field to reflect the translation and listening port, in addition to adding a translation for the global listening port. Note: Call-ID could be used to identify the internal host for inbound responses related to this session. The Content-Length header MUST be modified to reflect the change to the SDP lines for all relevant packets, i.e., Via, 200 OK, etc. For RTP, The firewall passes information parsed from SDP "c=" and "m=" to NAT for creation of inbound IP header and port translation entry of 10.1.1.221 port 49170/192.168.221.1 port x (49170 in our example). The firewall MUST create an inbound pinhole for the listening IP Header and port based on outbound SDP. NOTE: RTP ports MUST be even numbered ++++++++++++++++++++++++++++++++++++++++++++++++++++ | L | G | L/G | L | G | | | |Protocol | Port | Port | ++++++++++++++++++++++++++++++++++++++++++++++++++++ |10.1.1.221|192.168.221.1| UDP | 49170 | 49170 | ++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 2: RTP Pinholes For RTCP, the firewall must also open an incoming pinhole for a port number one higher (an odd number). In our example it would be global IP 192.168.221.1 listening Port 49171 Protocol UDP. ++++++++++++++++++++++++++++++++++++++++++++++++++++ | L | G | L/G | L | G | | | |Protocol| Port | Port | ++++++++++++++++++++++++++++++++++++++++++++++++++++ |10.1.1.221|192.168.221.1 | UDP |49171 | 49171 | ++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 3: RTCP Pinholes For SIP the firewall SHOULD keep track of Call-ID and tag value for signaling, state, and to translate inbound SIP responses to the correct inside host, in this case it is UserA on port 5060. ================================================= F3 TRYING NS->NAT -------- IP Header ------------------------ Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 --------- SIP Message --------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy Call-ID: 1234500@192.168.221.1 CSeq: 1 INVITE ================================================= The NS uses a location manager function to determine where UserB is actually located. Based upon location analysis the call is proxied to UserB, for the firewall, which is actually UserA. ================================================= F4 Trying NAT->UserA ------------ IP Header --------------- Source IP Address: 63.81.221.88 Destination IP Address: 10.1.1.221 ------------ SIP Message -------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.1.1.221:5060 * From: TheBigGuy To: TheLittleGuy Call-ID: 1234500@10.1.1.221 * CSeq: 1 INVITE ================================================= ================================================= F5 INVITE NS->UserB ------ IP Header --------------------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.1.10 ------ SIP Message -------------------------- INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: From: TheBigGuy To: TheLittleGuy Call-ID: 1234500@192.168.221.1 CSeq: 1 INVITE Contact: sip:UserA@192.168.221.1 Content-Type: application/sdp Content-Length: 149 v=0 o=UserA 2890844526 2890844526 IN IP4 UserA.customerA.com s=- t=0 0 c=IN IP4 192.168.221.1 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ================================================= Note: the Record-Route is inserted by proxy servers, which takes on the form of Request URI, and may include additional tags (rr-param)such as maddr= indicating the proxy address. ================================================= F6 RINGING UserB->NS ------------ IP Header ------------------- Source IP Address: 192.168.1.10 Destination IP Address: 63.81.221.88 ------------ SIP Message ------------------ SIP/2.0 180 Ringing Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 1 INVITE ================================================= ================================================= F7 RINGING NS->NAT ---------- IP Header ----------------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 ---------- SIP Message --------------------- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 1 INVITE ================================================= ================================================= F8 RINGING NAT->UserA ---------- IP Header ------------------ Source IP Address: 63.81.221.88 Destination IP Address: 10.1.1.221 ----------- SIP Message ---------------- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.1.1.221:5060 * From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@10.1.1.221 * CSeq: 1 INVITE ================================================= The firewall MUST modify the Via header to insure that UserA does not discard this packet. ================================================= F9 200 OK USERB->NS ------------- IP Header ------------------ Source IP Address: 192.168.1.10 Destination IP Address: 63.81.221.88 ---------- SIP Message -------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 1 INVITE Contact: sip:UserB@192.168.1.10 Content-Type: application/sdp Content-Length: 141 v=0 o=UserB 2890844527 2890844527 IN IP4 UserB.there.com s=- t=0 0 c=IN IP4 192.168.1.10 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ================================================= ================================================= F10 200 OK NS->NAT -------------- IP Header ------------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 -------------- SIP Message ----------------- SIP/2.0 200 OK INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 1 INVITE Contact: sip:UserB@192.168.1.10 Content-Type: application/sdp Content-Length: 141 v=0 o=UserB 2890844527 2890844527 IN IP4 UserB.there.com s=- t=0 0 c=IN IP4 192.168.1.10 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ================================================= ================================================= F11 200 OK NAT->UserA ------------- IP Header --------------- Source IP Address: 63.81.221.88 Destination IP Address: 10.1.1.221 -------- SIP Message ------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.10:5060 * Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@10.1.1.221 * CSeq: 1 INVITE Contact: sip:UserB@192.168.1.10 Content-Type: application/sdp Content-Length: 141 v=0 o=UserB 2890844527 2890844527 IN IP4 UserB.there.com s=- t=0 0 c=IN IP4 192.168.1.10 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ================================================= The client for UserA prepares to send data on port 3456 to UserB. For SIP, the firewall MUST do the following: Firewall parses SIP packet and modifies Via using NAT table entry for the session to determine the global IP address. Call-ID MUST also be modified if an IP address is contained within it. In this packet Content-Length does not require modification because SDP does not require changes for inbound initiated sessions. RTP Firewall MUST determine the remote IP address and remote listening port values from SDP c= and m=. This SHOULD be added to the NAT table created, based on Call-ID and tag. The following information could be added to the NAT table for RTP Communications: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP Address | R Protocol | R Listening Port | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 192.168.1.10 | UDP | 3456 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 4: Outbound RTP RTCP Due to the nature of RTP the firewall MUST create a remote destination IP address and port entry for RTCP the listening port(the port MUST be one higher, and odd). A NAT entry MUST be created to allow "transparent" RTCP communications when necessary. In this example Destination IP 192.168.1.10 Destination port 3457 Protocol UDP. For more information on RTP and RTCP refer to RFC 1889. The following information SHOULD be added to the NAT table for RTCP Communications: +++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP Address | R Protocol | R Listening Port| +++++++++++++++++++++++++++++++++++++++++++++++++++++ | 192.168.1.10 | UDP | 3457 | +++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 5: Outbound RTCP ================================================= F12 ACK UserA->NAT ------------ IP Header ------------------- Source IP Address: 10.1.1.221 Destination IP Address: 63.81.221.88 ----------- SIP Message ------------------ ACK sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.221:5060 Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@10.1.1.221 CSeq: 1 ACK ================================================= Note: the Route header is used to identify the next hop from the proxy. ================================================= F13 ACK NAT->NS -------------- IP Header ----------------- Source IP Address: 192.168.221.1 Destination IP Address: 63.81.221.88 -------------- SIP Message -------------- ACK sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 192.168.221.1:5060 * Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 * CSeq: 1 ACK ================================================= When the ACK is received the NAT translation table for RTP SHOULD be activated NAT MUST Translate the IP Header for RTP/RTCP traffic traversing the firewall. The firewall MUST modify Via and Call-ID. Upon receipt of the ACK the firewall MUST enable the pinholes for RTP and RTCP, with the following rules created using the tables created earlier: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP | R | R | G IP | G | G | | Address |Protocol|List| Address |Protocol|Listening| | | |Port| | | Port | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |192.168.1.10| UDP |3456|192.168.221.1| UDP | 49170 | RTP |192.168.1.10| UDP |3457|192.168.221.1| UDP | 49171 | RTCP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 6: RTP/RTCP Note: The Source Port may be an ephemeral port (1024 through 5000), any of the registered ports (1024-49151) or up to 65535 depending on vendor implementation. The dynamic access rules SHOULD specify that the source port be a wildcard. Alternatively the incoming RTP/RTCP packets may be accepted based on the state established by an outgoing packet. ================================================= F14 ACK NS->UserB -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.1.10 -------------- SIP Message --------------- ACK sip: UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 1 ACK ================================================= ================================================= F15 RTP UserA-->NAT --------- IP Header ------------------------------------- Outbound [IP Source Address: 10.1.1.221, Destination IP Address: 192.168.1.10 UDP Source Port: ephemeral, Destination Port: 3456] Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 10.1.1.221 UDP Source Port: ephemeral, Destination Port: 49170] --------------- RTP Header ------------------------------ RTP Data ================================================= ================================================= F16 RTP NAT -->UserB --------- IP Header ------------------------------------- Outbound [IP Source Address: 192.168.221.1, Destination IP Address: 192.168.1.10] UDP Destination Port: 3456 Source Port: ephemeral Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 192.168.221.1] UDP Destination Port: 49170 Source Port: ephemeral --------------- RTP Header ------------------------------ RTP Data ================================================= NAT translations for IP Headers should remain to allow RTP data between UserA and UserB until the call is terminated. NAT should maintain translation for SIP until a BYE, CANCEL or timeout occurs ================================================= F17 BYE UserA->NAT -------------- IP Header ------------------ Source IP Address: 10.1.1.221 Destination IP Address: 63.81.221.88 -------------- SIP Message ----------------- BYE sip: UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.221:5060 Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@10.1.1.221 CSeq: 2 BYE ================================================= UserA Hangs up. ================================================= Note: CSeq has incremented because the user that initiated the communication is the same user that is terminating the call. Also note the Route header indicating the next hop, from the proxy. The firewall should keep the pinholes active until a 200 OK is received, or RTP transmission times out based on inactivity or a preset timeout on the firewall due to a loss of network connectivity. ================================================= F18 BYE NAT->NS -------------- IP Header ----------------- Source IP Address: 192.168.221.1 Destination IP Address: 63.81.221.88 --------------- SIP Message -------------- BYE sip: UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 192.168.221.1:5060 * Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 * CSeq: 2 BYE ================================================= ================================================= F19 BYE NS->UserB -------------- IP Header ----------------- Source IP Address:63.81.221.88 Destination IP Address: 192.168.1.10 --------------- SIP Message ---------------- BYE sip: UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 2 BYE ================================================= ================================================= F20 200 OK USERB->NS -------------- IP Header ---------------- Source IP Address: 192.168.1.10 Destination IP Address 63.81.221.88 ------------- SIP Message --------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 2 BYE ================================================= ================================================= F21 200 OK NS->NAT -------------- IP Header ------------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 ------------- SIP Message ------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@192.168.221.1 CSeq: 2 BYE ================================================= ================================================= F22 200 OK NAT->UserA -------------- IP Header ------------- Source IP Address: 63.81.221.88 Destination IP Address:10.1.1.254 --------------- SIP Message ---------- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.221:5060 * From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 1234500@10.1.1.221 * CSeq: 2 BYE ================================================= NAT SHOULD delete translation table entries for the SIP, RTP and RTCP sessions (using the Call-ID and tag as the reference to this session) for both inbound and outbound connections. Firewall MUST close pinholes for inbound and outbound connections as soon as the call is terminated. Inbound SIP Through NAT Call Flows Inbound Call Flow Illustration UserA NAT NS UserB 10.1.1.221 192.168.221.1 63.88.221.88 192168.1.10 | | | | | | |<--F1 INVITE-| |<---F4 INVITE-----|<--F3 INVITE-| | | | |---F2 100--->| | | | | |----F5 180------->|--F6 180---->| | | | |--F7 180---->| | | | | |----F8 200 OK---->|--F9 200 OK->| | | | |-F10 200 OK->| | | | | | | |<-F11 ACK----| |<---F13 ACK-------|<-F12 ACK----| | | | | | |<--F14 2WAY RTP-->|<------F15 2WAY RTP ------>| | | | | |----F16 BYE------>|-F17 BYE---->| | | | |--F18 BYE--->| | | |<-F19 200 OK-| |<---F21 200 OK----|<-F20 200 OK-| | | | | | Figure 3 Inbound Call Flow Detail ========================================== F1 INVITE USERB->NS ------------ IP Header ------------------- IP Source Address: 192.168.1.10 IP Destination Address: 63.81.221.88 ------------- SIP Message ---------------- INVITE sip:UserA@customerA.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheLittleGuy To: TheBigGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE Contact: sip:UserB@192.168.1.10 Authorization:Digest username="UserB", realm="MCI WorldCom SIP", nonce="85b4f1cen4341ae6cbe5a3a9c8e88df9", opaque="", uri="sip:63.81.221.88", response="b3f392f9218a328b9294076d708e6815" Content-Type: application/sdp Content-Length: 142 v=0 o=UserB 2890844526 2890844526 IN IP4 UserB.there.com s=- t=0 0 c=IN IP4 192.168.1.10 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ========================================== User B prepares to receive data on port 49170 from the network F1 shows an example of SIP utilizing the Authentication header for authentication to the proxy using message digest algorithm. PGP and S/MIME are also being developed as other possible scalable authentication mechanisms. ========================================== F2 Trying NS->UserB -------------- IP Header ------------------ Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.10 ------------- SIP Message ------------------- SIP/2.0 100 Trying Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheBigGuy To: TheBigGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE ========================================== ========================================== F3 INVITE NS->NAT ------------ IP Header -------------------- IP Source Address: 63.81.221.88 IP Destination Address: 192.168.221.1 ------------- SIP Message ----------------- INVITE sip:UserA@customerA.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 Record-Route: From: TheLittleGuy To: TheBigGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE Contact: sip:UserB@192.168.1.10 Content-Type: application/sdp Content-Length: 142 v=0 o=UserB 2890844526 2890844526 IN IP4 UserB.there.com s=- t=0 0 c=IN IP4 192.168.1.10 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ========================================== The NS will perform a lookup for the location of UserA; in this case it would be registered through the firewall. The firewall should be configured to be listening on port 5060, the default port for SIP but may be configured according to any custom implementation parameters. The firewall may have a method to perform internal hostname lookup based on SIP URI. When name is resolved NAT SHOULD setup table entries to pass packets through to UserA. One possible solution is that the firewall performs DNS lookup for internal IP address of UserA, parsed from the Request URI: UserA@customerA.com, replacing the "@" with a ".". The lookup would yield internal host 10.1.1.221 and adds it to the NAT entry for this session, including in the entry the Call-ID and tag, supplied by UserB, to identify future SIP packets belonging to the session. NAT then modifies the IP header Destination IP address of packet. This is of course assuming that customerA wishes to utilize DNS naming consistent with this method. The firewall should prepare pinhole for remote RTP to User B on port 49170. ++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP Address | R Protocol | R Listening Port | ++++++++++++++++++++++++++++++++++++++++++++++++++++++ |192.168.1.10 | UDP | 49170 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 7: Inbound RTP The firewall MUST prepare RTCP pinhole for remote of 49170+1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP Address | R Protocol | R Listening Port | +++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 192.168.1.10 | UDP | 49171 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 8: Inbound RTCP ========================================== F4 INVITE NAT->UserA ------------------ IP Header ---------- IP source address: 63.81.221.88 IP Destination Address: 10.1.1.221 ----------------- SIP Message ----------- INVITE sip:UserA@customerA.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 Record-Route: From: TheLittleGuy To: TheBigGuy ;tag=abcde Contact: sip:UserB@192.168.1.10 CSeq: 1 INVITE Contact: sip:UserB@192.168.1.10 Content-Type: application/sdp Content-Length: ... v=0 o=UserB 2890844526 2890844526 IN IP4 UserB.there.com c=IN IP4 192.168.1.10 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ========================================== ========================================== F5 RINGING UserA->NAT -------------- IP Header ----------------- Source IP Address: 10.1.1.221 Destination IP Address: 63.81.221.88 --------------- SIP Message ------------- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE ========================================== ========================================== F6 RINGING NAT->NS -------------- IP Header ----------------- Source IP Address: 192.168.221.1 Destination IP Address: 63.81.221.88 -------------- SIP Message --------------- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE ========================================== The following NAT entry SHOULD be created: 10.1.1.221, 5060, Call- ID, tag, 192.168.221.1, 5060, Call-ID, tag ========================================== F7 RINGING NS->UserB -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.1.10 -------------- SIP Message --------------- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.221.1:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE ========================================== ========================================== F8 200 OK UserA->NAT -------------- IP Header ------------------ Source IP Address: 10.1.1.12 Destination IP Address: 192.168.221.1 -------------- SIP Message ---------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Contact: sip:UserA@10.1.1.12 Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 148 v=0 o=UserA 2890844527 2890844527 IN IP4 UserA.there.com s=- t=0 0 c=IN IP4 10.1.1.12 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ========================================== UserA prepares to listen on port 3456 The firewall MUST modify IP, port, SIP and via port if necessary, and SDP c=, and m=, NAT should create an outbound translation. Firewall should prepare pinholes for inbound RTP/RTCP IP and port +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP | R | R | G IP | G | G | | Address |Protocol| Port| Address |Protocol|Port| +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |192.168.1.10| UDP |49170|192.168.221.1| UDP |3456| RTP |192.168.1.10| UDP |49171|192.168.221.1| UDP |3457| RTCP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 9: NAT RTP/RTCP ========================================== F9 200 OK NAT->NS -------------- IP Header ----------------- Source IP Address: 192.168.221.1 Destination IP Address: 63.81.221.88 -------------- SIP Message -------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Contact: sip:UserA@192.168.221.1 * Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 142 * v=0 o=UserA 2890844527 2890844527 IN IP4 UserA.there.com s=- t=0 0 c=IN IP4 192.168.221.1 * m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ========================================== ========================================== F10 200 OK NS->UserB -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.1.10 -------------- SIP Message --------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=abcde Contact: sip:UserA@192.168.221.1 Call-ID: 12345600@192.168.1.10 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 142 v=0 o=UserA 2890844527 2890844527 IN IP4 UserA.there.com s=- t=0 0 c=IN IP4 192.168.221.1 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ========================================== ========================================== F11 ACK USERB->NS -------------- IP Header ----------------- Source IP Address: 192.168.1.10 Destination IP Address: 63.81.221.88 -------------- SIP Message --------------- ACK sip:UserA@here.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Route: Call-ID: 12345600@192.168.1.10 CSeq: 1 ACK ========================================== ========================================== F12 ACK NS->NAT -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 -------------- SIP Message --------------- ACK sip:UserA@here.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Record-Route: Call-ID: 12345600@192.168.1.10 CSeq: 1 ACK ========================================== Upon receipt of ACK, NAT translation MUST be activated. Receipt of ACK firewall MUST enable pinholes using the following rules created from SDP information. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | R IP | R | R | G IP | G | G | | Address |Prot|List.| Address |Protocol|Listening| | | |Port | | | Port | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |63.81.221.88| UDP|49170|192.168.221.1| UDP | 3456 |RTP |63.81.221.88| UDP|49171|192.168.221.1| UDP | 3457 |RTCP ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 10 RTP/RTCP Note: The Source Port will be an ephemeral port (Between 1024 and 65536). Source port could be a wildcard, and may be accepted if ACK bit set (in the case of TCP), or can be added after first packet received indicating source port, depending on the stateful mechanisms employed. ========================================== F13 ACK NAT->UserA -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address: 10.1.1.221 -------------- SIP Message --------------- ACK sip:UserA@customerA.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.1.10:5060 From: TheBigGuy To: TheLittleGuy ;tag=abcde Record-Route: Call-ID: 12345600@192.168.1.10 CSeq: 1 ACK ========================================== ========================================== F14 RTP UserA-->NAT --------- IP Header ------------------------------------- Outbound [IP Source Address: 10.1.1.221, Destination IP Address: 192.168.1.10 UDP Source Port: ephemeral, Destination Port: 49170] Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 10.1.1.221 UDP Source Port: ephemeral, Destination Port: 3456] --------------- RTP Header ------------------------------ RTP Data ========================================== ========================================== F15 RTP NAT -->B --------- IP Header ------------------------------------- Outbound [IP Source Address: 192.168.221.1, Destination IP Address: 192.168.1.10 UDP Source Port: ephemeral, Destination Port: 49170] Inbound [IP Source Address: 192.168.1.10, Destination IP Address: 192.168.221.1 UDP Source Port: ephemeral, Destination Port: 3456] --------------- RTP Header ------------------------------ RTP Data ========================================== User A Hangs Up with User B. */ ========================================== F16 BYE UserA->NAT -------------- IP Header ----------------- Source IP Address: 10.1.1.221 Destination IP Address: 63.81.221.88 -------------- SIP Message --------------- BYE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.221:5060 Route: To: TheBigGuy From: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 BYE ========================================== ========================================== F17 BYE NAT->NS -------------- IP Header ----------------- Source IP Address: 192.168.221.1 Destination IP Address: 63.81.221.88 -------------- SIP Message --------------- BYE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 192.168.221.1:5060 * Route: To: TheBigGuy From: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 BYE ========================================== ========================================== F18 BYE NS->UserB -------------- IP Header ----------------- Source IP Address:63.81.221.88 Destination IP Address: 192.168.1.10 -------------- SIP Message --------------- BYE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 Record-Route: To: TheBigGuy From: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 BYE ========================================== ========================================== F19 200 OK USERB->NS -------------- IP Header ----------------- Source IP Address: 192.168.1.10 Destination IP Address 63.81.221.88 -------------- SIP Message --------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 63.81.221.88:5060 Via: SIP/2.0/UDP 192.168.221.1:5060 To: TheBigGuy From: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 BYE ========================================== ========================================== F20 200 OK NS->NAT -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address: 192.168.221.1 -------------- SIP Message --------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.221.1:5060 To: TheBigGuy From: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 BYE ========================================== ========================================== F21 200 OK NAT->UserA -------------- IP Header ----------------- Source IP Address: 63.81.221.88 Destination IP Address:10.1.1.221 -------------- SIP Message --------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.221:5060 * To: TheBigGuy From: TheLittleGuy ;tag=abcde Call-ID: 12345600@192.168.1.10 CSeq: 1 BYE ========================================== Firewall MUST close RTP pinholes in both directions and delete NAT entries for SIP, RTP and RTCP (using the Call-ID and To: tag as the reference point for these flows) References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, March 1999. [3] M. Handley, V. Jacobson, "SDP: Session Description Protocol", Request for Comments (Proposed Standard) 2327, Internet Engineering Task Force, April 1998 [4] P. Srisuresh, J. Kuthan, and J. Rosenberg, " Middlebox Communication Architecture and framework", Internet Engineering Task Force Internet-Draft, Work in Progress, 2001. [5] Egevang, K. and P. Francis, "The IP Network Address Translator",RFC 3022, January 2001. [6] Srisuresh, P. and M. Holdrege, "NAT Terminology and Considerations", RFC 2663, August 1999. [7] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP:A Transport Protocol for Real-Time Applications " Request for comments(Standards Track) 1889, Network Working Group Audio-Video Transport Working Group, January 1996 [8] H. Shulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", Internet Engineering Task Force, January 1996 Authors' Addresses Christopher A. Martin WorldCom 400 International Richardson, Texas 75081 christopher.a.martin@wcom.com Alan Johnston WorldCom 100 S. 4th Street St. Louis, Missouri 63104 alan.johnston@wcom.com Copyright Notice "Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.