idnits 2.17.1 draft-camarillo-sip-compression-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '... SHOULD compress the request using Sigcomp as defined in [2]. The...' RFC 2119 keyword, line 153: '... A client MUST NOT send a compressed...' RFC 2119 keyword, line 158: '...ses, this client SHOULD add the parame...' RFC 2119 keyword, line 164: '...sed, this client SHOULD add the parame...' RFC 2119 keyword, line 166: '...t is a proxy, it SHOULD add the parame...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 28, 2002) is 7966 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Obsolete informational reference (is this intentional?): RFC 2915 (ref. '3') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo 4 Ericsson 5 draft-camarillo-sip-compression-01.txt 6 May 28, 2002 7 Expires: November 2002 9 Compressing the Session Initiation Protocol 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a mechanism to signal that compression is 35 desired for one or more SIP messages. It also states when it is 36 appropriate to send compressed SIP messages to a SIP entity. 38 Table of Contents 40 1 Introduction ........................................ 3 41 2 Overview of operation ............................... 4 42 3 Sending a Request to a Server ....................... 4 43 4 Sending a Response to a Client ...................... 5 44 5 Error Situations .................................... 5 45 6 Augmented BNF ....................................... 6 46 7 Example ............................................. 6 47 8 Security Considerations ............................. 9 48 9 Acknowledges ........................................ 9 49 10 Authors' Addresses .................................. 9 50 11 Normative References ................................ 10 51 12 Informative References .............................. 10 53 1 Introduction 55 A SIP [1] client sending a request to a SIP server typically performs 56 a DNS lookup for the domain name of the server. When NAPTR [3] or SRV 57 [4] records are available for the server, the client can specify the 58 type of service it wants. The service in this context is the 59 transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP 60 server that support, for instance, three different transport 61 protocols, will have three different DNS entries. 63 Since it is foreseen that the number of transport protocols supported 64 by a particular application layer protocol is not going to grow 65 dramatically, having a DNS entry per transport seems like a scalable 66 enough solution. 68 However, sometimes it is necessary to include new layers between the 69 transport protocol and the application layer protocol. Examples of 70 these layers are transport layer security and compression. If DNS was 71 used to discover the availability of these layers for a particular 72 server, the number of DNS entries needed for that server would grow 73 dramatically. 75 A server that, for example, supported TCP and SCTP as transports, TLS 76 for transport security and Sigcomp for signaling compression, would 77 need the 8 DNS entries listed below: 79 1. TCP, no security, no compression 81 2. TCP, no security, SigComp 83 3. TCP, TLS, no compression 85 4. TCP, TLS, SigComp 87 5. SCTP, no security, no compression 89 6. SCTP, no security, SigComp 91 7. SCTP, TLS, no compression 93 8. SCTP, TLS, SigComp 95 It is clear that this way of using DNS is not scalable. Therefore, an 96 application layer mechanism to express support of signalling 97 compression is needed. 99 Note that for historical reasons both HTTP and SIP use a 100 different port for TLS on top of TCP than for TCP alone, 101 although at present this solution is not considered 102 scalable any longer. 104 A SIP element that supports compression will need to be prepared to 105 receive compressed and uncompressed messages on the same port. It 106 will perform demultiplexing based on the cookie in the topmost bits 107 of every compressed message. 109 2 Overview of operation 111 There are two types of SIP messages; SIP requests and SIP responses. 112 Clients send SIP requests to the host part of a URI and servers send 113 responses to the host in the sent-by parameter of the Via header 114 field. 116 We define two parameters, one for SIP URIs and the other for the Via 117 header field. The format of both parameters is the same, as shown in 118 the examples below: 120 sip:alice@atlanta.com;comp=sigcomp 121 Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp 123 The presence of this parameter in a URI indicates that the request 124 has to be compressed using Sigcomp, as defined in [2]. The presence 125 of comp=sigcomp in a Via header field indicates that the response has 126 to be compressed using Sigcomp. 128 Note that, as stated in , every implementation that 129 supports Sigcomp needs to implement the static dictionary 130 for SIP and SDP. 132 3 Sending a Request to a Server 134 A request is sent to the host part of a URI. This URI, referred to as 135 the next-hop URI, is the Request-URI of the request or an entry in 136 the Route header field. 138 If the next-hop URI contains the parameter comp=sigcomp, the client 139 SHOULD compress the request using Sigcomp as defined in [2]. The 140 next-hop URI can contain such a parameter due to a number of reasons: 142 o The URI was obtained from a Record-Route header field when the 143 dialog was established. 145 o The URI was previously registered in a registrar using a 146 REGISTER request. 148 o The URI was obtained from a Contact header field in a 3xx or 149 485 response to the request. 151 o The URI was obtained out of band or statically configured. 153 A client MUST NOT send a compressed request to a server if it does 154 not know whether or not the server supports Sigcomp. 156 If a client does not know whether or not the server supports Sigcomp, 157 but in case the server supported it, it would like to receive 158 compressed responses, this client SHOULD add the parameter 159 comp=sigcomp to the topmost entry of the Via header field. The 160 request, however, as stated above, will not be compressed. 162 Regardless of whether the request is sent compressed or not, if a 163 client would like to receive subsequent requests within the same 164 dialog compressed, this client SHOULD add the parameter comp=sigcomp 165 to the URI in the Contact header field if it is a user agent client. 166 If the client is a proxy, it SHOULD add the parameter comp=sigcomp to 167 its URI in the Record-Route header field. 169 4 Sending a Response to a Client 171 A response is sent to the host in the sent-by parameter of the Via 172 header field. If the topmost Via header field contains the parameter 173 comp=sigcomp, the response SHOULD be compressed. Otherwise, the 174 response MUST NOT be compressed. 176 A proxy performing Record-Route inspects the Record-Route header 177 field in the response and the Contact header field in the request 178 that triggered this response (see example in Section 7). It looks for 179 the URI of the next upstream (closer to the user agent client) hop in 180 the route set. If this URI contains the parameter comp=sigcomp, the 181 proxy SHOULD add comp=sigcomp to its entry in the Record-Route header 182 field. 184 The same way, a user agent server SHOULD add comp=sigcomp to the 185 Contact header field of the response if the URI of the next upstream 186 hop in the route set contained the parameter comp=sigcomp. 188 5 Error Situations 190 If a compressed SIP request arrives to a SIP server that does not 191 understand SigComp, the server will not have any means to indicate 192 the error to the client. The message will be impossible to parse, and 193 there will be no Via header field indicating an address to send the 194 error response. 196 If a SIP client sends a compressed request and the client transaction 197 times out without having received any response, the client SHOULD 198 retry the same request without using compression. If the compressed 199 request was sent over a TCP connection, the client SHOULD close that 200 connection and open a new one to send the uncompressed request. 201 Otherwise the server would not be able to detect the beginning of the 202 new message. 204 6 Augmented BNF 206 This section provides the augmented Backus-Naur Form (BNF) of both 207 parameters described above. 209 The compression URI parameter is a "uri-parameter", as defined by the 210 SIP ABNF (Section 25.1 of [1]): 212 compression-param = "comp=" ("sigcomp" / other-compression) 213 other-compression = token 215 The Via compression parameter is a "via-extension", as defined by the 216 SIP ABNF (Section 25.1 of [1]): 218 via-compression = "comp" EQUAL ("sigcomp" / other-compression) 219 other-compression = token 221 7 Example 223 The following example illustrates the use of the parameters defined 224 above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake 225 between a UAC and a UAS through two proxies. Proxy P1 does not 226 Record-Route but proxy P2 does. Both proxies support compression, but 227 they do not use it by default. 229 UAC P1 P2 UAS 231 |(1)INVITE(c) | | | 232 |------------>| (2) INVITE | | 233 | |------------>| (3) INVITE | 234 | | |------------>| 235 | | | (4) 200 OK | 236 | | (5) 200 OK |<------------| 237 |(6)200 OK(c) |<------------| | 238 |<------------| | | 239 | | (7)ACK(c) | | 240 |-------------------------->| (8) ACK | 241 | | |------------>| 242 | | | | 243 | | | | 245 Figure 1: INVITE transaction through two proxies 247 Messages (1), (6) and (7) are compressed (c). 249 We provide a partial description of the messages involved in this 250 call flow below. Only some parts of each message are shown, namely 251 the Method name, the Request-URI and the Via, Route, Record-Route and 252 Contact header fields. We have not used a correct format for these 253 header fields. We have rather focus on the contents of the header 254 fields and on the presence (or absence) of the "comp=sigcomp" 255 parameter. 257 (1) INVITE UAS 258 Via: UAC;comp=sigcomp 259 Route:P1;comp=sigcomp 260 Contact: UAC;comp=sigcomp 262 P1 is the outbound proxy of the UAC, and it supports Sigcomp. The UAC 263 is configured to send compressed traffic to P1, and therefore, it 264 compresses the INVITE (1). In addition, the UAC wants to receive 265 future requests and responses for this dialog compressed. Therefore, 266 it adds the comp=Sigcomp parameter to the Via and to the Contact 267 header fields. 269 (2) INVITE UAS 270 Via: P1 271 Via: UAC;comp=sigcomp 272 Route:P2 273 Contact: UAC;comp=sigcomp 275 P1 forwards the INVITE (2) to P2. P1 does not use compression by 276 default, so it sends the INVITE uncompressed to P2. 278 (3) INVITE UAS 279 Via: P2 280 Via: P1 281 Via: UAC;comp=sigcomp 282 Record-Route:P2 283 Contact: UAC;comp=sigcomp 285 P2 forwards the INVITE (3) to the UAS. P2 supports compression, but 286 it does not use it by default. Therefore, it sends the INVITE 287 uncompressed. P2 wishes to remain in the signalling path and 288 therefore it Record-Routes. 290 (4) 200 OK 291 Via: P2 292 Via: P1 293 Via: UAC;comp=sigcomp 294 Record-Route:P2 295 Contact: UAS 297 The UAS generates a 200 OK response and sends it to the host in the 298 topmost Via, which is P2. 300 (5) 200 OK 301 Via: P1 302 Via: UAC;comp=sigcomp 303 Record-Route:P2;comp=sigcomp 304 Contact: UAS 306 P2 receives the 200 OK response. P2 Record-Routed, so it inspects the 307 Route set for this dialog. For requests from the UAS towards the UAC 308 (the opposite direction than the first INVITE), the next hop will be 309 the Contact header field of the INVITE, because P1 did not Record- 310 Route. That Contact identified the UAC: 312 Contact: UAC;comp=sigcomp 314 Since the UAC wants to receive compressed requests (Contact of the 315 INVITE), P2 assumes that the UAC would also like to send compressed 316 requests (Record-Route of the 200 OK). Therefore, P2 modifies its 317 entry in the Record-Route header field of the 200 OK (5). In the 318 INVITE (3), P2 did not used the comp=sigcomp parameter. Now it adds 319 it in the 200 OK (5). This will allow the UAC sending compressed 320 requests within this dialog. 322 (6) 200 OK 323 Via: UAC;comp=sigcomp 324 Record-Route:P2;comp=sigcomp 325 Contact: UAS 327 P1 sends the 200 OK (6) compressed to the UAC because the Via header 328 field contained the comp=Sigcomp parameter. 330 (7) ACK UAS 331 Via: UAC;comp=sigcomp 332 Route:P2;comp=sigcomp 333 Contact: UAC;comp=sigcomp 335 The UAC sends the ACK (7) compressed directly to P2 (P1 did not 336 Record-Route). 338 (8) ACK UAS 339 Via: P2 340 Via: UAC;comp=sigcomp 341 Contact: UAC;comp=sigcomp 343 P2 sends the ACK (8) uncompressed to the UAS. 345 8 Security Considerations 347 A SIP entity receiving a compressed message has to decompress it and 348 to parse it. This requires slightly more processing power than only 349 parsing a message. This implies that a denial of service attack using 350 compressed messages would be slightly worse than an attack with 351 uncompressed messages. 353 An attacker inserting the parameter comp=sigcomp in a SIP message 354 could make a SIP entity send compressed messages to another SIP 355 entity that did not support Sigcomp. Appropriate integrity mechanisms 356 should be used to avoid this attack. 358 9 Acknowledges 360 Jonathan Rosenberg and Miguel Angel Garcia provided valuable comments 361 on this memo. 363 10 Authors' Addresses 364 Gonzalo Camarillo 365 Ericsson 366 Advanced Signalling Research Lab. 367 FIN-02420 Jorvas 368 Finland 369 electronic mail: Gonzalo.Camarillo@ericsson.com 371 11 Normative References 373 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 374 protocol," Internet Draft, Internet Engineering Task Force, Feb. 375 2002. Work in progress. 377 [2] R. Price, J. Rosenberg, C. Bormann, H. Hannu, and Z. Liu, 378 "Universal decompressor virtual machine (udvm)," Internet Draft, 379 Internet Engineering Task Force, Jan. 2002. Work in progress. 381 12 Informative References 383 [3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) 384 DNS resource record," RFC 2915, Internet Engineering Task Force, 385 Sept. 2000. 387 [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying 388 the location of services (DNS SRV)," RFC 2782, Internet Engineering 389 Task Force, Feb. 2000. 391 Full Copyright Statement 393 Copyright (c) The Internet Society (2002). All Rights Reserved. 395 This document and translations of it may be copied and furnished to 396 others, and derivative works that comment on or otherwise explain it 397 or assist in its implementation may be prepared, copied, published 398 and distributed, in whole or in part, without restriction of any 399 kind, provided that the above copyright notice and this paragraph are 400 included on all such copies and derivative works. However, this 401 document itself may not be modified in any way, such as by removing 402 the copyright notice or references to the Internet Society or other 403 Internet organizations, except as needed for the purpose of 404 developing Internet standards in which case the procedures for 405 copyrights defined in the Internet Standards process must be 406 followed, or as required to translate it into languages other than 407 English. 409 The limited permissions granted above are perpetual and will not be 410 revoked by the Internet Society or its successors or assigns. 412 This document and the information contained herein is provided on an 413 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 414 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 415 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 416 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 417 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.