SIP Working Group Fredrik Thernelius Bertil Engelholm Internet Draft Ericsson July 2000 Category: Informational SIP Firewall Solution Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. 1. Abstract This document describes a solution that is able to handle SIP signaling together with NAT enabled firewalls. The intent is to show that existing firewalls do not have to be replaced by "SIP enabled" ones, instead they will only have to be reconfigured slightly. The main feature of this solution is using MGCP from a session control proxy to open/close holes in an RTP proxy which then enables RTP traffic to flow between interconnected networks. Worth noting is that this solution will not only work for SIP, it will also work for other protocols, such as H.323 or Real Audio. It does not even have to be RTP that is passed through the RTP proxy, though this draft assumes that the RTP stream is accompanied by RTCP. The solution will work for any protocol that wishes to open/close ports dynamically in the RTP proxy (maybe it should be called Forwarding Engine in the general case). Thernelius, Engelholm [Page 1] SIP Firewall Solution July 2000 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Introduction This draft proposes a simple solution to the problems that NAT introduces when it's used together with SIP [2]. By terminating all multimedia sessions in an RTP proxy on the demilitarized zone (DMZ) and then from that point relay the RTP packets to the final destination we do not have to bother with NAT even if the internal network uses private addresses. It must be noted that packet-filtering rules have to be added in the firewall in order to allow UDP packets from both the internal and the external networks if they are destined for the RTP proxy. Similarly, packets must be allowed to leave the DMZ if they come from the RTP proxy. The RTP proxy will require a global IP address for this solution to work as described in this document. A SIP proxy controls the RTP proxy by using the media gateway control protocol (MGCP) [3]. MGCP is a client-server protocol, documented in RFC 2705. The solution requires that an MGCP call agent is integrated in the SIP proxy. The draft "draft-huitema-megaco-mgcp-firewall-00.txt" shows the signaling needed for implementing this solution. Since only a small subset of MGCP is needed the development time of this solution is kept to a minimum. 4 SIP 4.1 General The Session Initiation Protocol (SIP) is used to setup media sessions between two or more parties. The session can include e.g. audio and/or video streams. A SIP message can look like this: INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: ... Thernelius, Engelholm Expires January 2001 [Page 2] SIP Firewall Solution July 2000 v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=Mr. Watson, come here. c=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0 3 4 5 The SIP message contains two parts. A SIP part and a SDP part. The SIP part basically describes who you want to contact (in the example watson@boston.bell-tel.com) and from whom the invitation come from (A.Bell). The SDP part describes what kind of media stream you want to setup and to where you want the B-client to setup the media stream (in the example the A-client want the B-client to setup an RTP audio stream towards port 3456 at kton.bell-tel.com).If this kind of message is sent from a client connected to a company network or an ISP network a few problem will arise if the network is connected through a firewall towards the rest of internet. 5 Firewall Design | | +----------+ +--| | | | | | +----------+ EXTERNAL INTERNAL | | : | : | : oooo | : ooo ooo | ooo ooo +-----------+ | +----------+ o o | | | | Agent 1 | o IP Cloud o--------| Firewall |---+--| | ooo ooo | | | +----------+ / ooo ooo +-----------+ | / oooo | | / DMZ | / | / | +----------+ +--------+ +--|SIP proxy | | Agent 2| +----------+ | | | | | |RTP proxy |---+ +----------+ +--------+ | | | +----------+ Figure 1. Firewall Design View Thernelius, Engelholm Expires January 2001 [Page 3] SIP Firewall Solution July 2000 The design is based on a firewall/router (FW) with three interfaces. The internal interface connects to all SIP agents inside the firewall. The external interface connects to the unprotected external world. The demilitarized zone (DMZ) is a third separate interface connecting a number of proxies. For SIP there are two proxies that are interesting, the SIP proxy and the RTP proxy. The SIP proxy will transfer all SIP communication between the internal and the external world. In the same way will the RTP proxy transfer all RTP communication. This means that no SIP or RTP traffic is allowed to pass through the firewall without first passing one of the proxies. It is noted that the architecture described above is not REQUIRED. Both the RTP proxy and the SIP proxy MAY just as well be co-located in the firewall box. For simplicity reasons the architecture in Figure 1 is discussed in this document. 5.1 SIP Proxy The SIP proxy will take care of all SIP messages that need to be transferred between the internal and the external interfaces. When SIP messages are received, the SIP proxy will use them to control the RTP proxy so that all RTP ports for a multi media session are opened/closed as they are needed. In some cases the SIP proxy also have to modify addresses in the SIP headers so that internal/private information is not send out on the external side of the firewall. This draft does not attempt to cover how this should be done. The SIP proxy will exchange the SDP part of the message to the one given by the RTP proxy (see below) 5.2 RTP Proxy The RTP proxy will analyze the SDP part sent by the SIP proxy and open/close the corresponding ports and then return a new SDP back to the SIP proxy containing the addresses and ports used by the RTP proxy for the current session. This new SDP is copied into the SIP message by the SIP proxy which then forwards it to the correct receiver. The RTP proxy will be configured to use a wide range of ports for the RTP traffic. The firewall will have to let UDP traffic through if its destination or source address is the RTP proxy. 5.3 MGCP The Media Gateway Control Protocol (MGCP) is used as a control protocol between the SIP proxy and the RTP proxy. The SIP proxy have Thernelius, Engelholm Expires January 2001 [Page 4] SIP Firewall Solution July 2000 to integrate the client part of the protocol, the Call Agent (CA), and the RTP proxy will have to implement the server part of the protocol, the Call Agent Server (CAS). The CAS will use the well- known MGCP port (2427). MGCP is convenient to use for this purpose since it also uses SDP as session description protocol, just as SIP do. In this way the SIP proxy can just copy the SDP part from SIP messages to the MGCP commands sent to the RTP proxy. MGCP is also logical to use due to the fact that the functionality of the RTP proxy is very similar to that of other media gateways in the sense that we set up connections through the RTP proxy. In this case the media gateway happens to have IP on the both sides. The media gateway will thus work as an IP bridge. When MGCP is used in the way described in this draft only a subset of the entire protocol have to be implemented. MGCP specifies possibility to get traffic statistics from the gateway (RTP proxy) which means that functionality for charging can be added. 6 Signal Flows 6.1 Session Setup (internal -> External) 6.1.1 Flow agent1 SIP proxy RTP proxy agent2 | | | | | SIP(INVITE) | | | |----------------->| | | | SIP(100 Trying) | | | |<-----------------| | | | | MGCP (Create Connection#1) | | | |----------------------------->| | | | MGCP (200 OK) | | | |<-----------------------------| | | | MGCP (Create Connection#2) | | | |----------------------------->| | | | MGCP (200 OK) | | | |<-----------------------------| | | | SIP (INVITE) | | | |--------------------------------------------->| | | SIP (200 OK) | | | |<---------------------------------------------| | | MGCP (Modify connection#2) | | | |----------------------------->| | | | MGCP (200 OK) | | | |<-----------------------------| | | | MGCP (Modify connection#1) | | Thernelius, Engelholm Expires January 2001 [Page 5] SIP Firewall Solution July 2000 | |----------------------------->| | | | MGCP (200 OK) | | | |<-----------------------------| | | SIP(200 OK) | | | |<-----------------| | | | SIP(ACK) | | | |----------------->| | | | | MGCP (Modify connection: sendrecv) | | |----------------------------->| | | | MGCP (200 OK) | | | |<-----------------------------| | | | SIP (ACK) | | | |--------------------------------------------->| | | | | |<----------------------------------------------->|<------------->| |<---------- RTP traffic -------------->|<-RTP traffic->| |<----------------------------------------------->|<------------->| | | | | | | | | Figure 2. SIP and MGCP setup signaling 6.1.2 Description RTP proxy +--------+ P1 C1 P2 +---------+ P3 C2 P4 +--------+ | |o---------------o|- - - - -|o-----------------o| | | agent1 | | R1 | | agent2 | | |o----- | | -----o| | +--------+ \ +---------+ / +--------+ \ o / \ | / \ | / \ | / \ | MGCP / SIP \ | / SIP \ | / \ | / \ | / \ | / \ | / \ | / C = Connection o o o P = Endpoint +---------+ R = Relay | | |SIP proxy| | | +---------+ Figure 3. Signaling between logical entities Thernelius, Engelholm Expires January 2001 [Page 6] SIP Firewall Solution July 2000 This is a logical view of what should be done for this traffic case. The SIP proxy shall order the RTP proxy to setup connections (C1 and C2) towards the two SIP agents where agent1 is inside the firewall and agent2 is outside. Everything starts with agent1 sending a SIP INVITE message to the outbound SIP proxy: INVITE sip:UserB@fwp1.wcom.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: TheBigGuy To: TheLittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheBigGuy Content-Type: application/sdp Content-Length:169 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com t=0 0 c=IN IP4 10.11.12.13 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 In this example UserA (user agent1) invites UserB (user agent2) to participate in a session containing one audio stream (on port 49170 at IP address 10.11.12.13) and one MPEG video stream (on port 53000 also at IP address 10.11.12.13). The SIP proxy will send a MGCP command ordering the RTP proxy to setup a connection towards agent1 (C1): CRCX 1432 relay/$@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 M: inactive v=0 o=UserA 2890844526 2890844526 IN IP4 here.com t=0 0 c=IN IP4 10.11.12.13 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 The SIP proxy orders the RTP proxy to create a connection (CRCX) for this session. The SDP from the SIP message is copied as it is and will be analyzed by the Call Agent Server in the RTP proxy. The SIP proxy has also specified a call id (C: ...) and the connection mode Thernelius, Engelholm Expires January 2001 [Page 7] SIP Firewall Solution July 2000 (M: ...). The mode is set to inactive at this stage because we don't want the RTP proxy to forward any RTP packages yet (no receiver yet). The RTP proxy will now analyze the SDP part and create the corresponding ports, which will be returned as a new SDP part in a OK message: 200 1432 OK Z: relay/42@rtpproxy.here.com I: 32C789 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com t=0 0 c=IN IP4 200.3.4.5 m=audio 10126 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 10128 RTP/AVP 32 a=rtpmap:32 MPV/90000 The RTP proxy has generated a new IP address (200.3.4.5) and two new port numbers (10126 and 10128). The RTP proxy actually allocates four port numbers since each RTP port has a corresponding RTCP port (10127 and 10129). A connection identity (I: ...) has also been returned so the SIP proxy can direct orders directly to this connection later on. The RTP proxy has also return a relay address (Z: ...) for this connection so the SIP proxy can order the RTP proxy to relay packages (R1 in the picture) between different connections. The SIP proxy will now order the RTP proxy to setup a new connection (C2) towards agent2: CRCX 1433 relay/42@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 M: inactive Since the SIP proxy has no information yet about agent2 it cannot send any SDP information. Since the SIP proxy uses the same call id and specifies the relay code (42) it received in the last response from the RTP proxy the RTP proxy will create the corresponding ports and setup the relay between these ports (R1 between P2 and P3). The RTP proxy will then return an OK message with the new ports: 200 1433 OK I: 32C78A v=0 o=UserA 2890844526 2890844526 IN IP4 here.com t=0 0 c=IN IP4 200.3.4.5 Thernelius, Engelholm Expires January 2001 [Page 8] SIP Firewall Solution July 2000 m=audio 10130 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 10132 RTP/AVP 32 a=rtpmap:32 MPV/90000 The SIP proxy can know take the received SDP part and copy it into a SIP INVITE message and send it to UserB at agent2: INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP fwp1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: TheBigGuy To: TheLittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheBigGuy Content-Type: application/sdp Content-Length:167 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com t=0 0 c=IN IP4 200.3.4.5 m=audio 10130 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 10132 RTP/AVP 32 a=rtpmap:32 MPV/90000 Agent2 can now setup communication towards the address and ports pointed out the RTP proxy. When UserB has decided which media streams he can/wants to participate in he respond with an OK message: SIP/2.0 200 OK Via: SIP/2.0/UDP fwp1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: TheBigGuy To: TheLittleGuy ;tag=314159 Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheLittleGuy Content-Type: application/sdp Content-Length: 147 v=0 o=UserB 2890844527 2890844527 IN IP4 there.com t=0 0 c=IN IP4 110.111.112.113 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Thernelius, Engelholm Expires January 2001 [Page 9] SIP Firewall Solution July 2000 m=video 0 RTP/AVP 32 In this message agent2 (UserB) says that the audio stream will be received at port 3456 at IP address 110.111.112.113 but denies the video stream by setting the port to zero. The SIP proxy will now order the RTP proxy to modify the connection towards agent2 using the SDP part received in the SIP message from agent2: MDCX 1434 relay/42@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 I: 32C78A M: inactive v=0 o=UserB 2890844527 2890844527 IN IP4 there.com t=0 0 c=IN IP4 110.111.112.113 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 32 The RTP proxy will remove the ports allocated for the video stream since it will not be used. After that the RTP proxy respond with an OK message: 200 1434 OK The SIP proxy now orders the RTP proxy to modify the connection towards agent1 (UserA): MDCX 1435 relay/42@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 I: 32C789 M: inactive v=0 o=UserB 2890844527 2890844527 IN IP4 there.com t=0 0 c=IN IP4 110.111.112.113 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 32 The RTP proxy modifies this connection according to the new SDP and responds with an OK message: 200 1435 OK Thernelius, Engelholm Expires January 2001 [Page 10] SIP Firewall Solution July 2000 v=0 o=UserB 2890844527 2890844527 IN IP4 there.com t=0 0 c=IN IP4 200.3.4.5 m=audio 10126 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 32 This SDP information is copied into the SIP OK message by the SIP proxy and sent to UserA at agent1: SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: TheBigGuy To: TheLittleGuy ;tag=314159 Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheLittleGuy Content-Type: application/sdp Content-Length: 147 v=0 o=UserB 2890844527 2890844527 IN IP4 there.com t=0 0 c=IN IP4 200.3.4.5 m=audio 10126 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 32 Agent1 can now configure its RTP ports to communicate with the RTP proxy and after that send an ACK message back to agent2 via the SIP proxy: ACK sip:UserB@fwp1.wcom.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 Route: From: TheBigGuy To: TheLittleGuy ;tag=314159 Call-Id: 12345600@here.com CSeq: 1 ACK Content-Length: 0 The SIP proxy now has to order the RTP proxy to open up the RTP traffic by issuing a new modify command (this could already have been done when the SIP OK message arrived): MDCX 1436 relay/42@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 M: sendrecv Thernelius, Engelholm Expires January 2001 [Page 11] SIP Firewall Solution July 2000 The RTP proxy respond with an OK message after the mode have been changed: 200 1436 OK The SIP proxy now forwards the ACK message to agent2: ACK sip: UserB@there.com SIP/2.0 Via: SIP/2.0/UDP fwp1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 From: TheBigGuy To: TheLittleGuy ;tag=314159 Call-Id: 12345600@here.com CSeq: 1 ACK Content-Length: 0 UserA and UserB can now send audio streams to each other through the RTP proxy. Since all RTP traffic is passing the RTP proxy it means that the RTP proxy can keep track on how much traffic is passing it which can be used for e.g. charging. The RTP proxy can also check if the packages passing is correct and throw away packages that has some fault in them. 6.2 Session Disconnection (internal -> External) 6.2.1 Flow agent1 SIP proxy RTP proxy agent2 | | | | | SIP(BYE) | | | |----------------->| | | | | SIP (BYE) | | | |------------------------------------------->| | | SIP (200 OK) | | | |<-------------------------------------------| | | MGCP (Delete Connection#1) | | | |----------------------------->| | | | MGCP (250 OK) | | | |<-----------------------------| | | | MGCP (Delete Connection#2) | | | |----------------------------->| | | | MGCP (250 OK) | | | |<-----------------------------| | | SIP(200 OK) | | | |<-----------------| | | | | | | Figure 4. SIP and MGCP setup signaling 6.2.2 Description Thernelius, Engelholm Expires January 2001 [Page 12] SIP Firewall Solution July 2000 RTP proxy +--------+ P1 C1 P2 +---------+ P3 C2 P4 +--------+ | |o---------------o|- - - - -|o-----------------o| | | agent1 | | R1 | | agent2 | | |o----- | | -----o| | +--------+ \ +---------+ / +--------+ \ o / \ | / \ | / \ | / \ | MGCP / SIP \ | / SIP \ | / \ | / \ | / \ | / \ | / \ | / C = Connection o o o P = Endpoint +---------+ R = Relay | | |SIP proxy| | | +---------+ Figure 5. Signaling between logical entities This is a logical view of what should be done for this traffic case. The SIP proxy shall order the RTP proxy to delete the two connections (C1 and C2) towards the SIP agents where agent1 is inside the firewall and agent2 is outside. Agent1 initiates the disconnection by sending a SIP BYE message to the SIP proxy: BYE sip:UserB@fwp1.wcom.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 Route: From: TheBigGuy To: TheLittleGuy Call-Id: 12345600@here.com CSeq: 2 BYE Content-Length:0 The SIP proxy forwards the BYE message to agent2: BYE sip: UserB@there.com SIP/2.0 Via: SIP/2.0/UDP fwp1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 From: TheBigGuy To: TheLittleGuy ;tag=314159 Thernelius, Engelholm Expires January 2001 [Page 13] SIP Firewall Solution July 2000 Call-Id: 12345600@here.com CSeq: 2 BYE Content-Length: 0 Agent2 confirms the disconnection by returning a OK message to the SIP proxy: SIP/2.0 200 OK Via: SIP/2.0/UDP fwp1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 From: TheBigGuy To: TheLittleGuy ;tag=314159 Call-Id: 12345600@here.com CSeq: 2 BYE Content-Length: 0 The SIP proxy now orders the RTP proxy to delete the two connections used by this session: DLCX 1437 relay/42@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 I: 32C789 DLCX 1438 relay/42@rtpproxy.here.com MGCP 1.0 C: A3F41278B7065249 I: 32C78A After deleting each connection the RTP proxy respond with an OK message for each delete command: 250 1437 OK P: PS=1459, OS=34560, PR=1434, OR=33780, PL=2, JI=7, LA=26 250 1438 OK P: PS=1434, OS=33780, PR=1459, OR=34560, PL=5, JI=5, LA=26 MGCP specifies a possibility for the gateway (RTP proxy in our case) to return connection parameters (P: ...) when a connection is deleted. These parameters basically says how many packets was sent (PS) and received (PR) and how many octets that was sent (OS) and received (OR). It is also specified how many packets were lost (PL) the jitter (JI) and estimated network latency (LA). 8. Security Considerations Strong authentication and encryption algorithms SHOULD protect the communication between the SIP proxy and the RTP proxy. Thernelius, Engelholm Expires January 2001 [Page 14] SIP Firewall Solution July 2000 RTP proxy: This entity should have all services turned off except those needed for management. SIP proxy: This entity should have all services turned off except those needed for management. The firewall SHOULD allow communication to and from the RTP proxy and SIP proxy, which both reside on the DMZ. The SIP proxy MUST know if a certain SIP message came from the "inside" or from the "outside". Otherwise it is possible for a user to be able to open ports through the RTP proxy by answering his/her own INVITE message with a 200 OK. 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 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, Mar. 1999. [3] M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Media Gateway Control Protocol Version 1.0", RFC 2705, October 1999. 10. Author's Addresses Fredrik Thernelius G÷talandsv„gen 230 Box 1505 125 25 ýlvsj÷ Stockholm, Sweden Phone: +46-8-727 49 96 Email: fredrik.thernelius@uab.ericsson.se Bertil Engelholm G÷talandsv„gen 230 Box 1505 125 25 ýlvsj÷ Stockholm, Sweden Phone: +46-8-727 3499 Email: bertil.engelholm@uab.ericsson.se Thernelius, Engelholm Expires January 2001 [Page 15] SIP Firewall Solution July 2000 11. Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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. Thernelius, Engelholm Expires January 2001 [Page 16]