idnits 2.17.1 draft-ietf-sip-compression-02.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 12 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 140: '...at supports SigComp MUST implement the...' RFC 2119 keyword, line 150: '... SHOULD compress the request using SigComp as defined in [2]....' RFC 2119 keyword, line 152: '... URI, the request SHOULD be compressed...' RFC 2119 keyword, line 155: '... A client MUST NOT send a compressed...' RFC 2119 keyword, line 160: '...ion compressed, this client SHOULD add...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 462 has weird spacing: '.... Price et al...' -- 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 (October 29, 2002) is 7821 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. '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 (~~), 4 warnings (==), 4 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-ietf-sip-compression-02.txt 6 October 29, 2002 7 Expires: April 2003 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 SigComp implementations for SIP ..................... 4 43 4 Sending a Request to a Server ....................... 4 44 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ....... 5 45 5 Sending a Response to a Client ...................... 6 46 6 Double Record-Routing ............................... 7 47 7 Error Situations .................................... 7 48 8 Augmented BNF ....................................... 7 49 9 Example ............................................. 8 50 10 Security Considerations ............................. 11 51 11 Acknowledges ........................................ 11 52 12 Authors' Addresses .................................. 11 53 13 Normative References ................................ 11 54 14 Informative References .............................. 11 56 1 Introduction 58 A SIP [1] client sending a request to a SIP server typically performs 59 a DNS lookup for the domain name of the server. When NAPTR [3] or SRV 60 [4] records are available for the server, the client can specify the 61 type of service it wants. The service in this context is the 62 transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP 63 server that supports, for instance, three different transport 64 protocols, will have three different DNS entries. 66 Since it is foreseen that the number of transport protocols supported 67 by a particular application layer protocol is not going to grow 68 dramatically, having a DNS entry per transport seems like a scalable 69 enough solution. 71 However, sometimes it is necessary to include new layers between the 72 transport protocol and the application layer protocol. Examples of 73 these layers are transport layer security and compression. If DNS was 74 used to discover the availability of these layers for a particular 75 server, the number of DNS entries needed for that server would grow 76 dramatically. 78 A server that, for example, supported TCP and SCTP as transports, TLS 79 for transport security and SigComp for signaling compression, would 80 need the 8 DNS entries listed below: 82 1. TCP, no security, no compression 84 2. TCP, no security, SigComp 86 3. TCP, TLS, no compression 88 4. TCP, TLS, SigComp 90 5. SCTP, no security, no compression 92 6. SCTP, no security, SigComp 94 7. SCTP, TLS, no compression 96 8. SCTP, TLS, SigComp 98 It is clear that this way of using DNS is not scalable. Therefore, an 99 application layer mechanism to express support of signalling 100 compression is needed. 102 Note that for historical reasons both HTTP and SIP use a 103 different port for TLS on top of TCP than for TCP alone, 104 although at present, this solution is not considered 105 scalable any longer. 107 A SIP element that supports compression will need to be prepared to 108 receive compressed and uncompressed messages on the same port. It 109 will perform demultiplexing based on the cookie in the topmost bits 110 of every compressed message. 112 2 Overview of operation 114 There are two types of SIP messages; SIP requests and SIP responses. 115 Clients send SIP requests to the host part of a URI and servers send 116 responses to the host in the sent-by parameter of the Via header 117 field. 119 We define two parameters, one for SIP URIs and the other for the Via 120 header field. The format of both parameters is the same, as shown in 121 the examples below: 123 sip:alice@atlanta.com;comp=sigcomp 124 Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp 126 The presence of this parameter (comp=sigcomp) in a URI indicates that 127 the request has to be compressed using SigComp, as defined in [2]. 128 The presence of comp=sigcomp in a Via header field indicates that the 129 response has to be compressed using SigComp. 131 Therefore, the presence of comp=sigcomp indicates that the SIP entity 132 identified by the URI or by the Via header field supports SigComp and 133 is willing to receive compressed messages. Having comp=sigcomp mean 134 "willingness" as well as "support" allows the receiver of a SIP 135 message to influence the decision of whether or not to use SigComp at 136 a given time. 138 3 SigComp implementations for SIP 140 Every SIP implementation that supports SigComp MUST implement the 141 procedures described in this document. 143 4 Sending a Request to a Server 145 A request is sent to the host part of a URI. This URI, referred to as 146 the next-hop URI, is the Request-URI of the request or an entry in 147 the Route header field. 149 If the next-hop URI contains the parameter comp=sigcomp, the client 150 SHOULD compress the request using SigComp as defined in [2]. 152 If the next-hop URI is a SIPS URI, the request SHOULD be compressed 153 before it is passed to the TLS layer. 155 A client MUST NOT send a compressed request to a server if it does 156 not know whether or not the server supports SigComp. 158 Regardless of whether the request is sent compressed or not, if a 159 client would like to receive subsequent requests within the same 160 dialog in the UAS->UAC direction compressed, this client SHOULD add 161 the parameter comp=sigcomp to the URI in the Contact header field if 162 it is a user agent client. If the client is a proxy, it SHOULD add 163 the parameter comp=sigcomp to its URI in the Record-Route header 164 field. 166 If a user agent client sends a compressed request, it SHOULD add the 167 parameter comp=sigcomp to the URI in the Contact header field. If a 168 proxy that Record-Routes sends a compressed request, it SHOULD add 169 comp=sigcomp to its URI in the Record-Route header field. 171 If a client sends a compressed request, it SHOULD add the parameter 172 comp=sigcomp to the topmost entry of the Via header field. 174 If a client does not know whether or not the server supports SigComp, 175 but in case the server supported it, it would like to receive 176 compressed responses, this client SHOULD add the parameter 177 comp=sigcomp to the topmost entry of the Via header field. The 178 request, however, as stated above, will not be compressed. 180 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp 182 For requests within a dialog, a next-hop URI with the comp=sigcomp 183 parameter is obtained from a Record-Route header field when the 184 dialog is established. A client sending a request outside a dialog 185 can also obtain SIP URIs with comp=sigcomp in a Contact header field 186 in a 3xx or 485 response to the request. 188 However, clients establishing a session will not typically be willing 189 to wait until the dialog is established in order to begin compressing 190 messages. One of the biggest gains that SigComp can bring to SIP is 191 the ability to compress the initial INVITE of a dialog, when the user 192 is waiting for the session to be established. Therefore, clients need 193 a means to obtain a comp=sigcomp URI from their outbound proxy before 194 the user decides to establish a session. 196 One solution to this problem is manual configuration. However, 197 sometimes it is necessary to have clients configured in an automatic 198 fashion. Unfortunately, current mechanisms for SIP client 199 configuration (e.g., using DHCP [5]) do not allow to provide the 200 client with URI parameters. In this case, the client SHOULD send an 201 uncompressed OPTIONS request to its outbound proxy. The outbound 202 proxy can provide an alternative SIP URI with the comp=sigcomp 203 parameter in a Contact header field in a 200 OK response to the 204 OPTIONS. The client can use this URI for subsequent requests that are 205 sent through the same outbound proxy using compression. 207 RFC3261 [1] does not define how a proxy should respond to an OPTIONS 208 request addressed to itself. It only describes how servers respond to 209 OPTIONS addressed to a particular user. Section 11.2 of RFC3261 says: 211 Contact header fields MAY be present in a 200 (OK) response 212 and have the same semantics as in a 3xx response. That is, 213 they may list a set of alternative names and methods of 214 reaching the user. 216 We extend this behavior to proxy servers responding to OPTIONS 217 addressed to them. They MAY list a set of alternative URIs to contact 218 the proxy. 220 Note that receiving incoming requests (even initial INVITEs) 221 compressed is not a problem, since user agents can REGISTER a SIP URI 222 with comp=sigcomp in their registrar. All incoming requests for the 223 user will be sent to this SIP URI using compression. 225 5 Sending a Response to a Client 227 A response is sent to the host in the sent-by parameter of the Via 228 header field. If the topmost Via header field contains the parameter 229 comp=sigcomp, the response SHOULD be compressed. Otherwise, the 230 response MUST NOT be compressed. 232 In order to avoid asymmetric compression (i.e., two SIP entities 233 exchanging compressed requests in one direction and uncompressed 234 requests in the other direction) proxies need to rewrite their 235 Record-Route entries in the responses. A proxy performing Record- 236 Route inspects the Record-Route header field in the response and the 237 Contact header field in the request that triggered this response (see 238 example in Section 9). It looks for the URI of the next upstream 239 (closer to the user agent client) hop in the route set. If this URI 240 contains the parameter comp=sigcomp, the proxy SHOULD add 241 comp=sigcomp to its entry in the Record-Route header field. If this 242 URI does not contain the parameter comp=sigcomp, the proxy SHOULD 243 remove comp=sigcomp (if it is present) from its entry in the Record- 244 Route header field. 246 The same way, a user agent server SHOULD add comp=sigcomp to the 247 Contact header field of the response if the URI of the next upstream 248 hop in the route set contained the parameter comp=sigcomp. 250 6 Double Record-Routing 252 Although proxies usually add zero or one Record-Route entries to a 253 particular request, some proxies add two of them to avoid Record- 254 Route rewriting. A typical example of double Record-Routing is a SIP 255 proxy that acts as a firewall between two networks. Depending on 256 which network a request comes from, it will be received on a 257 different interface by the proxy. The proxy adds one Record-Route 258 entry for one interface and a second one for the other interface. 259 This way, the proxy does not need to rewrite the Record-Route header 260 field on the response. 262 Proxies that receive compressed messages from one side of the dialog 263 (e.g., upstream) and uncompressed messages from the other side (e.g., 264 downstream) MAY use the mechanism described above. 266 If a proxy detects that the next-hop proxy for a request is the proxy 267 itself and that the request will not be sent through the network, the 268 proxy MAY choose not to compress the request even if the URI contains 269 the comp=sigcomp parameter. 271 7 Error Situations 273 If a compressed SIP request arrives to a SIP server that does not 274 understand SigComp, the server will not have any means to indicate 275 the error to the client. The message will be impossible to parse, and 276 there will be no Via header field indicating an address to send the 277 error response. 279 If a SIP client sends a compressed request and the client transaction 280 times out without having received any response, the client SHOULD 281 retry the same request without using compression. If the compressed 282 request was sent over a TCP connection, the client SHOULD close that 283 connection and open a new one to send the uncompressed request. 284 Otherwise the server would not be able to detect the beginning of the 285 new message. 287 8 Augmented BNF 289 This section provides the augmented Backus-Naur Form (BNF) of both 290 parameters described above. 292 The compression URI parameter is a "uri-parameter", as defined by the 293 SIP ABNF (Section 25.1 of [1]): 295 compression-param = "comp=" ("sigcomp" / other-compression) 296 other-compression = token 298 The Via compression parameter is a "via-extension", as defined by the 299 SIP ABNF (Section 25.1 of [1]): 301 via-compression = "comp" EQUAL ("sigcomp" / other-compression) 302 other-compression = token 304 9 Example 306 The following example illustrates the use of the parameters defined 307 above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake 308 between a UAC and a UAS through two proxies. Proxy P1 does not 309 Record-Route but proxy P2 does. Both proxies support compression, but 310 they do not use it by default. 312 UAC P1 P2 UAS 314 |(1)INVITE(c) | | | 315 |------------>| (2) INVITE | | 316 | |------------>| (3) INVITE | 317 | | |------------>| 318 | | | (4) 200 OK | 319 | | (5) 200 OK |<------------| 320 |(6)200 OK(c) |<------------| | 321 |<------------| | | 322 | | (7)ACK(c) | | 323 |-------------------------->| (8) ACK | 324 | | |------------>| 325 | | | | 326 | | | | 328 Figure 1: INVITE transaction through two proxies 330 Messages (1), (6) and (7) are compressed (c). 332 We provide a partial description of the messages involved in this 333 call flow below. Only some parts of each message are shown, namely 334 the Method name, the Request-URI and the Via, Route, Record-Route and 335 Contact header fields. We have not used a correct format for these 336 header fields. We have rather focus on the contents of the header 337 fields and on the presence (or absence) of the "comp=sigcomp" 338 parameter. 340 (1) INVITE UAS 341 Via: UAC;comp=sigcomp 342 Route:P1;comp=sigcomp 343 Contact: UAC;comp=sigcomp 345 P1 is the outbound proxy of the UAC, and it supports SigComp. The UAC 346 is configured to send compressed traffic to P1, and therefore, it 347 compresses the INVITE (1). In addition, the UAC wants to receive 348 future requests and responses for this dialog compressed. Therefore, 349 it adds the comp=Sigcomp parameter to the Via and to the Contact 350 header fields. 352 (2) INVITE UAS 353 Via: P1 354 Via: UAC;comp=sigcomp 355 Route:P2 356 Contact: UAC;comp=sigcomp 358 P1 forwards the INVITE (2) to P2. P1 does not use compression by 359 default, so it sends the INVITE uncompressed to P2. 361 (3) INVITE UAS 362 Via: P2 363 Via: P1 364 Via: UAC;comp=sigcomp 365 Record-Route:P2 366 Contact: UAC;comp=sigcomp 368 P2 forwards the INVITE (3) to the UAS. P2 supports compression, but 369 it does not use it by default. Therefore, it sends the INVITE 370 uncompressed. P2 wishes to remain in the signalling path and 371 therefore it Record-Routes. 373 (4) 200 OK 374 Via: P2 375 Via: P1 376 Via: UAC;comp=sigcomp 377 Record-Route:P2 378 Contact: UAS 380 The UAS generates a 200 OK response and sends it to the host in the 381 topmost Via, which is P2. 383 (5) 200 OK 384 Via: P1 385 Via: UAC;comp=sigcomp 386 Record-Route:P2;comp=sigcomp 387 Contact: UAS 389 P2 receives the 200 OK response. P2 Record-Routed, so it inspects the 390 Route set for this dialog. For requests from the UAS towards the UAC 391 (the opposite direction than the first INVITE), the next hop will be 392 the Contact header field of the INVITE, because P1 did not Record- 393 Route. That Contact identified the UAC: 395 Contact: UAC;comp=sigcomp 397 Since the UAC wants to receive compressed requests (Contact of the 398 INVITE), P2 assumes that the UAC would also like to send compressed 399 requests (Record-Route of the 200 OK). Therefore, P2 modifies its 400 entry in the Record-Route header field of the 200 OK (5). In the 401 INVITE (3), P2 did not used the comp=sigcomp parameter. Now it adds 402 it in the 200 OK (5). This will allow the UAC sending compressed 403 requests within this dialog. 405 (6) 200 OK 406 Via: UAC;comp=sigcomp 407 Record-Route:P2;comp=sigcomp 408 Contact: UAS 410 P1 sends the 200 OK (6) compressed to the UAC because the Via header 411 field contained the comp=sigcomp parameter. 413 (7) ACK UAS 414 Via: UAC;comp=sigcomp 415 Route:P2;comp=sigcomp 416 Contact: UAC;comp=sigcomp 418 The UAC sends the ACK (7) compressed directly to P2 (P1 did not 419 Record-Route). 421 (8) ACK UAS 422 Via: P2 423 Via: UAC;comp=sigcomp 424 Contact: UAC;comp=sigcomp 426 P2 sends the ACK (8) uncompressed to the UAS. 428 10 Security Considerations 430 A SIP entity receiving a compressed message has to decompress it and 431 to parse it. This requires slightly more processing power than only 432 parsing a message. This implies that a denial of service attack using 433 compressed messages would be slightly worse than an attack with 434 uncompressed messages. 436 An attacker inserting the parameter comp=sigcomp in a SIP message 437 could make a SIP entity send compressed messages to another SIP 438 entity that did not support SigComp. Appropriate integrity mechanisms 439 should be used to avoid this attack. 441 11 Acknowledges 443 Allison Mankin, Jonathan Rosenberg and Miguel Angel Garcia provided 444 valuable comments on this memo. 446 12 Authors' Addresses 448 Gonzalo Camarillo 449 Ericsson 450 Advanced Signalling Research Lab. 451 FIN-02420 Jorvas 452 Finland 453 electronic mail: Gonzalo.Camarillo@ericsson.com 455 13 Normative References 457 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 458 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 459 initiation protocol," RFC 3261, Internet Engineering Task Force, June 460 2002. 462 [2] R. Price et al. , "Signaling compression," Internet Draft, 463 Internet Engineering Task Force, June 2002. Work in progress. 465 14 Informative References 467 [3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) 468 DNS resource record," RFC 2915, Internet Engineering Task Force, 469 Sept. 2000. 471 [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying 472 the location of services (DNS SRV)," RFC 2782, Internet Engineering 473 Task Force, Feb. 2000. 475 [5] H. Schulzrinne, "DHCP option for SIP servers," Internet Draft, 476 Internet Engineering Task Force, Mar. 2002. Work in progress. 478 Full Copyright Statement 480 Copyright (c) The Internet Society (2002). All Rights Reserved. 482 This document and translations of it may be copied and furnished to 483 others, and derivative works that comment on or otherwise explain it 484 or assist in its implementation may be prepared, copied, published 485 and distributed, in whole or in part, without restriction of any 486 kind, provided that the above copyright notice and this paragraph are 487 included on all such copies and derivative works. However, this 488 document itself may not be modified in any way, such as by removing 489 the copyright notice or references to the Internet Society or other 490 Internet organizations, except as needed for the purpose of 491 developing Internet standards in which case the procedures for 492 copyrights defined in the Internet Standards process must be 493 followed, or as required to translate it into languages other than 494 English. 496 The limited permissions granted above are perpetual and will not be 497 revoked by the Internet Society or its successors or assigns. 499 This document and the information contained herein is provided on an 500 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 501 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 502 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 503 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 504 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.