Network Working Group M. Petit-Huguenin Internet-Draft 8x8, Inc. Intended status: Standards Track March 4, 2007 Expires: September 5, 2007 Preventing IP Fragmentation in Responses for the Session Initiation Protocol (SIP) draft-petithuguenin-sip-fragmentation-responses-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract There is limited support to prevent IP fragmentation when using a UDP or Datagram Transport Layer Security (DTLS) transport with the Session Initiation Protocol (SIP). This document describes an extension to prevent fragmentation in SIP responses. Petit-Huguenin Expires September 5, 2007 [Page 1] Internet-Draft IP fragmentation in SIP March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 4. Detailed Processing Rules . . . . . . . . . . . . . . . . . . 4 4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4 4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. Header Field Parameters . . . . . . . . . . . . . . . . . 6 6.2. Header Field . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Response Code . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Norminative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Petit-Huguenin Expires September 5, 2007 [Page 2] Internet-Draft IP fragmentation in SIP March 2007 1. Introduction [RFC3261] section 18.1.1 presents a simple algorithm to prevent fragmentation in the response, by sending the request over a congestion controlled transport protocol (e.g. TCP) if the size of the packet is larger than the MTU. The problem is that it is difficult to calculate the size of the packets that will be received from the size of the packet sent so the algorithm simply presumes that the response will be 200 bytes bigger than the request. The real size of the packet can be lower than this, and perhaps small enough to do not mandate the use of TCP, or can be higher than this and then resulting in unexpected fragmentation. [I-D.jennings-sip-dtls] describes how to use DTLS [RFC4347] over SIP and states that "[t]he normal rules for sending a request over UDP in RFC 3261 apply to sending over DTLS." This means that the same problem exists when evaluating if a SIP transaction should use DTLS or TLS. The fundamental assumption for this extension is that a SIP server (proxy or UAS) is capable to evaluate the number of bytes it will increase or decrease the size of the response received before forwarding it. If the proxy stores this value in the Via header, and all the other proxies on the path to the endpoint are also doing this, then the UAS will be able to evaluate if the response will be fragmented when sent back by this proxy. 2. Terminology 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 [RFC2119]. 3. Overview of Operation The protocol works by adding one, two or three parameters on each Via header field. The first parameter, "delta", contains a negative or positive value that indicates the number of bytes that will be added or removed when traversing this network element. It also signals that this element is supporting this specification. The second parameter, "mtu", contains the MTU for the network element that added the Via. This parameter is added only when UDP or DTLS is used. By walking through the Via list, an UAS supporting this specification can find which network element needs to switch to a congestion Petit-Huguenin Expires September 5, 2007 [Page 3] Internet-Draft IP fragmentation in SIP March 2007 controlled transport protocol to prevent IP fragmentation. If it is the case, the UAS sends a 6XX Congestion Control response with a Target header that is used to propagate the response to the chosen network element. The network element then resends the request by using a congestion controlled transport protocol. The protocol also adds the size of the response in the 6XX Congestion Control response, so each element can evaluate on the second try if the congestion controlled transport needs to be used. 4. Detailed Processing Rules 4.1. UAC Behavior When an UAC sends over any protocol a request that is not the result of a 6XX Congestion Control response, it MUST add a delta parameter equal to 0 to the Via header field. When sending the request over UDP or DTLS, an UAC MUST also add a mtu parameter with a value equal to the path MTU (or 1500 if the MTU is unknown) to the Via header field. For other protocols the UAC MUST NOT add the mtu parameter to the Via header field. The rules described in section 18.1.1 of RFC 3261 are used to choose if the request is sent over UDP or DTLS or a [RFC2914] congestion controlled transport. When an UAC receives a 6XX Congestion Control response, it checks if the response was received from the UDP or DTLS transport. If not, then an element did not follow this specification and the branch MUST be retried with the same protocol but without the delta and mtu Via parameters defined by this specification. If the response was received over the UDP or DTLS transport, then the branch MUST be retried, but this time by using a [RFC2914] congestion controlled transport. This can be done by applying again the [RFC3263] algorithm, but this time by excluding UDP and DTLS from the list of supported protocols. The new request must have a Via header field with a different branch parameter, a delta parameter equal to 0, no mtu parameter and a size parameter equals to the size value in the Target header field received in the 6XX Congestion Control response. 4.2. Proxy Behavior The proxy will remove and eventually add elements to the response that will be proxied and so will increase or decrease the size of the response by a number of bytes. In the majority of cases this size can be evaluated from the content of the request that will trigger the response and from the knowledge of the internal proxy processing. The proxy MUST evaluate this value before proxying the request and add this value in a delta parameter to the Via header field that will Petit-Huguenin Expires September 5, 2007 [Page 4] Internet-Draft IP fragmentation in SIP March 2007 be added as part of the proxy operation. If the top Via header field contains a size parameter then the delta value must be subtracted from this value and the result must be compared to the MTU. If the MTU is lower than the adjusted size then the UDP or DTLS transport MUST be excluded from the list of transports that can be used to proxy the request. The adjusted size value MUST be copied in size parameter of the new Via header field. If the request will be proxied using an UDP or DTLS transport then the path MTU (or 1500 if the path MTU is not known) MUST be added as a mtu parameter to the new Via header field. The mtu parameter MUST NOT be added for other protocols. When a proxy receives a 6XX Congestion Control response it MUST check for the presence of the Target header field. If the field contains the target value 0, then the response is for this proxy. If the response is for this proxy, then it checks that this response was received over the UDP or DTLS transport. If not, then an element did not follow this specification and the branch must be retried with the same protocol, but without the Via parameters defined by this specification. If the response is for this proxy and was received over the UDP or DTLS transport then the branch must be retried by using a congestion controlled transport. The new request must have a Via header field with a different branch parameter, a delta parameter, no mtu parameter and a size parameter equal to the size value in the Target header field received in the 6XX Congestion Control response. If the response is not for this proxy, the value of the Target header field MUST be decremented by one, the proxy MUST cancel all the eventual pending branches and MUST forward the response upstream. 4.3. UAS Behavior When an UAS received a request, it initializes a variable named target with the value 0 and a variable named size with the total size in bytes of the response that will be sent. If the UAS can send provisional responses the maximum size of all the possible responses is used instead. Then the UAS will execute the following steps on each Via header fields, starting from the top Via: o If the Via header field does not contain a delta parameter or if there is no other Via header field in the list then the process stops here. If the Target header was previously created then one of the hop must be replaced by a congestion controlled transport. A 6XX response must be created, the Target header must be added to this response and the response must be sent. o If the Via header field contains a mtu parameter that is lower than the value of the size variable, then this hop must be replaced by a congestion controlled transport. The current values Petit-Huguenin Expires September 5, 2007 [Page 5] Internet-Draft IP fragmentation in SIP March 2007 of the target and size parameters must be copied in a Target header. o The target variable value is incremented by one and the value of the delta parameter of the Via is added to the size variable value (the value is incremented or decremented depending on the sign of the delta parameter value). 5. Grammar This specification defines three new Via header field parameters, delta, mtu and size. The following ABNF [RFC4234] uses some definitions from [RFC3261]: via-params = via-ttl / via-maddr / via-received / via-branch / via- delta / via-mtu / via-size / via-extension via-delta = "delta" EQUAL ["-"] 1*DIGIT via-mtu = "mtu" EQUAL 1*DIGIT via-size = "size" EQUAL 1*DIGIT This specification defines also a new header field, Target. The following ABNF [RFC4234] uses some definitions from [RFC3261]: Target = "Target" HCOLON target-val LWS target-size target-val = 1*DIGIT target-size = 1*DIGIT 6. IANA Considerations This specification registers three new Via header field parameters according to the processes of [RFC3968], one new header field and one response code according to the processes of [RFC3261]. 6.1. Header Field Parameters Header field in which the parameter can appear: Via Name of the Parameter: delta Predefined values: no Petit-Huguenin Expires September 5, 2007 [Page 6] Internet-Draft IP fragmentation in SIP March 2007 RFC Reference: RFC XXXX: Header field in which the parameter can appear: Via Name of the Parameter: mtu Predefined values: no RFC Reference: RFC XXXX: Header field in which the parameter can appear: Via Name of the Parameter: size Predefined values: no RFC Reference: RFC XXXX: 6.2. Header Field RFC Number: RFC XXXX Header Field Name: Target Compact Form: none 6.3. Response Code Response Code Number: 6XX Default Reason Phrase: Congestion Control 7. Security Considerations TBD Petit-Huguenin Expires September 5, 2007 [Page 7] Internet-Draft IP fragmentation in SIP March 2007 8. Example Alice Atlanta Biloxi Bob | | | | |Request UDP | | | F1 |----------------->|Request TCP | | F2 |delta=0 mtu=1500 |====================>|Request UDP | F3 | |delta=100 |-------------------->| | | |delta=100 mtu=1500 | | | | | | | | 6XX Response| F4 | | 6XX Response|<--------------------| F5 | 6XX Response|<====================| Target: 2 1800| F6 |<-----------------| Target: 1 1800| | | Target: 0 1800| | | | | | | |Request TCP | | | F7 |=================>|Request TCP | | F8 |delta=0 size=1800 |====================>|Request TCP | F9 | |delta=100 size=1700 |====================>| | | |delta=100 size=1600 | | | | | Figure 1 F1: The UAC sends a request to the Atlanta proxy with a delta parameter equal to 0 added to the Via. As the transport chosen is UDP, a mtu parameter is added to the Via header. F2: The Atlanta proxy prepares to proxy the request to the Biloxi proxy, and evaluates the number of bytes that it would add or subtract to the response received from Biloxi for this request. It adds this value as a delta parameter to the Via of the proxied request. As the proxy chooses TCP, a congestion controlled transport, for the proxied request it does not add any mtu parameter to the Via header. F3: The Biloxi proxy prepares to proxy the request to the UAS, and evaluate the number of bytes that it would add or subtract to the response received from the UAS for this request. It adds this value as a delta parameter to the Via of the proxied request. As the proxy choose UDP as transport for the proxied request, it adds a mtu parameter to the Via header. F4: The UAS evaluates the size of the response that will be sent and finds a value of 1600 bytes. It initializes the target variable to 0 and the size variable to the size of the response so we have target=0 and size=1600. The UAS then looks at the first Via and find a mtu value that is lower than the current size value, so it copies the target and size variables in the Target header (Target: 0 1600). It then adds the delta value to the size variable and Petit-Huguenin Expires September 5, 2007 [Page 8] Internet-Draft IP fragmentation in SIP March 2007 increments the target variable so we now have target=1 and size=1700. The UAS then looks at the second Via header and finds no mtu parameter. It then adds the delta value to the size variable and increments the target variable so we now have target=2 and size=1800. The UAS then looks at the third Via header and finds a mtu value that is lower than the current size variable so it copies the target and size values in the Target header (Target: 2 1800). There is no other Via in the list and there was at least one mtu too small in the list so the UAS creates a 6XX response, adds the Target header field on it and sends it back to the Biloxi proxy. F5: The Biloxi proxy receives the 6XX response, checks that the target value in the Target header is different than 0, cancels all the eventual branches, and decrements the target value in the Target header field before forwarding the response to the Atlanta proxy. F6: The Atlanta proxy receives the 6XX response, checks that the target value in the Target header is different than 0, cancels all the eventual branches and decrements the target value in the Target header field before forwarding the response to the UAC. F7: The Alice UAC receives the 6XX response and re-executes the RFC3263 algorithm, but this time by excluding UDP from the list of supported transports. The same request is then sent over the selected transport with a Via header containing a delta parameter equal to 0 and with a size parameter equals to the size value received in the Target parameter of the 6XX response. F8: The Atlanta proxy prepares to proxy the request to the Biloxi proxy, and evaluates the number of bytes that it would add or subtract to the response received from Biloxi for this request. It adds this value as a delta parameter to the Via of the proxied request. The proxy also looks at the top Via and finds that there is a size parameter on it. It subtracts the delta value that was just calculated and as the value is higher than the MTU, UDP is excluded from the list of transports selected by the RFC 3263 algorithm. As the proxy chooses TCP, a congestion controlled transport, for the proxied request it does not add any mtu parameter to the Via header. The proxy also adds the modified size in the new Via. F9: The Biloxi proxy prepares to proxy the request to the Biloxi proxy, and evaluates the number of bytes that it would add or subtract to the response received from the UAS for this request. It adds this value as a delta parameter to the Via of the proxied request. The proxy also looks at the top Via and finds that there is a size parameter on it. It subtract the delta value that was just calculated and as the value is higher than the MTU, UDP is excluded from the list of transports selected by the RFC 3263 algorithm. As the proxy chooses TCP, a congestion controlled transport, for the proxied request it does not add any mtu Petit-Huguenin Expires September 5, 2007 [Page 9] Internet-Draft IP fragmentation in SIP March 2007 parameter to the Via header. The proxy also adds the modified size in the new Via. 9. Acknowledgements Internal versions of this document were reviewed by Patrice Bruno, Lee Hong, Garth Judge, Suhas Joshi, Jim Kleck, Eric Lin, Jason Liu, Vadim Tsyganok and Qing Zhao. 10. Norminative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC3261] 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. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [I-D.jennings-sip-dtls] Jennings, C. and N. Modadugu, "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", draft-jennings-sip-dtls-03 (work in progress), February 2007. Petit-Huguenin Expires September 5, 2007 [Page 10] Internet-Draft IP fragmentation in SIP March 2007 Author's Address Marc Petit-Huguenin 8x8, Inc. 3151 Jay Street Santa Clara, CA 95054 US Phone: +1 408 654 0875 Email: marc@8x8.com Petit-Huguenin Expires September 5, 2007 [Page 11] Internet-Draft IP fragmentation in SIP March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Petit-Huguenin Expires September 5, 2007 [Page 12]