idnits 2.17.1 draft-ietf-insipid-logme-marking-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 153 has weird spacing: '...orp.com p1.fo...' -- The document date (May 15, 2017) is 2537 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) == Missing Reference: 'RFCXXXX' is mentioned on line 979, but not defined == Unused Reference: 'RFC7206' is defined on line 1010, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7206 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Dawes 3 Internet-Draft Vodafone Group 4 Intended status: Standards Track C. Arunachalam 5 Expires: November 16, 2017 Cisco Systems 6 May 15, 2017 8 Marking SIP Messages to be Logged 9 draft-ietf-insipid-logme-marking-07 11 Abstract 13 SIP networks use signaling monitoring tools to diagnose user reported 14 problems and for regression testing if network or user agent software 15 is upgraded. As networks grow and become interconnected, including 16 connection via transit networks, it becomes impractical to predict 17 the path that SIP signaling will take between user agents, and 18 therefore impractical to monitor SIP signaling end-to-end. 20 This document describes an indicator for the SIP protocol which can 21 be used to mark signaling as of interest to logging. Such marking 22 will typically be applied as part of network testing controlled by 23 the network operator and not used in regular user agent signaling. 24 However, such marking can be carried end-to-end including the 25 originating and terminating SIP user agents, even if a session 26 originates and terminates in different networks. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 16, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4 65 3.1. Session-ID logme Parameter . . . . . . . . . . . . . . . 4 66 3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 4 67 3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 5 68 3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 5 69 3.4.1. To and From a User Device . . . . . . . . . . . . . . 5 70 3.4.2. To and From an External Network . . . . . . . . . . . 5 71 3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 5 72 3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 5 73 3.7. Marking Related Dialogs . . . . . . . . . . . . . . . . . 6 74 3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 8 75 4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 8 76 4.1. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. SIP Intermediaries . . . . . . . . . . . . . . . . . . . 8 78 4.2.1. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.2.1.1. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . 10 80 4.2.1.2. Signaling-only and SDP-Modifying Signaling-only . 10 81 4.2.1.3. Media Relay, Media Aware, Media Termination . . . 10 82 4.2.2. "Log me" Marker Processing . . . . . . . . . . . . . 11 83 4.2.2.1. Stateless processing . . . . . . . . . . . . . . 11 84 4.2.2.2. Stateful processing . . . . . . . . . . . . . . . 11 85 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.1. Missing "Log me" Marker in Dialog Being Logged . . . . . 18 87 5.2. "Log Me" Marker Appears Mid-Dialog . . . . . . . . . . . 19 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 6.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 19 90 6.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 19 91 6.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19 92 6.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 6.4.1. Personal Identifiers . . . . . . . . . . . . . . . . 20 94 6.4.2. Data Stored at SIP Intermediaries . . . . . . . . . . 20 95 6.4.3. Data Visible at Network Elements . . . . . . . . . . 21 96 6.4.4. Preventing Fingerprinting . . . . . . . . . . . . . . 21 97 6.4.5. Retaining Logs . . . . . . . . . . . . . . . . . . . 21 98 6.4.6. User Control of Logging . . . . . . . . . . . . . . . 21 99 6.4.7. Recommended Defaults . . . . . . . . . . . . . . . . 22 100 6.5. Data Protection . . . . . . . . . . . . . . . . . . . . . 22 101 7. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 22 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 103 8.1. Registration of the "logme" Parameter . . . . . . . . . . 22 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 106 9.2. Informative References . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 109 1. Introduction 111 When users experience problems with setting up sessions using SIP, 112 enterprise or service provider network operators need to identify 113 root cause by examining the SIP signaling. Also, when network or 114 user agent software or hardware is upgraded regression testing is 115 needed. Such diagnostics apply to a small proportion of network 116 traffic and can apply end-to-end, even if signaling crosses several 117 networks possibly belonging to several different network operators. 118 It may not be possible to predict the path through those networks in 119 advance, therefore a mechanism is needed to mark a session as being 120 of interest so that SIP entities along the signaling path can provide 121 diagnostic logging. [RFC8123] illustrates this motivating scenario. 122 This document describes a solution that meets the requirements for 123 such 'log me' marking of SIP signaling also defined in [RFC8123]. 125 This document defines a new header field parameter "logme" for the 126 "Session-ID" header field. Implementations of this document MUST 127 implement session identity specified in [RFC7989]. 129 2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119], except that 134 rather than describing interoperability requirements, they are used 135 to describe requirements to be satisfied by the "log me" marking 136 solution. 138 3. "Log Me" Marking Protocol Aspects 140 3.1. Session-ID logme Parameter 142 Logging is most effective when it is applied end-to-end for a 143 communication session. This ability requires "log me" marker to be 144 passed through SIP intermediaries. Session-ID header defined in 145 ([RFC7989]) was chosen to carry the "log me" marker as a "logme" 146 parameter since the session identifier is passed through SIP B2BUAs 147 or other intermediaries. The "logme" parameter shown in Figure 1 148 does not introduce any device-specific or user-specific information 149 and MUST be passed unchanged through SIP B2BUAs or other 150 intermediaries. 152 Alice Proxy Registrar 153 u1.foocorp.com p1.foocorp.com r1.foocorp.com 154 | | | 155 |(1) INVITE | | 156 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; 157 | remote=47755a9de7794ba387653f2099600ef2;logme 158 |----------------->| | 159 | | | 161 Figure 1: "Log Me" marking using the "logme" Session-ID header field 162 parameter 164 3.2. Starting and Stopping Logging 166 A proxy or user agent needs to determine when it needs to mark a SIP 167 request or response for logging. A user agent or proxy adds a "log 168 me" marker in a request or response for two reasons: either it is 169 configured to do so or it has detected that a dialog is being "log 170 me" marked and maintains state to ensure that all requests and 171 responses in the dialog are "log me" marked. During regression 172 testing, a proxy or user agent might be configured to mark all SIP 173 dialogs created during a given time period whereas during 174 troubleshooting it might be configured to mark a dialog based on 175 criteria specific to a reported fault such as calling and called 176 party numbers. When configuration has caused a user agent or proxy 177 to start "log me" marking requests and responses, marking continues 178 until the dialog ends. 180 3.3. Identifying Test Cases 182 The local Universally Unique Identifier (UUID) portion of Session-ID 183 [RFC7989] in the initial SIP request of a dialog is used as a random 184 test case identifier. This provides the ability to collate all 185 logged SIP requests and responses to the initial SIP request in a 186 dialog or standalone transaction. 188 3.4. Passing the Marker 190 3.4.1. To and From a User Device 192 Edge proxy or B2BUA checks whether the user device is allowed to 193 make/receive e.g. calls, based on authentication and on 194 authorization. "Log me" marking to and from authorized devices MUST 195 be passed unchanged. 197 3.4.2. To and From an External Network 199 An external network is a peer network connected at a network boundary 200 as defined in [RFC8123]. 202 External networks may be connected directly or via a peering network 203 and such networks SHOULD have specific connection agreements. 204 Whether "log me" marking is removed depends upon the policy applied 205 at the network to network interface. Peer networks SHOULD endeavor 206 to make agreements to pass "log me" marking unchanged. However, 207 since a "log me" marker may cause a SIP entity to log the SIP header 208 and body of a request or response, if no agreement exists between 209 peer networks then the "log me" marker MUST be removed at a network 210 boundary. 212 3.5. Logging Multiple Simultaneous Dialogs 214 An originating or terminating user agent and SIP entities on the 215 signaling path can log multiple SIP dialogs simultaneously, these 216 dialogs are differentiated by their test identifier. 218 3.6. Format of Logged Signaling 220 The entire SIP message (SIP headers and message body) is logged. 221 Logging SHOULD use common standard formats such as the SIP CLF 222 defined in [RFC6873] and Libpcap. If SIP CLF format is used, the 223 entire message is logged using Vendor-ID = 00000000 and Tag = 02 in 224 the portion of the SIP CLF record (see [RFC6873] 225 clause 4.4). Header fields SHOULD be logged in the form in which 226 they appear in the message, they SHOULD NOT be converted between long 227 and compact forms described in [RFC3261] clause 7.3.3. 229 3.7. Marking Related Dialogs 231 "Log me" marking is done per-dialog and typically begins at dialog 232 creation and ends when the dialog ends. However, dialogs related to 233 a "log me" marked dialog MAY also be "log me" marked. An example is 234 call transfer described in section 6.1 of [RFC5589] and explained 235 below. The logged signalling for related dialogs can be correlated 236 using Session-ID values as described in section 10.1 of [RFC7989]. 238 F1 - Transferee's UA inserts "logme" parameter in the Session-ID 239 header of the INVITE request that creates dialog1. 241 F3 - Transferor's UA inserts "logme" parameter in the Session-ID 242 header of the REFER request that creates dialog2 which is related to 243 dialog1. 245 F5 - Transferee's UA inserts "logme" parameter in the Session-ID 246 header of the INVITE request that creates dialog3 which is related to 247 dialog1. 249 Transferor Transferee Transfer 250 | | Target 251 | INVITE F1 | | 252 dialog1 |<-------------------| | 253 | 200 OK F2 | | 254 dialog1 |------------------->| | 255 | ACK | | 256 dialog1 |<-------------------| | 257 | INVITE (hold) | | 258 dialog1 |------------------->| | 259 | 200 OK | | 260 dialog1 |<-------------------| | 261 | ACK | | 262 dialog1 |------------------->| | 263 | REFER F3 (Target-Dialog:1) | 264 dialog2 |------------------->| | 265 | 202 Accepted | | 266 dialog2 |<-------------------| | 267 | NOTIFY (100 Trying) F4 | 268 dialog2 |<-------------------| | 269 | 200 OK | | 270 dialog2 |------------------->| | 271 | | INVITE F5 | 272 dialog3 | |------------------->| 273 | | 200 OK | 274 dialog3 | |<-------------------| 275 | | ACK | 276 dialog3 | |------------------->| 277 | NOTIFY (200 OK) F6| | 278 dialog2 |<-------------------| | 279 | 200 OK | | 280 dialog2 |------------------->| | 281 | BYE | | 282 dialog1 |------------------->| | 283 | 200 OK | | 284 dialog1 |<-------------------| | 285 | | BYE | 286 dialog3 | |<-------------------| 287 | | 200 OK | 288 dialog3 | |------------------->| 290 Figure 2: "Log me" marking related dialogs in call transfer 292 3.8. Forked Requests 294 The "log me" marker MUST be copied into forked requests. 296 4. SIP Entity Behavior 298 "Log me" marking is initiated on a dialog creating side controlled by 299 configuration. The dialog terminating side detects an incoming "log 300 me" marker and reacts accordingly. 302 4.1. Endpoints 304 A common scenario is to have both originating and terminating 305 endpoints support "log me" marking specification with the originating 306 endpoint configured to initiate "log me" marking. In this simplest 307 use case, the originating user agent inserts a "log me" marker in the 308 dialog-creating SIP request and all subsequent SIP requests within 309 that dialog. The "log me" marker is passed through the SIP 310 intermediaries and arrives at the terminating user agent which ecohes 311 "log me" header in the corresponding responses. If the terminating 312 user agent sends an in-dialog request on a dialog that is being "log 313 me" marked, it inserts a "log me" marker and the originating user 314 agent echoes the "log me" marker in responses. This basic use case 315 suggests the following principles: 317 o The originating user agent configured for "log me" marking logs 318 its own signaling and inserts a "log me" marker into the dialog- 319 creating SIP request and subsequent in-dialog SIP requests. 321 o The terminating user agent detects that a dialog is of interest to 322 logging by the existence of a "log me" marker in an incoming 323 dialog-creating SIP request. 325 o The terminating user agent logs marked requests and corresponding 326 responses if allowed as per policy. 328 o The terminating user agent MUST echo a "log me" marker in 329 responses to a SIP request that included a "log me" marker. 331 o If the terminating user agent has detected that a dialog is being 332 "log me" marked, it MUST insert a "log me" marker in any in-dialog 333 SIP requests that it sends. 335 4.2. SIP Intermediaries 337 A network operator may know that some of the user agents connected to 338 the network do not support "log me" marking. In order to test 339 sessions involving such user agents, the SIP intermediary closest to 340 the user agent (e.g. edge proxies, B2BUA) on the originating and 341 terminating sides insert the "log me" marker instead. The "log me" 342 marker is carried to the terminating user agent but it is not able to 343 echo the "log me" marker in responses to that request. Therefore the 344 SIP intermediary closest to the terminating user agent inserts a "log 345 me" marker in responses to the request. Likewise, if the terminating 346 user agent sends an in-dialog request, the SIP intermediary at the 347 termination side inserts a "log me" marker and the SIP intermediary 348 at the origination side echoes the "log me" marker in responses to 349 that request. This scenario suggests the following principles when a 350 SIP intermediary is configured to initiate or handle "log me" marking 351 on behalf of user agent: 353 o The originating SIP intermediary at the originating side MUST 354 insert a "log me" marker into SIP requests for session setup. 356 o The terminating SIP intermediary detects that a dialog is of 357 interest to logging by the existence of a "log me" marker in an 358 incoming SIP request. 360 o The terminating SIP intermediary logs marked requests and 361 corresponding responses if allowed as per policy. 363 o The terminating SIP intermediary MUST echo a "log me" marker in 364 responses to a SIP request that included a "log me" marker. 366 o If terminating SIP intermediary has detected that a dialog is 367 being "log me" marked, it inserts a "log me" marker in in-dialog 368 SIP requests from the terminating user agent. 370 o The originating SIP intermediary echoes the "log me" marker in 371 responses to in-dialog requests received from the terminating 372 side. 374 4.2.1. B2BUAs 376 "Log me" marking behavior of a B2BUA needs to be consistent with its 377 purpose of troubleshooting user problems and regression testing. For 378 example, a B2BUA that does no more than transcoding media can simply 379 copy "log me" marking from UAS to UAC whereas a B2BUA that performs 380 varied and complex signaling tasks such as distributing calls in a 381 call centre needs flexible configuration so that "log me" marking can 382 target specific B2BUA functions. 384 B2BUA behavior is described below for each of the B2BUA types 385 described in [RFC7092]. The behavior described in this clause 386 applies only to dialogs that are being "log me" marked. 388 For dialogs that are being "log me" marked, all B2BUAs MUST "log me" 389 mark in-dialog SIP requests that they generate on their own, without 390 needing explicit configuration to do so. This rule applies to both 391 the originating and terminating sides of a B2BUA. 393 4.2.1.1. Proxy-B2BUA 395 4.2.1.1.1. Terminating behavior 397 A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses 398 from its terminating to the originating side without needing explicit 399 configuration to do so. 401 4.2.1.2. Signaling-only and SDP-Modifying Signaling-only 403 4.2.1.2.1. Terminating behavior 405 B2BUA configured to initiate or handle "log me" marking on behalf of 406 user agents MUST follow the principles described in Section 4.2. 408 B2BUA SHOULD insert "log me" marking on new dialogs initiated in the 409 origination side if these dialogs are related to the "log me" marked 410 dialog handled on the termination side (e.g. a new dialog is 411 initiated on the origination side to provide IVR treatment for an end 412 user dialog handled in the termination side). 414 When a B2BUA, acting as a Session Border Controller (SBC), handles 415 "log me" marked dialog in the termination side and initiates a 416 related dialog in the origination side towards an external network, 417 the "log me" marking MUST be passed or removed based on connection 418 agreements with the external network as described in Section 3.4.2. 420 4.2.1.2.2. Originating behavior 422 Whether a signaling-only B2BUA "log me" marks SIP requests that it 423 generates on its own SHOULD be controlled by explicit configuration 424 of the originating side, in the same way that a UAC requires 425 configuration to control "log me" marking. 427 4.2.1.3. Media Relay, Media Aware, Media Termination 429 "Log me" marking behavior is independent of B2BUA media-plane 430 functionality. The behavior of signaling/media plane B2BUA roles is 431 therefore dictated only by the signaling plane role as described in 432 Section 4.2.1.1 and Section 4.2.1.2 in this document. 434 4.2.2. "Log me" Marker Processing 436 4.2.2.1. Stateless processing 438 Typically, "log me" marking will be done by an originating UA and 439 echoed by a terminating UA. Any SIP intermediary on the signalling 440 path between these UAs MAY be stateless and simply log any SIP 441 request or response that contains a "log me" marker, if configured to 442 do so. 444 4.2.2.2. Stateful processing 446 It is possible that some or all user agents connected to a SIP 447 network do not support "log me" marking, or that "log me" marking is 448 removed from SIP messages by the originating or terminating network. 449 These scenarios require SIP intermediaries to maintain state to 450 enable "log me" marking: 452 o The originating UA does not support "log me" marking. 454 o The originating network removes "log me" marking from SIP requests 455 and responses before forwarding them from its network edge to 456 external network. 458 o The terminating UA does not support "log me" marking. 460 o The terminating network removes "log me" marking from SIP requests 461 and responses received from its network edge to internal network. 463 The sections below illustrate SIP intermediary behavior in these 464 scenarios using [RFC3665] example call flow "Session Establishment 465 Through Two Proxies". 467 4.2.2.2.1. "Log Me" marking not supported by Originating UA 469 Alice's user agent does not support "log me" marking and hence 470 Proxy-1 which is the SIP intermediary closest to Alice is configured 471 to act on behalf of Alice's user agent to "log me" mark dialogs 472 created by Alice. 474 In Figure 3 below, Proxy 1 in the originating network maintains state 475 of which dialogs are being logged in order to "log me" mark all SIP 476 requests and responses that it receives from Alice's user agent 477 before forwarding them to Proxy 2. 479 [ NETWORK A ] [ NETWORK B ] 480 Alice Proxy 1 Proxy 2 Bob 481 | | | | 482 | INVITE F1 | | | 483 |--------------->| | | 484 | | | | 485 | | | | 486 | 407 F2 | | | 487 |<---------------| | | 488 | ACK F3 | | | 489 |--------------->| | | 490 | INVITE F4 | | | 491 |--------------->| | | 492 | | INVITE F5 | | 493 | |--------------->| | 494 | | | | 495 | | | | 496 | 100 F6 | | INVITE F7 | 497 |<---------------| 100 F8 |--------------->| 498 | |<---------------| | 499 | | | 180 F9 | 500 | | 180 F10 |<---------------| 501 | 180 F11 |<---------------| | 502 |<---------------| | 200 F12 | 503 | | 200 F13 |<---------------| 504 | 200 F14 |<---------------| | 505 |<---------------| | | 506 | ACK F15 | | | 507 |--------------->| | | 508 | | | | 509 | | ACK F16 | | 510 | |--------------->| | 511 | | | | 512 | | | ACK F17 | 513 | | |--------------->| 514 | Both Way RTP Media | 515 |<================================================>| 516 | | | BYE F18 | 517 | | BYE F19 |<---------------| 518 | BYE F20 |<---------------| | 519 |<---------------| | | 520 | 200 F21 | | | 521 |--------------->| | | 522 | | 200 F22 | | 523 | |--------------->| | 524 | | | | 525 | | | 200 F23 | 526 | | |--------------->| 527 | | | | 529 Figure 3: Case 1: The originating UA does not support "log me" 530 marking 532 F1 - Alice's UA does not insert a "log me" marker in the dialog- 533 creating INVITE request F1. Nevertheless, Proxy 1 is configured to 534 detect the start of logging. Proxy 1 logs INVITE request F1 and 535 maintains state that this dialog is being logged. 537 F2 - Proxy 1 inserts a "log me" marker in INVITE request F5 before 538 forwarding it to Proxy 2. 540 F3 - Proxy 1 inserts a "log me" marker in ACK request F16 before 541 forwarding it to Proxy 2). 543 4.2.2.2.2. "Log Me" marking removed by Originating Network 545 If network A in In Figure 4 below is performing testing independently 546 of network B then network A removes "log me" marking from SIP 547 requests and responses forwarded to network B to prevent triggering 548 unintended logging in network B. Proxy 1 removes "log me" marking 549 from requests and responses that it forwards to Proxy 2 and maintains 550 state of which dialogs are being "log me" marked in order to "log me" 551 mark requests and responses that it forwards from Proxy 2 to Alice's 552 user agent. Proxy 1 also logs requests and responses for the 553 duration of the dialog. 555 [ NETWORK A ] [ NETWORK B ] 556 Alice Proxy 1 Proxy 2 Bob 557 | | | | 558 | INVITE F1 | | | 559 |--------------->| | | 560 | | | | 561 | | | | 562 | 407 F2 | | | 563 |<---------------| | | 564 | ACK F3 | | | 565 |--------------->| | | 566 | INVITE F4 | | | 567 |--------------->| | | 568 | |INVITE F5 | | 569 | |--------------->| | 570 | | | | 571 | | | | 572 | 100 F6 | | | 573 |<---------------| | | 574 | | | | 575 | | | | 576 | | | INVITE F7 | 577 | | 100 F8 |--------------->| 578 | |<---------------| | 579 | | | 180 F9 | 580 | | 180 F10 |<---------------| 581 | |<---------------| | 582 | 180 F11 | | | 583 |<---------------| | | 584 | | | | 585 | | | | 586 | | | 200 F12 | 587 | | 200 F13 |<---------------| 588 | 200 F14 |<---------------| | 589 |<---------------| | | 590 | ACK F15 | | | 591 |--------------->| | | 592 | | ACK F16 | | 593 | |--------------->| | 594 | | | | 596 | | | | 597 | | | ACK F17 | 598 | | |--------------->| 599 | Both Way RTP Media | 600 |<================================================>| 601 | | | BYE F18 | 602 | | BYE F19 |<---------------| 603 | BYE F20 |<---------------| | 604 |<---------------| | | 605 | 200 F21 | | | 606 |--------------->| | | 607 | | 200 F22 | | 608 | |--------------->| | 609 | | | | 610 | | | | 611 | | | 200 F23 | 612 | | |--------------->| 613 | | | | 615 Figure 4: Case 2: The originating network removes "log me" marking 616 from outgoing SIP messages at its network edge. 618 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 619 INVITE request and Proxy 1 therefore maintains state that this dialog 620 is to be logged. 622 F5 - Proxy 1 removes "log me" marking from INVITE request before 623 forwarding it to Proxy 2. 625 F6 - Proxy 1 inserts a "log me" marker in 100 response sent to the 626 Alice's user agent. 628 F11 - Proxy 1 inserts a "log me" marker in 180 response before 629 forwarding it to Alice's user agent. The same applies to responses 630 F14, F20. 632 F16 - Proxy 1 removes "log me" marking from ACK request before 633 forwarding it to Proxy 2. 635 F22 - Proxy 1 removes "log me" marking from the 200 response of the 636 BYE request before forwarding it to Proxy 2. 638 4.2.2.2.3. "Log Me" marking not supported by Terminating UA 640 In Figure 5 below Bob's UA does not support "log me" marking, so 641 Proxy 2 in the terminating network maintains state to ensure "log me" 642 marking of SIP requests and responses from Bob's UA. 644 [ NETWORK A ] [ NETWORK B ] 645 Alice Proxy 1 Proxy 2 Bob 646 | | | | 647 | INVITE F1 | | | 648 |--------------->| | | 649 | | | | 650 | | | | 651 | 407 F2 | | | 652 |<---------------| | | 653 | ACK F3 | | | 654 |--------------->| | | 655 | INVITE F4 | | | 656 |--------------->| | | 657 | | INVITE F5 | | 658 | |--------------->| | 659 | | | | 660 | | | | 661 | 100 F6 | | | 662 |<---------------| | | 663 | | | INVITE F7 | 664 | | 100 F8 |--------------->| 665 | |<---------------| | 666 | | | 180 F9 | 667 | | |<---------------| 668 | | | | 669 | | | | 670 | | 180 F10 | | 671 | |<---------------| | 672 | | | | 673 | | | | 674 | 180 F11 | | | 675 |<---------------| | 200 F12 | 676 | | 200 F13 |<---------------| 677 | 200 F14 |<---------------| | 678 |<---------------| | | 679 | ACK F15 | | | 680 |--------------->| 681 | | ACK F16 | | 682 | |--------------->| ACK F17 | 683 | | |--------------->| 684 | Both Way RTP Media | 685 |<================================================>| 686 | | | BYE F18 | 687 | | BYE F19 |<---------------| 688 | BYE F20 |<---------------| | 689 |<---------------| | | 690 | 200 F21 | | | 691 |--------------->| 692 | | 200 F22 | | 693 | |--------------->| 200 F23 | 694 | | |--------------->| 695 | | | | 697 Figure 5: Case 3: The terminating UA does not support "log me" 698 marking. 700 F1 - Alice's UA inserts a "log me" marker in the the dialog-creating 701 INVITE request F1. 703 F5 - INVITE F5 is "log me" marked and Proxy 2 therefore maintains 704 state that this dialog is to be logged. 706 F9 - Bob's UA does not support "log me" marking, therefore the 180 707 response to the INVITE request doesn't have a "log me" marker. 709 F10 - Proxy 2 inserts a "log me" marker in the 180 response on behalf 710 of Bob's UA before forwarding it. The same applies to response F13 711 and BYE request in F19. 713 4.2.2.2.4. "Log Me" marking removed by Terminating Network 715 In Figure 6 below Proxy 2 removes "log me" marking from all SIP 716 requests and responses entering network B. Proxy 1 therefore 717 maintains state of which dialogs are being "log me" marked in order 718 to "log me" mark all requests and responses that it receives from 719 Proxy 2. 721 [ NETWORK A ] [ NETWORK B ] 722 Alice Proxy 1 Proxy 2 Bob 723 | | | | 724 | INVITE F1 | | | 725 |--------------->| | | 726 | | | | 727 | 407 F2 | | | 728 |<---------------| | | 729 | ACK F3 | | | 730 |--------------->| | | 731 | INVITE F4 | | | 732 |--------------->| | | 733 | | INVITE F5 | | 734 | |--------------->| | 735 | | | | 736 | | | | 737 | 100 F6 | | | 738 |<---------------| | | 739 | | | INVITE F7 | 740 | | 100 F8 |--------------->| 741 | |<---------------| | 742 | | | 180 F9 | 743 | | |<---------------| 744 | | 180 F10 | 745 | |<---------------| | 746 | | | | 748 | | | | 749 | 180 F11 | | | 750 |<---------------| | 200 F12 | 751 | | 200 F13 |<---------------| 752 | 200 F14 |<---------------| | 753 |<---------------| | | 754 | ACK F15 | | | 755 |--------------->| 756 | | ACK F16 | | 757 | |--------------->| ACK F17 | 758 | | |--------------->| 759 | Both Way RTP Media | 760 |<================================================>| 761 | | | BYE F18 | 762 | | BYE F19 |<---------------| 763 | BYE F20 |<---------------| | 764 |<---------------| | | 765 | 200 F21 | | | 766 |--------------->| 767 | | 200 F22 | | 768 | |--------------->| 200 F23 | 769 | | |--------------->| 770 | | | | 772 Figure 6: Case 2: The terminating network removes "log me" marking 773 from incoming SIP messages at its network edge. 775 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 776 INVITE request F1. Proxy 1 detects the "log me" marker and maintains 777 state that this dialog is to be logged. 779 F5 - Proxy 2 removes "log me" marker in the INVITE request F5 before 780 forwarding it as F7. 782 F10 - Proxy 1 inserts a "log me" marker in 180 response of the INVITE 783 request before forwarding it as F11. The same applies to responses 784 F13 and BYE request in F19. 786 5. Error Handling 788 5.1. Missing "Log me" Marker in Dialog Being Logged 790 A terminating user agent or terminating edge proxy that has been 791 echoing markers in responses for a given dialog might receive a SIP 792 request that has not been "log me" marked. Since "log me" marking is 793 done per dialog, this is an error. In such cases, the user agent or 794 proxy SHOULD consider "log me" marking to have ended and MUST NOT 795 mark a response to the unmarked request, responses to subsequent 796 requests in the dialog, or in-dialog requests sent from the 797 terminating side. 799 5.2. "Log Me" Marker Appears Mid-Dialog 801 "log me" marking that begins mid-dialog is an error case and the 802 terminating user agent or edge proxy MUST NOT "log me" mark responses 803 to the marked request, responses to subsequent requests in the 804 dialog, or in-dialog requests from the terminating side. 806 6. Security Considerations 808 6.1. "Log Me" Authorization 810 An end user or network administrator MUST give permission for a 811 terminal to perform "log me" marking. The configuration of a SIP 812 intermediary to perform "log me" marking on behalf of a terminal MUST 813 be authorized by the network administrator. 815 Activating a debug mode affects the operation of a terminal, 816 therefore debugging configuration MUST be supplied by an authorized 817 party to an authorized terminal through a secure communication 818 channel. 820 6.2. "Log Me" Marker Removal 822 The log me marker is not sensitive information, although it will 823 sometimes be inserted because a particular device is experiencing 824 problems. 826 The presence of a log me marker will cause some SIP entities to log 827 signaling messages. Therefore, this marker MUST be removed at the 828 earliest opportunity if it has been incorrectly inserted, such as 829 appearing mid-dialog in a dialog that was not being logged or outside 830 the configured start and stop of logging. 832 If SIP requests and responses are exchanged with an external network 833 with which there is no agreement to pass "log me" marking, then the 834 "log me" marking is removed. 836 6.3. Denial of Service Attacks 838 Maliciously configuring a large number of terminals to simultaneously 839 "log me" mark dialogs will cause high processor load on SIP entities 840 that are logging signalling. Since "log me" marking is for the small 841 number of dialogs subject to troubleshooting or regression testing, 842 the number of dialogs that can be simultaneously logged can be 843 statically limited without adversely affecting the usefulness of "log 844 me" marking. Also, the SIP intermediary closest to the terminal and 845 SIP intermediary at network edge (e.g Session Border Controllers) can 846 be configured to screen-out "log me" markers when troubleshooting or 847 regression testing is not in progress. 849 6.4. Privacy 851 Logging includes all SIP header fields, the SIP privacy mechanisms 852 defined in [RFC3323] can be used to ensure that logs do not divulge 853 personal identity information. 855 6.4.1. Personal Identifiers 857 "Log me" marking is defined for the SIP Protocol, and SIP has header 858 fields such as From, Contact, P-Asserted-Identity that can carry 859 personal identifiers. Different protocol interactions can be 860 correlated using the Session-ID and Call-ID header fields, but such 861 correlation is limited to a single end-to-end session. 863 In order to protect user privacy during logging, privacy settings can 864 be enabled or requested by the terminal used by the end user. 865 [RFC3323] suggests two mechanisms: 867 o By using the value anonymous in the From header field 869 o By requesting privacy from SIP intermediaries using the Privacy 870 header 872 "Log me" marking is typically used for troubleshooting and regression 873 testing, and in some cases a service provider owned device with a 874 dummy account can be used instead of a customer device. In such 875 cases, no personal identifiers are included in the logged signaling 876 messages. 878 6.4.2. Data Stored at SIP Intermediaries 880 SIP endpoints and intermediaries that honor the "log me" request 881 store all the SIP messages that are exchanged within a given dialog. 882 SIP messages can contain the personal identifiers listed in 883 Section 6.4.1 and additionally a user identity, calling party number, 884 IP address, hostname, and other user and device related items. The 885 SIP message bodies describe the kind of session being set up by the 886 identified end user and device. 888 "Log me" marking does not introduce any additional user or device 889 data to SIP but might indicate that a specific user is experiencing a 890 problem. 892 6.4.3. Data Visible at Network Elements 894 SIP messages that are logged due to "log me" requests are stored only 895 by the SIP initiators, intermediaries and recipients. Enablers as 896 defined in section 3.1 of [RFC6973], such as firewalls and DNS 897 servers do not log messages due to the "log me" marking. 899 6.4.4. Preventing Fingerprinting 901 "Log me" functionality is typically used to troubleshoot a given 902 problem and hence it can be used as an method to identify users and 903 devices that are experiencing issues. The best way to prevent 904 fingerprinting is to enable or request SIP privacy for the logged 905 dialog. 907 6.4.5. Retaining Logs 909 The lifetime of "log me" marking is equivalent to the lifetime of the 910 dialog that initiated the "log me" request. When "log me" is 911 extended to related dialogs the lifetime is extended until there is 912 no more related dialog for the end-to-end session. 914 "log me" automatically expires at the end of the dialog and there is 915 no explicit mechanism to turn off logging within a dialog. 917 The scope of "log me" Marking is limited i.e. an user or the network 918 administrator has to enable it on a per session basis or for a 919 specific time period. This minimizes the risk of exposing user data 920 for an indefinite time. 922 The retention time period for logged messages is out of scope for 923 this document and is expected to be configured based on the data 924 storage policies of service providers and enterprises. 926 6.4.6. User Control of Logging 928 Consent to turn on "log me" for a given session MUST be provided by 929 the end user or by the network administrator. It is handled outside 930 of the protocol through user interface or application programming 931 interfaces at the end point, call control elements and network 932 management systems. 934 SIP entities across the communication path can be configured to pass 935 through the "log me" marking but not honor the request i.e. not log 936 the data based on local policies. 938 6.4.7. Recommended Defaults 940 The recommended defaults for "log me" marking are: 942 o turn on SIP privacy as described in Section 6.4 or use a service 943 provider owned device with a dummy user identity for test calls 945 o use the local UUID of Session-ID header at the originating device 946 as the test identifier as described in Section 3.3 948 6.5. Data Protection 950 A SIP entity that has logged information MUST protect the logs. 951 Storage of the log files are subject to the security considerations 952 specified in [RFC6872]. 954 7. Augmented BNF for the "logme" Parameter 956 ABNF is described in [RFC5234]. This document introduces a new 957 "logme"parameter for the Session-ID header field defined in Section 5 958 of [RFC7989]. 960 sess-id-param = remote-param / logme-param / generic-param 962 remote-param = "remote" EQUAL remote-uuid 964 logme-param = "logme" 966 Figure 7: Augmented BNF for the "logme" Parameter 968 8. IANA Considerations 970 8.1. Registration of the "logme" Parameter 972 The following parameter is to be added to the "Header Field 973 Parameters and Parameter Values" section of the SIP parameter 974 registry: 976 +--------------+----------------+-------------------+-----------+ 977 | Header Field | Parameter Name | Predefined Values | Reference | 978 +--------------+----------------+-------------------+-----------+ 979 | Session-ID | logme | No | [RFCXXXX] | 980 +--------------+----------------+-------------------+-----------+ 982 Table 1 984 9. References 986 9.1. Normative References 988 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 989 Requirement Levels", BCP 14, RFC 2119, 990 DOI 10.17487/RFC2119, March 1997, 991 . 993 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 994 A., Peterson, J., Sparks, R., Handley, M., and E. 995 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 996 DOI 10.17487/RFC3261, June 2002, 997 . 999 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1000 H., and O. Festor, "The Common Log Format (CLF) for the 1001 Session Initiation Protocol (SIP): Framework and 1002 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1003 February 2013, . 1005 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1006 Session Initiation Protocol (SIP) Common Log Format 1007 (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, 1008 . 1010 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1011 Kaplan, "Requirements for an End-to-End Session 1012 Identification in IP-Based Multimedia Communication 1013 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1014 . 1016 [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- 1017 to-End Session Identification in IP-Based Multimedia 1018 Communication Networks", RFC 7989, DOI 10.17487/RFC7989, 1019 October 2016, . 1021 9.2. Informative References 1023 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1024 Initiation Protocol (SIP)", RFC 3323, 1025 DOI 10.17487/RFC3323, November 2002, 1026 . 1028 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1029 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1030 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1031 December 2003, . 1033 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1034 Specifications: ABNF", STD 68, RFC 5234, 1035 DOI 10.17487/RFC5234, January 2008, 1036 . 1038 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1039 Initiation Protocol (SIP) Call Control - Transfer", 1040 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1041 . 1043 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1044 Morris, J., Hansen, M., and R. Smith, "Privacy 1045 Considerations for Internet Protocols", RFC 6973, 1046 DOI 10.17487/RFC6973, July 2013, 1047 . 1049 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1050 Initiation Protocol (SIP) Back-to-Back User Agents", 1051 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1052 . 1054 [RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking 1055 SIP Messages to be Logged", RFC 8123, 1056 DOI 10.17487/RFC8123, March 2017, 1057 . 1059 Authors' Addresses 1061 Peter Dawes 1062 Vodafone Group 1063 The Connection 1064 Newbury, Berkshire RG14 2FN 1065 UK 1067 Email: peter.dawes@vodafone.com 1069 Chidambaram Arunachalam 1070 Cisco Systems 1071 7200-12 Kit Creek Road 1072 Research Triangle Park, NC, NC 27709 1073 US 1075 Email: carunach@cisco.com