diff options
Diffstat (limited to 'doc/rfc/rfc3581.txt')
| -rw-r--r-- | doc/rfc/rfc3581.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3581.txt b/doc/rfc/rfc3581.txt new file mode 100644 index 0000000..6ba996f --- /dev/null +++ b/doc/rfc/rfc3581.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 3581 dynamicsoft +Category: Standards Track H. Schulzrinne + Columbia University + August 2003 + + + An Extension to the Session Initiation Protocol (SIP) for + Symmetric Response Routing + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Session Initiation Protocol (SIP) operates over UDP and TCP, + among others. When used with UDP, responses to requests are returned + to the source address the request came from, and to the port written + into the topmost Via header field value of the request. This + behavior is not desirable in many cases, most notably, when the + client is behind a Network Address Translator (NAT). This extension + defines a new parameter for the Via header field, called "rport", + that allows a client to request that the server send the response + back to the source IP address and port from which the request + originated. + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 1] + +RFC 3581 Symmetric Response Routing August 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . 8 + 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 8 + 9.3. Brittleness Introduced by this Specification . . . . . . 9 + 9.4. Requirements for a Long Term Solution . . . . . . . . . 10 + 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 10 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 11.2. Informative References . . . . . . . . . . . . . . . . . 11 + 12. Intellectual Property and Copyright Statements . . . . . . . . 11 + 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 + +1. Introduction + + The Session Initiation Protocol (SIP) [1] operates over UDP and TCP. + When used with UDP, responses to requests are returned to the source + address the request came from, and to the port written into the + topmost Via header field value of the request. This results in a + "hybrid" way of computing the destination of the response. Half of + the information (specifically, the IP address) is taken from the IP + packet headers, and the other half (specifically, the port) from the + SIP message headers. SIP operates in this manner so that a server + can listen for all messages, both requests and responses, on a single + IP address and port. This helps improve scalability. However, this + behavior is not desirable in many cases, most notably, when the + client is behind a NAT. In that case, the response will not properly + traverse the NAT, since it will not match the binding established + with the request. + + Furthermore, there is currently no way for a client to examine a + response and determine the source port that the server saw in the + corresponding request. Currently, SIP provides the client with the + source IP address that the server saw in the request, but not the + port. The source IP address is conveyed in the "received" parameter + in the topmost Via header field value of the response. This + information has proved useful for basic NAT traversal, debugging + + + +Rosenberg & Schulzrinne Standards Track [Page 2] + +RFC 3581 Symmetric Response Routing August 2003 + + + purposes, and support of multi-homed hosts. However, it is + incomplete without the port information. + + This extension defines a new parameter for the Via header field, + called "rport", that allows a client to request that the server send + the response back to the source IP address and port where the request + came from. The "rport" parameter is analogous to the "received" + parameter, except "rport" contains a port number, not the IP address. + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 + [2] and indicate requirement levels for compliant implementations. + +3. Client Behavior + + The client behavior specified here affects the transport processing + defined in Section 18.1 of SIP (RFC 3261) [1]. + + A client, compliant to this specification (clients include UACs and + proxies), MAY include an "rport" parameter in the top Via header + field value of requests it generates. This parameter MUST have no + value; it serves as a flag to indicate to the server that this + extension is supported and requested for the transaction. + + When the client sends the request, if the request is sent using UDP, + the client MUST be prepared to receive the response on the same IP + address and port it used to populate the source IP address and source + port of the request. For backwards compatibility, the client MUST + still be prepared to receive a response on the port indicated in the + sent-by field of the topmost Via header field value, as specified in + Section 18.1.1 of SIP [1]. + + When there is a NAT between the client and server, the request will + create (or refresh) a binding in the NAT. This binding must remain + in existence for the duration of the transaction in order for the + client to receive the response. Most UDP NAT bindings appear to have + a timeout of about one minute. This exceeds the duration of non- + INVITE transactions. Therefore, responses to a non-INVITE request + will be received while the binding is still in existence. INVITE + transactions can take an arbitrarily long amount of time to complete. + As a result, the binding may expire before a final response is + received. To keep the binding fresh, the client SHOULD retransmit + its INVITE every 20 seconds or so. These retransmissions will need + to take place even after receiving a provisional response. + + + + +Rosenberg & Schulzrinne Standards Track [Page 3] + +RFC 3581 Symmetric Response Routing August 2003 + + + A UA MAY execute the binding lifetime discovery algorithm in Section + 10.2 of RFC 3489 [4] to determine the actual binding lifetime in the + NAT. If it is longer than 1 minute, the client SHOULD increase the + interval for request retransmissions up to half of the discovered + lifetime. If it is shorter than one minute, it SHOULD decrease the + interval for request retransmissions to half of the discovered + lifetime. Note that discovery of binding lifetimes can be + unreliable. See Section 14.3 of RFC 3489 [4]. + +4. Server Behavior + + The server behavior specified here affects the transport processing + defined in Section 18.2 of SIP [1]. + + When a server compliant to this specification (which can be a proxy + or UAS) receives a request, it examines the topmost Via header field + value. If this Via header field value contains an "rport" parameter + with no value, it MUST set the value of the parameter to the source + port of the request. This is analogous to the way in which a server + will insert the "received" parameter into the topmost Via header + field value. In fact, the server MUST insert a "received" parameter + containing the source IP address that the request came from, even if + it is identical to the value of the "sent-by" component. Note that + this processing takes place independent of the transport protocol. + + When a server attempts to send a response, it examines the topmost + Via header field value of that response. If the "sent-protocol" + component indicates an unreliable unicast transport protocol, such as + UDP, and there is no "maddr" parameter, but there is both a + "received" parameter and an "rport" parameter, the response MUST be + sent to the IP address listed in the "received" parameter, and the + port in the "rport" parameter. The response MUST be sent from the + same address and port that the corresponding request was received on. + This effectively adds a new processing step between bullets two and + three in Section 18.2.2 of SIP [1]. + + The response must be sent from the same address and port that the + request was received on in order to traverse symmetric NATs. When a + server is listening for requests on multiple ports or interfaces, it + will need to remember the one on which the request was received. For + a stateful proxy, storing this information for the duration of the + transaction is not an issue. However, a stateless proxy does not + store state between a request and its response, and therefore cannot + remember the address and port on which a request was received. To + properly implement this specification, a stateless proxy can encode + the destination address and port of a request into the Via header + field value that it inserts. When the response arrives, it can + extract this information and use it to forward the response. + + + +Rosenberg & Schulzrinne Standards Track [Page 4] + +RFC 3581 Symmetric Response Routing August 2003 + + +5. Syntax + + The syntax for the "rport" parameter is: + + response-port = "rport" [EQUAL 1*DIGIT] + + This extends the existing definition of the Via header field + parameters, so that its BNF now looks like: + + via-params = via-ttl / via-maddr + / via-received / via-branch + / response-port / via-extension + +6. Example + + A client sends an INVITE to a proxy server which looks like, in part: + + INVITE sip:user@example.com SIP/2.0 + Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff + + This INVITE is sent with a source port of 4540 and a source IP + address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com), + listening on both port 5060 and 5070. The client sends the request + to port 5060. The request passes through a NAT on the way to the + proxy, so that the source IP address appears as 192.0.2.1 and the + source port as 9988. The proxy forwards the request, but not before + appending a value to the "rport" parameter in the proxied request: + + INVITE sip:user@example.com SIP/2.0 + Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 + Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 + ;branch=z9hG4bKkjshdyff + + This request generates a response which arrives at the proxy: + + SIP/2.0 200 OK + Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 + Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 + ;branch=z9hG4bKkjshdyff + + The proxy strips its top Via header field value, and then examines + the next one. It contains both a "received" parameter and an "rport" + parameter. The server follows the rules specified in Section 4 and + sends the response to IP address 192.0.2.1, port 9988, and sends it + from port 5060 on 192.0.2.2: + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 5] + +RFC 3581 Symmetric Response Routing August 2003 + + + SIP/2.0 200 OK + Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 + ;branch=z9hG4bKkjshdyff + + This packet matches the binding created by the initial request. + Therefore, the NAT rewrites the destination address of this packet + back to 10.1.1.1, and the destination port back to 4540. It forwards + this response to the client, which is listening for the response on + that address and port. The client properly receives the response. + +7. Security Considerations + + When a server uses this specification, responses that it sends will + now include the source port where the request came from. In some + instances, the source address and port of a request are sensitive + information. If they are sensitive, requests SHOULD be protected by + using SIP over TLS [1]. In such a case, this specification does not + provide any response routing functions (as these only work with TCP); + it merely provides the client with information about the source port + as seen by the server. + + It is possible that an attacker might try to disrupt service to a + client by acting as a man-in-the-middle, modifying the "rport" + parameter in a Via header in a request sent by a client. Removal of + this parameter will prevent clients from behind NATs from receiving + service. The addition of the parameter will generally have no + impact. Of course, if an attacker is capable of launching a man-in- + the-middle attack, there are many other ways of denying service, such + as merely discarding the request. Therefore, this attack does not + seem significant. + +8. IANA Considerations + + There are no IANA considerations associated with this specification. + +9. IAB Considerations + + The IAB has studied a class of protocols referred to as Unilateral + Self Address Fixing (UNSAF) protocols [5]. These protocols allow a + client behind a NAT to learn the IP address and port that a NAT will + allocate for a particular request, in order to use this information + in application layer protocols. An example of an UNSAF protocol is + the Simple Traversal of UDP Through NATs (STUN) [4]. + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 6] + +RFC 3581 Symmetric Response Routing August 2003 + + + Any protocol is an UNSAF protocol if it reveals, to a client, the + source IP address and port of a packet sent through that NAT. + Although not designed for that purpose, this specification can be + used as an UNSAF protocol. Using the "rport" parameter (defined + here) and the "received" parameter (defined in RFC 3261 [1]) in the + topmost Via header field value of a response, a client sending a + request can learn its address as it was seen by the server which sent + the response. + + There are two uses of this information. The first is for + registrations. Consider a client behind a NAT wishing to register + with a proxy/registrar on the other side of the NAT. The client must + provide, in its registration, the address at which it should receive + incoming SIP requests from the proxy. However, since the client is + located behind a NAT, none of the addresses on any of its interfaces + will be reachable from the proxy. If the client can provide the + proxy with an address that the proxy can reach, the client can + receive incoming requests. Using this specification, a client behind + a NAT can learn its address and port as seen by the proxy which + receives a REGISTER request. The client can then perform an + additional registration, using this address in a Contact header. + This would allow a client to receive incoming requests, such as + INVITE, on the IP address and port it used to populate the source IP + address and port of the registration it sent. This approach will + only work when servers send requests to a UA from the same address + and port on which the REGISTER itself was received. + + In many cases, the server to whom the registration is sent won't be + the registrar itself, but rather a proxy which then sends the request + to the registrar. In such a case, any incoming requests for the + client must traverse the proxy to whom the registration was directly + sent. The Path header extension to SIP [3] allows the proxy to + indicate that it must be on the path of such requests. + + The second usage is for record routing, to address the same problem + as above, but between two proxies. A proxy behind a NAT which + forwards a request to a server can use OPTIONS, for example, to learn + its address as seen by that server. This address can be placed into + the Record-Route header field of requests sent to that server. This + would allow the proxy to receive requests from that server on the + same IP address and port it used to populate the source IP address + and port of the OPTIONS request. + + Because of this potential usage, this document must consider the + issues raised in [5]. + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 7] + +RFC 3581 Symmetric Response Routing August 2003 + + +9.1. Problem Definition + + From [5], any UNSAF proposal must provide: + + Precise definition of a specific, limited-scope problem that is to + be solved with the UNSAF proposal. A short term fix should not be + generalized to solve other problems; this is why "short term fixes + usually aren't". + + This specification is primarily aimed at allowing SIP responses to be + received when a request is sent through a NAT. In this primary + application, this specification is not an UNSAF proposal. However, + as a side effect of this capability, this specification can be used + as an UNSAF protocol. In that usage, it would address two issues: + + o Provide a client with an address that it could use in the Contact + header of a REGISTER request when it is behind a NAT. + + o Provide a proxy with an address that it could use in a Record- + Route header in a request, when it is behind a NAT. + +9.2. Exit Strategy + + From [5], any UNSAF proposal must provide: + + Description of an exit strategy/transition plan. The better short + term fixes are the ones that will naturally see less and less use + as the appropriate technology is deployed. + + The SIP working group has recognized that the usage of this + specification to support registrations and record-routing through + NATs is not appropriate. It has a number of known problems which are + documented below. The way to eliminate potential usage of this + specification for address fixing is to provide a proper solution to + the problems that might motivate the usage of this specification for + address fixing. Specifically, appropriate solutions for + registrations and record-routing in the presence of NATs need to be + developed. These solutions would not rely on address fixing. + + Requirements for such solutions are already under development [6]. + + Implementors of this specification are encouraged to follow this work + for better solutions for registrations and record-routing through + NAT. + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 8] + +RFC 3581 Symmetric Response Routing August 2003 + + +9.3. Brittleness Introduced by this Specification + + From [5], any UNSAF proposal must provide: + + Discussion of specific issues that may render systems more + "brittle". For example, approaches that involve using data at + multiple network layers create more dependencies, increase + debugging challenges, and make it harder to transition. + + This specification, if used for address fixing, introduces several + points of brittleness into a SIP system: + + o If used for UDP registrations, a client will need to frequently + re-register in order to keep the NAT bindings fresh. In many + cases, these registrations will need to take place nearly one + hundred times more frequently than the typical refresh interval of + a registration. This introduces load into the system and hampers + scalability. + + o A client cannot accurately determine the binding lifetime of a NAT + it is registering (or record-routing) through. Therefore, there + may be periods of unreachability that occur between the time a + binding expires and the next registration or OPTIONS refresh is + sent. This may result in missed calls, messages, or other + information. + + o If the NAT is of the symmetric variety [4], a client will only be + able to use its address to receive requests from the server it has + sent the request to. If that server is one of many servers in a + cluster, the client may not be able to receive requests from other + servers in the cluster. This may result in missed calls, + messages, or other information. + + o If the NAT is of the symmetric variety [4], a client will only be + able to use its address to receive requests if the server sends + requests to the client from the same address and port the server + received the registrations on. This server behavior is not + mandated by RFC 3261 [1], although it appears to be common in + practice. + + o If the registrar and the server to whom the client sent its + REGISTER request are not the same, the approach will only work if + the server uses the Path header field [3]. There is not an easy + and reliable way for the server to determine that the Path header + should be used for a registration. Using Path when the address in + the topmost Via header field is a private address will usually + work, but may result in usage of Path when it is not actually + needed. + + + +Rosenberg & Schulzrinne Standards Track [Page 9] + +RFC 3581 Symmetric Response Routing August 2003 + + +9.4. Requirements for a Long Term Solution + + From [5], any UNSAF proposal must provide: + + Identify requirements for longer term, sound technical solutions + -- contribute to the process of finding the right longer term + solution. + + The brittleness described in Section 9.3 has led us to the following + requirements for a long term solution: + + The client should not need to specify its address. Registrations and + record routing require the client to specify the address at which + it should receive requests. A sound technical solution should + allow a client to explicitly specify that it wants to receive + incoming requests on the connection over which the outgoing + request was sent. In this way, the client does not need to + specify its address. + + The solution must deal with clusters of servers. In many + commercially deployed SIP systems, there will be multiple servers, + each at different addresses and ports, handling incoming requests + for a client. The solution must explicitly consider this case. + + The solution must not require increases in network load. There + cannot be a penalty for a sound technical solution. + +9.5. Issues with Existing NAPT Boxes + + From [5], any UNSAF proposal must provide: + + Discussion of the impact of the noted practical issues with + existing, deployed NA[P]Ts and experience reports. + + To our knowledge, at the time of writing, there is only very limited + usage of this specification for address fixing. Therefore, no + specific practical issues have been raised. + +10. Acknowledgements + + The authors would like to thank Rohan Mahy and Allison Mankin for + their comments and contributions to this work. + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 10] + +RFC 3581 Symmetric Response Routing August 2003 + + +11. References + +11.1. Normative References + + [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) + Extension Header Field for Registering Non-Adjacent Contacts", + RFC 3327, December 2002. + + [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - + Simple Traversal of User Datagram Protocol (UDP) Through Network + Address Translators (NATs)", RFC 3489, March 2003. + +11.2. Informative References + + [5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral + Self-Address Fixing (UNSAF) Across Network Address Translation", + RFC 3424, November 2002. + + [6] Mahy, R., "Requirements for Connection Reuse in the Session + Initiation Protocol (SIP)", Work in Progress. + +12. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 11] + +RFC 3581 Symmetric Response Routing August 2003 + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +13. Authors' Addresses + + Jonathan Rosenberg + dynamicsoft + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + Phone: +1 973 952-5000 + EMail: jdrosen@dynamicsoft.com + URI: http://www.jdrosen.net + + + Henning Schulzrinne + Columbia University + M/S 0401 + 1214 Amsterdam Ave. + New York, NY 10027 + US + + EMail: schulzrinne@cs.columbia.edu + URI: http://www.cs.columbia.edu/~hgs + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 12] + +RFC 3581 Symmetric Response Routing August 2003 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 13] + |