idnits 2.17.1 draft-ietf-insipid-logme-marking-08.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 154 has weird spacing: '...ple.com p1.ex...' -- The document date (August 6, 2017) is 2426 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 1328, but not defined == Unused Reference: 'RFC7206' is defined on line 1364, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7206 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: February 7, 2018 Cisco Systems 6 August 6, 2017 8 Marking SIP Messages to be Logged 9 draft-ietf-insipid-logme-marking-08 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 being of interest to logging. Such 22 marking will typically be applied as part of network testing 23 controlled by the network operator and not used in normal user agent 24 signaling. However, such marking can be carried end-to-end including 25 the 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 February 7, 2018. 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 . . . . . . . . . . . . . . . 6 73 3.7. Marking Related Dialogs . . . . . . . . . . . . . . . . . 6 74 3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 11 75 4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 11 76 4.1. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.2. SIP Intermediaries . . . . . . . . . . . . . . . . . . . 12 78 4.2.1. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.2.2. "Log me" Marker Processing . . . . . . . . . . . . . 14 80 4.2.2.1. Stateless processing . . . . . . . . . . . . . . 14 81 4.2.2.2. Stateful processing . . . . . . . . . . . . . . . 14 82 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.1. Missing "Log me" Marker in Dialog Being Logged . . . . . 24 84 5.1.1. Error Cases . . . . . . . . . . . . . . . . . . . . . 24 85 5.1.2. Non-Error Cases . . . . . . . . . . . . . . . . . . . 27 86 5.2. "Log Me" Marker Appears Mid-Dialog . . . . . . . . . . . 28 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 88 6.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 29 89 6.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 29 90 6.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 91 6.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 6.4.1. Personal Identifiers . . . . . . . . . . . . . . . . 30 93 6.4.2. Data Stored at SIP Intermediaries . . . . . . . . . . 30 94 6.4.3. Data Visible at Network Elements . . . . . . . . . . 30 95 6.4.4. Preventing Fingerprinting . . . . . . . . . . . . . . 31 96 6.4.5. Retaining Logs . . . . . . . . . . . . . . . . . . . 31 97 6.4.6. User Control of Logging . . . . . . . . . . . . . . . 31 98 6.4.7. Recommended Defaults . . . . . . . . . . . . . . . . 31 99 6.5. Data Protection . . . . . . . . . . . . . . . . . . . . . 32 100 7. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 32 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 102 8.1. Registration of the "logme" Parameter . . . . . . . . . . 32 103 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 106 10.2. Informative References . . . . . . . . . . . . . . . . . 33 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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 in 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. (See Section 3.4.2 where this normative behavior may 151 be relaxed for intermediaries in an external network.) 153 Alice Proxy Registrar 154 u1.example.com p1.example.com r1.example.com 155 | | | 156 |(1) INVITE | | 157 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; 158 | remote=47755a9de7794ba387653f2099600ef2;logme 159 |----------------->| | 160 | | | 162 Figure 1: "Log Me" marking using the "logme" Session-ID header field 163 parameter 165 3.2. Starting and Stopping Logging 167 A user agent or proxy adds a "log me" marker in a request or response 168 for two reasons: either it is configured to do so or it has detected 169 that a dialog is being "log me" marked, causing it to maintain state 170 to ensure that all requests and responses in the dialog are similarly 171 "log me" marked. 173 When a user agent or proxy is configured to add a "log me" marker in 174 messages, the start and stop times or events that the user agent or 175 proxy will be configured with is out of the scope of this document. 176 As example possible configurations, the user agent client or proxy 177 could be configured to add a "log me" marker for a certain number of 178 requests, or could be configured to mark messages with a temporal 179 scope (e.g., 9:00am - 10:00am every day), or could be configured to 180 mark messages when it encounters a specific "User-Agent" header, or 181 for a specific set of called party numbers for which users are 182 experiencing call setup failures. 184 On the other hand, when a user agent or proxy detects that a dialog- 185 initiating request is being "log me" marked, the scope of such 186 marking extends to the lifetime of the dialog. In addition, as 187 discussed in Section 3.7, "log me" marked dialogs that create related 188 dialogs (REFER) may transfer the marking to the related dialogs. In 189 such cases, the entire "session", identified by the Session-ID 190 header, is "log me" marked. 192 3.3. Identifying Test Cases 194 The local Universally Unique Identifier (UUID) portion of Session-ID 195 [RFC7989] in the initial SIP request of a dialog is used as a random 196 test case identifier. This provides the ability to collate all 197 logged SIP requests and responses to the initial SIP request in a 198 dialog or standalone transaction. 200 3.4. Passing the Marker 202 3.4.1. To and From a User Device 204 When a user device inserts the "log me" marker, the marker MUST be 205 passed unchanged in the Session-ID header across an edge proxy or a 206 B2BUA adjacent to the user device. 208 3.4.2. To and From an External Network 210 An external network is a peer network connected at a network boundary 211 as defined in [RFC8123]. 213 External networks may be connected directly or via a peering network 214 and such networks SHOULD have specific connection agreements. 215 Whether "log me" marking is removed depends upon the policy applied 216 at the network to network interface. Peer networks SHOULD endeavor 217 to make agreements to pass "log me" marking unchanged. However, 218 since a "log me" marker may cause a SIP entity to log the SIP header 219 and body of a request or response, if no agreement exists between 220 peer networks then the "log me" marker MUST be removed at a network 221 boundary. 223 3.5. Logging Multiple Simultaneous Dialogs 225 An originating or terminating user agent and SIP entities on the 226 signaling path can log multiple SIP dialogs simultaneously, these 227 dialogs are differentiated by their test case identifier (the local 228 UUID of the Session-ID header field at the originating device). 230 3.6. Format of Logged Signaling 232 The entire SIP message (SIP headers and message body) is logged. 233 Logging SHOULD use common standard formats such as the SIP CLF 234 defined in [RFC6873] and Libpcap. If SIP CLF format is used, the 235 entire message is logged using Vendor-ID = 00000000 and Tag = 02 in 236 the portion of the SIP CLF record (see [RFC6873] 237 clause 4.4). Header fields SHOULD be logged in the form in which 238 they appear in the message, they SHOULD NOT be converted between long 239 and compact forms described in [RFC3261] clause 7.3.3. 241 3.7. Marking Related Dialogs 243 "Log me" marking is done per-dialog and typically begins at dialog 244 creation and ends when the dialog ends. However, dialogs related to 245 a "log me" marked dialog MAY also be "log me" marked. An example is 246 call transfer described in section 6.1 of [RFC5589] and the logged 247 signalling for related dialogs can be correlated using Session-ID 248 values as described in section 10.9 of [RFC7989]. 250 In the example shown in Figure 2 below, Alice has reported problems 251 making call transfers and her terminal is configured to log 252 signalling for a call transfer. Alice calls Bob, which creates 253 initial dialog1, and then transfers the call to connect Bob to Carol. 254 Logged signalling is correlated using the test case identifier, which 255 is the local UUID ab30317f1a784dc48ff824d0d3715d86 in the Session-ID 256 header field of INVITE request F1. Logging by Alice's terminal 257 begins with INVITE request F1 and ends with the final 200 OK of 258 dialog1. Also during dialog1, Alice's terminal logs related REFER 259 dialog2 that it initiates and terminates as part of the call 260 transfer. Both dialog1 and dialog2 have the same test case 261 identifier. 263 Logging by Bob's terminal begins when it receives and echoes the 264 "logme" marker in INVITE F1 and ends when dialog3, initiated by Bob, 265 ends. Logging by Carol's terminal begins when it receives and echoes 266 the "log me" marker in INVITE F5 that creates dialog3 and ends when 267 dialog3 ends. 269 dialog3 is not logged by Alice's terminal and the test case 270 identifier ab30317f1a784dc48ff824d0d3715d86 is not the local-uuid in 271 INVITE F5. However, Alice's test case identifier can be linked to 272 dialog3 because dialog3 is initiated by the remote party of dialog1 273 i.e., the remote-uuid component of the Session-ID header field in 274 requests and responses sent from Alice to Bob is the local-uuid 275 component in INVITE F5. 277 F1 - Alice's UA inserts "logme" parameter in the Session-ID header of 278 the INVITE request that creates dialog1. 280 F3 - Alice's UA inserts "logme" parameter in the Session-ID header of 281 the REFER request that creates dialog2 which is related to dialog1. 283 F5 - Bob's UA inserts "logme" parameter in the Session-ID header of 284 the INVITE request that creates dialog3 which is related to dialog1. 286 Bob Alice Carol 287 Transferee Transferor Transfer 288 | | Target 289 | INVITE F1 | | 290 dialog1 |<-------------------| | 291 | 200 OK F2 | | 292 dialog1 |------------------->| | 293 | ACK | | 294 dialog1 |<-------------------| | 295 | INVITE (hold) | | 296 dialog1 |<-------------------| | 297 | 200 OK | | 298 dialog1 |------------------->| | 299 | ACK | | 300 dialog1 |<-------------------| | 301 | REFER F3 (Target-Dialog:1) | 302 dialog2 |<-------------------| | 303 | 202 Accepted | | 304 dialog2 |------------------->| | 305 | NOTIFY (100 Trying) F4 | 306 dialog2 |------------------->| | 307 | 200 OK | | 308 dialog2 |<-------------------| | 309 | | INVITE F5 | 310 dialog3 |---------------------------------------->| 311 | | 200 OK | 312 dialog3 |<----------------------------------------| 313 | | ACK | 314 dialog3 |---------------------------------------->| 315 | NOTIFY (200 OK) F6| | 316 dialog2 |------------------->| | 317 | 200 OK | | 318 dialog2 |<-------------------| | 319 | BYE | | 320 dialog1 |<-------------------| | 321 | 200 OK | | 322 dialog1 |------------------->| | 323 | | BYE | 324 dialog3 |<----------------------------------------| 325 | | 200 OK | 326 dialog3 |---------------------------------------->| 328 Figure 2: "Log me" marking related dialogs in call transfer 330 F1 INVITE Transferor -> Transferee 331 INVITE sips:transferor@atlanta.example.com SIP/2.0 332 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 333 Max-Forwards: 70 334 To: 335 From: ;tag=7553452 336 Call-ID: 090459243588173445 337 Session-ID: ab30317f1a784dc48ff824d0d3715d86 338 ;remote=00000000000000000000000000000000;logme 339 CSeq: 29887 INVITE 340 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 341 Supported: replaces, gruu, tdialog 342 Contact: 343 Content-Type: application/sdp 344 Content-Length: ... 346 F2 200 OK Transferee -> Transferor 348 SIP/2.0 200 OK 349 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 350 To: ;tag=31kdl4i3k 351 From: ;tag=7553452 352 Call-ID: 090459243588173445 353 Session-ID: 47755a9de7794ba387653f2099600ef2 354 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 355 CSeq: 29887 INVITE 356 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 357 Supported: replaces, gruu, tdialog 358 Contact: 359 Content-Type: application/sdp 360 Content-Length: ... 362 F3 REFER Transferor -> Transferee 364 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 365 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 366 Max-Forwards: 70 367 To: 368 From: ;tag=1928301774 369 Call-ID: a84b4c76e66710 370 Session-ID: ab30317f1a784dc48ff824d0d3715d86 371 ;remote=47755a9de7794ba387653f2099600ef2;logme 372 CSeq: 314159 REFER 373 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 374 Supported: gruu, replaces, tdialog 375 Require: tdialog 376 Refer-To: 377 Target-Dialog: 090459243588173445;local-tag=7553452 378 ;remote-tag=31kdl4i3k 379 Contact: 380 Content-Length: 0 382 F4 NOTIFY Transferee -> Transferor 384 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 385 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 386 Max-Forwards: 70 387 To: ;tag=1928301774 388 From: 389 ;tag=a6c85cf 390 Call-ID: a84b4c76e66710 391 Session-ID: 47755a9de7794ba387653f2099600ef2 392 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 393 CSeq: 73 NOTIFY 394 Contact: 395 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 396 Supported: replaces, tdialog 397 Event: refer 398 Subscription-State: active;expires=60 399 Content-Type: message/sipfrag 400 Content-Length: ... 402 F5 INVITE Transferee -> Transfer Target 404 INVITE sips:transfertarget@chicago.example.com SIP/2.0 405 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 406 Max-Forwards: 70 407 To: 408 From: ;tag=j3kso3iqhq 409 Call-ID: 90422f3sd23m4g56832034 410 Session-ID: 47755a9de7794ba387653f2099600ef2 411 ;remote=00000000000000000000000000000000;logme 412 CSeq: 521 REFER 413 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 414 Supported: replaces, gruu, tdialog 415 Contact: 416 Content-Type: application/sdp 417 Content-Length: ... 419 F6 NOTIFY Transferee -> Transferor 421 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 422 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 423 Max-Forwards: 70 424 To: ;tag=1928301774 425 From: 426 ;tag=a6c85cf 427 Call-ID: a84b4c76e66710 428 Session-ID: 47755a9de7794ba387653f2099600ef2 429 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 430 CSeq: 74 NOTIFY 431 Contact: 432 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 433 Supported: replaces, tdialog 434 Event: refer 435 Subscription-State: terminated;reason=noresource 436 Content-Type: message/sipfrag 437 Content-Length: ... 439 3.8. Forked Requests 441 The "log me" marker MUST be copied into forked requests. 443 4. SIP Entity Behavior 445 "Log me" marking is initiated on a dialog creating side controlled by 446 configuration. The dialog terminating side detects an incoming "log 447 me" marker and reacts accordingly. 449 4.1. Endpoints 451 A common scenario is to have both originating and terminating 452 endpoints support "log me" marking specification with the originating 453 endpoint configured to initiate "log me" marking. In this simplest 454 use case, the originating user agent inserts a "log me" marker in the 455 dialog-creating SIP request and all subsequent SIP requests within 456 that dialog. The "log me" marker is passed through the SIP 457 intermediaries and arrives at the terminating user agent which echoes 458 the "log me" marker in the corresponding responses. If the 459 terminating user agent sends an in-dialog request on a dialog that is 460 being "log me" marked, it inserts a "log me" marker and the 461 originating user agent echoes the "log me" marker in responses. The 462 terminating user agent logs the "log me" marked SIP requests and 463 responses if it is allowed as per policy defined in the termination 464 network. This basic use case suggests the following principles: 466 o The originating user agent configured for "log me" marking MUST 467 insert a "log me" marker into the dialog-creating SIP request and 468 subsequent in-dialog SIP requests. 470 o The originating user agent itself logs signaling. 472 o The terminating user agent detects that a dialog is of interest to 473 logging by the existence of a "log me" marker in an incoming 474 dialog-creating SIP request. 476 o The terminating user agent itself logs marked requests and 477 corresponding responses if allowed as per policy. 479 o The terminating user agent MUST echo a "log me" marker in 480 responses to a SIP request that included a "log me" marker. 482 o If the terminating user agent has detected that a dialog is being 483 "log me" marked, it MUST insert a "log me" marker in any in-dialog 484 SIP requests that it sends. 486 o The terminating user agent itself logs any in-dialog SIP requests 487 that it sends if allowed as per policy. 489 o The originating user agent echoes, in responses, the "log me" 490 marker received in in-dialog requests from the terminating side. 492 o The originating user agent logs the SIP responses that it sends in 493 response to received "log me" marked in-dialog requests. 495 4.2. SIP Intermediaries 497 A network operator may know that some of the user agents connected to 498 the network do not support "log me" marking. In order to test 499 sessions involving such user agents, the SIP intermediary closest to 500 the user agent (e.g. edge proxies, B2BUA) on the originating and 501 terminating sides insert the "log me" marker instead. If the 502 terminating user agent does not echo this "log me" marker in 503 responses to that request then the the SIP intermediary closest to 504 the terminating user agent inserts a "log me" marker in responses to 505 the request. Likewise, if the terminating user agent sends an in- 506 dialog request, the SIP intermediary at the termination side inserts 507 a "log me" marker and the SIP intermediary at the origination side 508 echoes the "log me" marker in responses to that request. The SIP 509 intermediary at the terminating side logs the "log me" marked SIP 510 requests and responses if it is allowed as per policy defined in the 511 termination network. This scenario suggests the following principles 512 when a SIP intermediary is configured to initiate or handle "log me" 513 marking on behalf of user agent: 515 o The originating SIP intermediary MUST insert a "log me" marker 516 into the dialog-creating SIP request and subsequent in-dialog SIP 517 requests. 519 o The originating SIP intermediary itself logs signaling. 521 o The terminating SIP intermediary detects that a dialog is of 522 interest to logging by the existence of a "log me" marker in an 523 incoming dialog-creating SIP request. 525 o The terminating SIP intermediary itself logs marked requests and 526 corresponding responses if allowed as per policy. 528 o The terminating SIP intermediary MUST echo a "log me" marker in 529 responses to a SIP request that included a "log me" marker. 531 o If terminating SIP intermediary has detected that a dialog is 532 being "log me" marked, it MUST insert a "log me" marker in any in- 533 dialog SIP requests from the terminating user agent. 535 o The terminating SIP intermediary itself logs any in-dialog SIP 536 requests that it sends if allowed as per policy. 538 o The originating SIP intermediary detects the "log me" marker 539 received in in-dialog requests and echoes the "log me" marker in 540 the corresponding SIP responses. 542 o The originating SIP intermediary logs the SIP responses that it 543 sends in response to "log me" marked in-dialog requests. 545 4.2.1. B2BUAs 547 B2BUA "log me" behavior is specified based on its different signaling 548 plane roles described in [RFC7092]. 550 A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses 551 from its terminating to the originating side without needing explicit 552 configuration to do so. 554 A dialog on one "side" of the B2BUA may or may not be coupled to a 555 related dialog on the other "side" for "log me" purposes. To allow 556 end-to-end troubleshooting of user problems and regression testing, a 557 signaling-only and SDP-modifying signaling-only B2BUA [RFC7092] 558 SHOULD couple related dialogs for "log me" marking purposes and pass 559 on the received "log me" parameter from the originating side to 560 terminating side and vice versa. For example, a SIP B2BUA handling 561 end-to-end session between an external caller and an agent in a 562 contact center environment can couple the dialog between itself and 563 an agent with the dialog between itself and external caller and pass 564 on the "log me" marking from originating side to terminating side to 565 enable end-to-end logging of specific sessions of interest. 567 For dialogs that are being "log me" marked, all B2BUAs MUST "log me" 568 mark in-dialog SIP requests that they generate on their own, without 569 needing explicit configuration to do so. This rule applies to both 570 the originating and terminating sides of a B2BUA. 572 4.2.2. "Log me" Marker Processing 574 4.2.2.1. Stateless processing 576 Typically, "log me" marking will be done by an originating UA and 577 echoed by a terminating UA. Any SIP intermediary on the signalling 578 path between these UAs MAY be stateless and simply log any SIP 579 request or response that contains a "log me" marker, if configured to 580 do so. 582 4.2.2.2. Stateful processing 584 It is possible that some or all user agents connected to a SIP 585 network do not support "log me" marking, or that "log me" marking is 586 removed from SIP messages by the originating or terminating network. 587 These scenarios require SIP intermediaries to maintain state to 588 enable "log me" marking: 590 o The originating UA does not support "log me" marking. 592 o The originating network removes "log me" marking from SIP requests 593 and responses before forwarding them from its network edge to 594 external network. 596 o The terminating UA does not support "log me" marking. 598 o The terminating network removes "log me" marking from SIP requests 599 and responses received from its network edge to internal network. 601 The sections below illustrate SIP intermediary behavior in these 602 scenarios using [RFC3665] example call flow "Session Establishment 603 Through Two Proxies". 605 4.2.2.2.1. "Log Me" marking not supported by Originating UA 607 Alice's user agent does not support "log me" marking and hence Proxy 608 1 which is the SIP intermediary closest to Alice is configured to act 609 on behalf of Alice's user agent to "log me" mark dialogs created by 610 Alice. 612 In Figure 3 below, Proxy 1 in the originating network maintains state 613 of which dialogs are being logged in order to "log me" mark all SIP 614 requests and responses that it receives from Alice's user agent 615 before forwarding them to Proxy 2. 617 [ NETWORK A ] [ NETWORK B ] 618 Alice Proxy 1 Proxy 2 Bob 619 | | | | 620 | INVITE F1 | | | 621 | (no logme) | | | 622 |--------------->| | | 623 | | INVITE F2 | | 624 | | (logme) | | 625 | |--------------->| | 626 | | | | 627 | | | | 628 | 100 F3 | | INVITE F4 | 629 | (logme) | | (logme) | 630 |<---------------| 100 F5 |--------------->| 631 | | (logme) | | 632 | |<---------------| | 633 | | | 180 F6 | 634 | | | (logme) | 635 | | 180 F7 |<---------------| 636 | | (logme) | | 637 | 180 F8 |<---------------| | 638 | (logme) | | | 639 |<---------------| | 200 F9 | 640 | | | (logme) | 641 | | 200 F10 |<---------------| 642 | | (logme) | | 643 | 200 F11 |<---------------| | 644 | (logme) | | | 645 |<---------------| | | 646 | ACK F12 | | | 647 | (no logme) | | | 648 |--------------->| | | 649 | | | | 650 | | ACK F13 | | 651 | | (logme) | | 652 | |--------------->| | 653 | | | | 654 | | | ACK F14 | 655 | | | (logme) | 656 | | |--------------->| 657 | Both Way RTP Media | 658 |<================================================>| 659 | | | BYE F15 | 660 | | | (logme) | 661 | | BYE F16 |<---------------| 662 | | (logme) | | 663 | BYE F17 |<---------------| | 664 | (logme) | | | 665 |<---------------| | | 666 | 200 F18 | | | 667 | (no logme) | | | 668 |--------------->| | | 669 | | 200 F19 | | 670 | | (logme) | | 671 | |--------------->| | 672 | | | | 673 | | | 200 F20 | 674 | | | (logme) | 675 | | |--------------->| 676 | | | | 678 Figure 3: Case 1: The originating UA does not support "log me" 679 marking 681 F1 - Alice's UA does not insert a "log me" marker in the dialog- 682 creating INVITE request F1. Nevertheless, Proxy 1 is configured to 683 initiate logging on behalf of Alice. Proxy 1 logs INVITE request F1 684 and maintains state that this dialog is being logged. 686 F2 - Proxy 1 inserts a "log me" marker in INVITE request F2 before 687 forwarding it to Proxy 2 and also logs this request. 689 F3 - Proxy 1 inserts a "log me" marker in 100 response F3 before 690 forwarding it to Alice's UA since this is a response sent on a dialog 691 that is being "log me" marked and also logs this response. 693 F4 - Bob's UA detects the "log me" marker and logs the INVITE request 694 F4 if allowed as per policy. 696 F6 - Bob's UA echoes the "log me" marker in INVITE request F4 into 697 180 response F6. It logs this response if allowed as per policy. 699 F7 and F8 - Proxy 1 logs the received the "180" response F7 and 700 passes the "log me" marker to Alice's UA in F8. 702 F13 - Proxy 1 inserts a "log me" marker in ACK request F13 before 703 forwarding it to Proxy 2 and also logs this request. 705 F15 - Bob's UA inserts a "log me" marker in the in-dialog BYE request 706 and this "log me" marker is carried back to Alice's UA in F16 and 707 F17. Bob's UA logs this request if allowed as per policy. 709 F18 - Alice's UA does not echo the "log me" marker from BYE request 710 F17 into 200 response F18. 712 F19 - Proxy 1 inserts a "log me" marker in 200 response F19 before 713 forwarding it to Proxy 2 and also logs this response. 715 4.2.2.2.2. "Log Me" marking removed by Originating Network 717 If network A in Figure 4 below is performing testing independently of 718 network B then network A removes "log me" marking from SIP requests 719 and responses forwarded to network B to prevent triggering unintended 720 logging in network B. Proxy 1 removes "log me" marking from requests 721 and responses that it forwards to Proxy 2 and maintains state of 722 which dialogs are being "log me" marked in order to "log me" mark 723 requests and responses that it forwards from Proxy 2 to Alice's user 724 agent. Proxy 1 also logs requests and responses for the duration of 725 the dialog. 727 [ NETWORK A ] [ NETWORK B ] 728 Alice Proxy 1 Proxy 2 Bob 729 | | | | 730 | INVITE F1 | | | 731 | (logme) | | | 732 |--------------->| | | 733 | | INVITE F2 | | 734 | | (no logme) | | 735 | |--------------->| | 736 | | | | 737 | | | | 738 | 100 F3 | | | 739 | (logme) | | INVITE F4 | 740 | | | (no logme) | 741 |<---------------| 100 F5 |--------------->| 742 | | (no logme) | | 743 | |<---------------| | 744 | | | 180 F6 | 745 | | | (no logme) | 746 | | 180 F7 |<---------------| 747 | | (no logme) | | 748 | 180 F8 |<---------------| | 749 | (logme) | | | 750 |<---------------| | 200 F9 | 751 | | | (no logme) | 752 | | 200 F10 |<---------------| 753 | | (no logme) | | 754 | 200 F11 |<---------------| | 755 | (logme) | | | 756 |<---------------| | | 757 | ACK F12 | | | 758 | (logme) | | | 759 |--------------->| | | 760 | | | | 761 | | ACK F13 | | 762 | | (no logme) | | 763 | |--------------->| | 764 | | | | 765 | | | ACK F14 | 766 | | | (no logme) | 767 | | |--------------->| 768 | Both Way RTP Media | 769 |<================================================>| 770 | | | BYE F15 | 771 | | | (no logme) | 772 | | BYE F16 |<---------------| 773 | | (no logme) | | 774 | BYE F17 |<---------------| | 775 | (logme) | | | 776 |<---------------| | | 777 | 200 F18 | | | 778 | (logme) | | | 779 |--------------->| | | 780 | | 200 F19 | | 781 | | (no logme) | | 782 | |--------------->| | 783 | | | | 784 | | | 200 F20 | 785 | | | (no logme) | 786 | | |--------------->| 787 | | | | 789 Figure 4: Case 2: The originating network removes "log me" marking 790 from outgoing SIP messages at its network edge. 792 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 793 INVITE request and Proxy 1 therefore maintains state that this dialog 794 is to be logged. 796 F2 - Proxy 1 removes "log me" marking from INVITE request before 797 forwarding it to Proxy 2. Proxy 1 does not log INVITE request F2. 799 F3 - Proxy 1 inserts a "log me" marker in 100 response sent to 800 Alice's user agent. 802 F8 - Proxy 1 inserts a "log me" marker in 180 response before 803 forwarding it to Alice's user agent. The same applies to responses 804 F11, F17. 806 F13 - Proxy 1 removes "log me" marking from ACK request before 807 forwarding it to Proxy 2. 809 F19 - Proxy 1 removes "log me" marking from the 200 response of the 810 BYE request before forwarding it to Proxy 2. 812 4.2.2.2.3. "Log Me" marking not supported by Terminating UA 814 In Figure 5 below Bob's UA does not support "log me" marking, so 815 Proxy 2 in the terminating network maintains state to ensure "log me" 816 marking of SIP requests and responses from Bob's UA. 818 [ NETWORK A ] [ NETWORK B ] 819 Alice Proxy 1 Proxy 2 Bob 820 | | | | 821 | INVITE F1 | | | 822 | (log me) | | | 823 |--------------->| | | 824 | | INVITE F2 | | 825 | | (log me) 826 | |--------------->| | 827 | | | | 828 | | | | 829 | 100 F3 | | | 830 | (log me) | | | 831 |<---------------| | | 832 | | | INVITE F4 | 833 | | | (log me) | 834 | | 100 F5 |--------------->| 835 | | (log me) | | 836 | |<---------------| | 837 | | | 180 F6 | 838 | | | (no log me) | 839 | | |<---------------| 840 | | | | 841 | | | | 842 | | 180 F7 | | 843 | | (log me) | | 844 | |<---------------| | 845 | | | | 846 | | | | 847 | 180 F8 | | | 848 | (log me) | | | 849 |<---------------| | 200 F9 | 850 | | | (no log me) | 851 | | 200 F10 |<---------------| 852 | | (log me) | | 853 | 200 F11 |<---------------| | 854 | (log me) | | | 855 |<---------------| | | 856 | ACK F12 | | | 857 | (log me) | | | 858 |--------------->| | | 859 | | ACK F13 | | 860 | | (log me) | | 861 | |--------------->| ACK F14 | 862 | | | (log me) | 863 | | |--------------->| 864 | Both Way RTP Media | 865 |<================================================>| 866 | | | BYE F15 | 867 | | | (no log me) | 868 | | BYE F16 |<---------------| 869 | | (log me) | | 870 | BYE F17 |<---------------| | 871 | (log me) | | | 872 |<---------------| | | 873 | 200 F18 | | | 874 | (log me) | | | 875 |--------------->| 876 | | 200 F19 | | 877 | | (log me) | | 878 | |--------------->| 200 F20 | 879 | | | (log me) | 880 | | |--------------->| 881 | | | | 883 Figure 5: Case 3: The terminating UA does not support "log me" 884 marking. 886 F1 - Alice's UA inserts a "log me" marker in the the dialog-creating 887 INVITE request F1. 889 F2 - INVITE F2 is "log me" marked and Proxy 2 therefore maintains 890 state that this dialog is to be logged. Proxy 2 logs the request and 891 responses of this dialog if allowed per policy. 893 F5 - Proxy 2 inserts a "log me" marker in the 100 response it sends 894 to Proxy 1. 896 F6 - Bob's UA does not support "log me" marking, therefore the 180 897 response to the INVITE request doesn't have a "log me" marker. 899 F7 - Proxy 2 inserts a "log me" marker in the 180 response on behalf 900 of Bob's UA before forwarding it. The same applies to response F10 901 and the BYE request in F16. 903 4.2.2.2.4. "Log Me" marking removed by Terminating Network 905 In Figure 6 below Proxy 2 removes "log me" marking from all SIP 906 requests and responses entering network B. Proxy 1 maintains the 907 marking state of the dialog. When Proxy 1 observes that requests and 908 responses received from Proxy 2 are not marked it adds the marking. 910 [ NETWORK A ] [ NETWORK B ] 911 Alice Proxy 1 Proxy 2 Bob 912 | | | | 913 | INVITE F1 | | | 914 | (log me) | | | 915 |--------------->| | | 916 | | INVITE F2 | | 917 | | (log me) | | 918 | |--------------->| | 919 | | | | 920 | | | | 921 | 100 F3 | | | 922 | (log me) | | | 923 |<---------------| | | 924 | | | INVITE F4 | 925 | | | (no log me) | 926 | | 100 F5 |--------------->| 927 | | (no log me) | | 928 | |<---------------| | 929 | | | 180 F6 | 930 | | | (no log me) | 931 | | |<---------------| 932 | | 180 F7 | | 933 | | (no log me) | | 934 | |<---------------| | 935 | | | | 936 | | | | 937 | 180 F8 | | | 938 | (log me) | | | 939 |<---------------| | 200 F9 | 940 | | | (no log me) | 941 | | 200 F10 |<---------------| 942 | | (no log me) | | 943 | 200 F11 |<---------------| | 944 | (log me) | | | 945 |<---------------| | | 946 | ACK F12 | | | 947 | (log me) | | | 948 |--------------->| | | 949 | | ACK F13 | | 950 | | (log me) | | 951 | |--------------->| ACK F14 | 952 | | | (no log me) | 953 | | |--------------->| 954 | Both Way RTP Media | 955 |<================================================>| 956 | | | BYE F15 | 957 | | | (no log me) | 958 | | BYE F16 |<---------------| 959 | | (no log me) | | 960 | BYE F17 |<---------------| | 961 | (log me) | | | 962 |<---------------| | | 963 | 200 F18 | | | 964 | (log me) | | | 965 |--------------->| | | 966 | | 200 F19 | | 967 | | (log me) | | 968 | |--------------->| 200 F20 | 969 | | | (no log me) | 970 | | |--------------->| 971 | | | | 973 Figure 6: Case 2: The terminating network removes "log me" marking 974 from incoming SIP messages at its network edge. 976 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 977 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 978 request and maintains state that this dialog is to be logged. 980 F2 - Proxy 2 removes "log me" marker in the INVITE request F2 before 981 forwarding it as F7. 983 F7 - Proxy 1 inserts a "log me" marker in 180 response of the INVITE 984 request before forwarding it as F8. The same applies to response F10 985 and the BYE request in F16. 987 5. Error Handling 988 5.1. Missing "Log me" Marker in Dialog Being Logged 990 "log me" marking is done per dialog, therefore if a user agent or 991 edge proxy that has been "log me" marking requests and responses in a 992 given dialog receives a SIP request or response that has not been 993 "log me" marked as expected, this is an error. User agents and 994 proxies that are stateless with respect to "log me" marking are not 995 able detect such errors. User agents and proxies that are stateful 996 with respect to "log me" marking are able to detect that a marker is 997 missing from a dialog that has previously been "log me" marked. 999 In such cases, the user agent or proxy SHOULD consider "log me" 1000 marking to have ended and MUST NOT mark the forwarded request or 1001 response to the unmarked request, responses to subsequent requests in 1002 the dialog, or in-dialog requests sent from the terminating side. 1004 5.1.1. Error Cases 1006 The following figures illustrate error cases. 1008 Figure 7 shows an error detected at Proxy 1. 1010 [ NETWORK A ] [ NETWORK B ] 1011 Alice Proxy 1 Proxy 2 Bob 1012 | | | | 1013 | INVITE F1 | | | 1014 | (log me) | | | 1015 |--------------->| | | 1016 | | | | 1017 | | | | 1018 | 200 F2 | | | 1019 | (log me) | | | 1020 |<---------------| | | 1021 | | | | 1022 | ACK F3 | | | 1023 | (no log me) | | | 1024 |--------------->| | | 1026 Figure 7: Error cases: missing "log me" marker 1028 F1 - Proxy 1 detects the "log me" marker and maintains state that 1029 this dialog is to be logged. 1031 F3 - Proxy 1 detects that the expected "log me" marker is missing and 1032 considers "log me" marking to have ended. 1034 Figure 8 shows an error detected at Proxy 2 and Bob's user agent. 1036 [ NETWORK A ] [ NETWORK B ] 1037 Alice Proxy 1 Proxy 2 Bob 1038 | INVITE F1 | | | 1039 | (log me) | | | 1040 |--------------->| | | 1041 | | INVITE F2 | | 1042 | | (log me) | | 1043 | |--------------->| | 1044 | | | | 1045 | | | | 1046 | 100 F3 | | | 1047 | (log me) | | | 1048 |<---------------| | | 1049 | | | INVITE F4 | 1050 | | | (log me) | 1051 | | 100 F5 |--------------->| 1052 | | (log me) | | 1053 | |<---------------| | 1054 | | | 180 F6 | 1055 | | | (log me) | 1056 | | |<---------------| 1057 | | 180 F7 | | 1058 | | (log me) | | 1059 | |<---------------| | 1060 | | | | 1061 | | | | 1062 | 180 F8 | | | 1063 | (log me) | | | 1064 |<---------------| | 200 F9 | 1065 | | | (log me) | 1066 | | 200 F10 |<---------------| 1067 | | (log me) | | 1068 | 200 F11 |<---------------| | 1069 | (log me) | | | 1070 |<---------------| | | 1071 | ACK F12 | | | 1072 | (no log me) | | | 1073 |--------------->| | | 1074 | | ACK F13 | | 1075 | | (no log me) | | 1076 | |--------------->| ACK F14 | 1077 | | | (no log me) | 1078 | | |--------------->| 1080 Figure 8: Error cases: missing "log me" marker 1082 F2 - Proxy 2 detects the "log me" marker and maintains state that 1083 this dialog is to be logged. 1085 F4 - Bob's user agent detects the "log me" marker and maintains state 1086 that this dialog is to be logged. 1088 F12 - Proxy 1 detects that the expected "log me" marker is missing 1089 and considers "log me" marking to have ended. Hence it does not 1090 insert a "log me" marker in F13. 1092 F13 - Proxy 2 detects that the expected "log me" marker is missing 1093 and considers "log me" marking to have ended. 1095 F14 - Proxy 2 does not insert a "log me" marker because it considers 1096 "log me" marking to have ended. Bob's UA detects that the expected 1097 "log me" marker is missing and considers "log me" marking to have 1098 ended. 1100 5.1.2. Non-Error Cases 1102 The following figures illustrate non-error cases. 1104 Figure 9 shows Proxy 2 receiving a response with no "log me" marker 1105 that is not an error case. Proxy 2 is configured by network B to 1106 perform "log me" marking on behalf of Bob's UA, which does not 1107 support "log me" marking. Proxy 2 does not therefore expect 1108 responses from Bob to include a "log me" marker. 1110 [ NETWORK A ] [ NETWORK B ] 1111 Alice Proxy 1 Proxy 2 Bob 1112 | | | | 1113 | INVITE F1 | | | 1114 | (log me) | | | 1115 |--------------->| | | 1116 | | INVITE F2 | | 1117 | | (log me) | | 1118 | |--------------->| | 1119 | | | | 1120 | | | | 1121 | 100 F3 | | | 1122 | (log me) | | | 1123 |<---------------| | | 1124 | | | INVITE F4 | 1125 | | | (log me) | 1126 | | 100 F5 |--------------->| 1127 | | (log me) | | 1128 | |<---------------| | 1129 | | | 180 F6 | 1130 | | | (no log me) | 1131 | | |<---------------| 1132 | | 180 F7 | | 1133 | | (log me) | | 1134 | |<---------------| | 1135 | | | | 1137 Figure 9: Non-error cases: missing "log me" marker 1139 F2 - Proxy 2 detects the "log me" marker and maintains state that 1140 this dialog is to be logged. Proxy 2 inserts "log me" markers on 1141 behalf of Bob's user agent such as in F7. 1143 F6 - Proxy 2 detects that the "log me" marker is missing from the 1144 response but considers "log me" marking to be ongoing as a marker was 1145 not expected. 1147 F7 - Proxy 2 continues to "log me" mark requests and responses on 1148 behalf of Bob's user agent. 1150 5.2. "Log Me" Marker Appears Mid-Dialog 1152 "log me" marking that begins mid-dialog is an error case and the 1153 terminating user agent or edge proxy MUST NOT "log me" mark responses 1154 to the marked request, responses to subsequent requests in the 1155 dialog, or in-dialog requests from the terminating side. 1157 6. Security Considerations 1159 6.1. "Log Me" Authorization 1161 An end user or network administrator MUST give permission for a 1162 terminal to perform "log me" marking. The configuration of a SIP 1163 intermediary to perform "log me" marking on behalf of a terminal MUST 1164 be authorized by the network administrator. 1166 Activating a debug mode affects the operation of a terminal, 1167 therefore debugging configuration MUST be supplied by an authorized 1168 party to an authorized terminal through a secure communication 1169 channel. 1171 6.2. "Log Me" Marker Removal 1173 The log me marker is not sensitive information, although it will 1174 sometimes be inserted because a particular device is experiencing 1175 problems. 1177 The presence of a log me marker will cause some SIP entities to log 1178 signaling messages. Therefore, this marker MUST be removed at the 1179 earliest opportunity if it has been incorrectly inserted, such as 1180 appearing mid-dialog in a dialog that was not being logged or outside 1181 the configured start and stop of logging. 1183 If SIP requests and responses are exchanged with an external network 1184 with which there is no agreement to pass "log me" marking, then the 1185 "log me" marking is removed. 1187 6.3. Denial of Service Attacks 1189 Maliciously configuring a large number of terminals to simultaneously 1190 "log me" mark dialogs will cause high processor load on SIP entities 1191 that are logging signalling. Since "log me" marking is for the small 1192 number of dialogs subject to troubleshooting or regression testing, 1193 the number of dialogs that can be simultaneously logged can be 1194 statically limited without adversely affecting the usefulness of "log 1195 me" marking. Also, the SIP intermediary closest to the terminal and 1196 SIP intermediary at network edge (e.g Session Border Controllers) can 1197 be configured to screen-out "log me" markers when troubleshooting or 1198 regression testing is not in progress. 1200 6.4. Privacy 1202 Logging includes all SIP header fields, the SIP privacy mechanisms 1203 defined in [RFC3323] can be used to ensure that logs do not divulge 1204 personal identity information. 1206 6.4.1. Personal Identifiers 1208 "Log me" marking is defined for the SIP Protocol, and SIP has header 1209 fields such as From, Contact, P-Asserted-Identity that can carry 1210 personal identifiers. Different protocol interactions can be 1211 correlated using the Session-ID and Call-ID header fields, but such 1212 correlation is limited to a single end-to-end session. 1214 In order to protect user privacy during logging, privacy settings can 1215 be enabled or requested by the terminal used by the end user. 1216 [RFC3323] suggests two mechanisms: 1218 o By using the value anonymous in the From header field 1220 o By requesting privacy from SIP intermediaries using the Privacy 1221 header 1223 "Log me" marking is typically used for troubleshooting and regression 1224 testing, and in some cases a service provider owned device with a 1225 dummy account can be used instead of a customer device. In such 1226 cases, no personal identifiers are included in the logged signaling 1227 messages. 1229 6.4.2. Data Stored at SIP Intermediaries 1231 SIP endpoints and intermediaries that honor the "log me" request 1232 store all the SIP messages that are exchanged within a given dialog. 1233 SIP messages can contain the personal identifiers listed in 1234 Section 6.4.1 and additionally a user identity, calling party number, 1235 IP address, hostname, and other user and device related items. The 1236 SIP message bodies describe the kind of session being set up by the 1237 identified end user and device. 1239 "Log me" marking does not introduce any additional user or device 1240 data to SIP but might indicate that a specific user is experiencing a 1241 problem. 1243 6.4.3. Data Visible at Network Elements 1245 SIP messages that are logged due to "log me" requests are stored only 1246 by the SIP initiators, intermediaries and recipients. Enablers as 1247 defined in section 3.1 of [RFC6973], such as firewalls and DNS 1248 servers do not log messages due to the "log me" marking. 1250 6.4.4. Preventing Fingerprinting 1252 "Log me" functionality is typically used to troubleshoot a given 1253 problem and hence it can be used as an method to identify users and 1254 devices that are experiencing issues. The best way to prevent 1255 fingerprinting is to enable or request SIP privacy for the logged 1256 dialog. 1258 6.4.5. Retaining Logs 1260 The lifetime of "log me" marking is equivalent to the lifetime of the 1261 dialog that initiated the "log me" request. When "log me" is 1262 extended to related dialogs the lifetime is extended until there is 1263 no more related dialog for the end-to-end session. 1265 "log me" automatically expires at the end of the dialog and there is 1266 no explicit mechanism to turn off logging within a dialog. 1268 The scope of "log me" Marking is limited i.e. an user or the network 1269 administrator has to enable it on a per session basis or for a 1270 specific time period. This minimizes the risk of exposing user data 1271 for an indefinite time. 1273 The retention time period for logged messages is out of scope for 1274 this document and is expected to be configured based on the data 1275 storage policies of service providers and enterprises. 1277 6.4.6. User Control of Logging 1279 Consent to turn on "log me" for a given session MUST be provided by 1280 the end user or by the network administrator. It is handled outside 1281 of the protocol through user interface or application programming 1282 interfaces at the end point, call control elements and network 1283 management systems. 1285 SIP entities across the communication path can be configured to pass 1286 through the "log me" marking but not honor the request i.e. not log 1287 the data based on local policies. 1289 6.4.7. Recommended Defaults 1291 The recommended defaults for "log me" marking are: 1293 o turn on SIP privacy as described in Section 6.4 or use a service 1294 provider owned device with a dummy user identity for test calls 1296 o use the local UUID of Session-ID header at the originating device 1297 as the test case identifier as described in Section 3.3 1299 6.5. Data Protection 1301 A SIP entity that has logged information MUST protect the logs. 1302 Storage of the log files are subject to the security considerations 1303 specified in [RFC6872]. 1305 7. Augmented BNF for the "logme" Parameter 1307 ABNF is described in [RFC5234]. This document introduces a new 1308 "logme"parameter for the Session-ID header field defined in Section 5 1309 of [RFC7989]. 1311 sess-id-param =/ logme-param 1313 logme-param = "logme" 1315 Figure 10: Augmented BNF for the "logme" Parameter 1317 8. IANA Considerations 1319 8.1. Registration of the "logme" Parameter 1321 The following parameter is to be added to the "Header Field 1322 Parameters and Parameter Values" section of the SIP parameter 1323 registry: 1325 +--------------+----------------+-------------------+-----------+ 1326 | Header Field | Parameter Name | Predefined Values | Reference | 1327 +--------------+----------------+-------------------+-----------+ 1328 | Session-ID | logme | No | [RFCXXXX] | 1329 +--------------+----------------+-------------------+-----------+ 1331 Table 1 1333 9. Acknowledgments 1335 The authors wish to thank Paul Giralt, Paul Kyzivat, Jorgen Axell and 1336 Vijay Gurbani for their constructive review comments and guidance 1337 while developing this document. 1339 10. References 1340 10.1. Normative References 1342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1343 Requirement Levels", BCP 14, RFC 2119, 1344 DOI 10.17487/RFC2119, March 1997, 1345 . 1347 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1348 A., Peterson, J., Sparks, R., Handley, M., and E. 1349 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1350 DOI 10.17487/RFC3261, June 2002, 1351 . 1353 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1354 H., and O. Festor, "The Common Log Format (CLF) for the 1355 Session Initiation Protocol (SIP): Framework and 1356 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1357 February 2013, . 1359 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1360 Session Initiation Protocol (SIP) Common Log Format 1361 (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, 1362 . 1364 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1365 Kaplan, "Requirements for an End-to-End Session 1366 Identification in IP-Based Multimedia Communication 1367 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1368 . 1370 [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- 1371 to-End Session Identification in IP-Based Multimedia 1372 Communication Networks", RFC 7989, DOI 10.17487/RFC7989, 1373 October 2016, . 1375 10.2. Informative References 1377 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1378 Initiation Protocol (SIP)", RFC 3323, 1379 DOI 10.17487/RFC3323, November 2002, 1380 . 1382 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1383 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1384 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1385 December 2003, . 1387 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1388 Specifications: ABNF", STD 68, RFC 5234, 1389 DOI 10.17487/RFC5234, January 2008, 1390 . 1392 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1393 Initiation Protocol (SIP) Call Control - Transfer", 1394 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1395 . 1397 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1398 Morris, J., Hansen, M., and R. Smith, "Privacy 1399 Considerations for Internet Protocols", RFC 6973, 1400 DOI 10.17487/RFC6973, July 2013, 1401 . 1403 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1404 Initiation Protocol (SIP) Back-to-Back User Agents", 1405 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1406 . 1408 [RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking 1409 SIP Messages to be Logged", RFC 8123, 1410 DOI 10.17487/RFC8123, March 2017, 1411 . 1413 Authors' Addresses 1415 Peter Dawes 1416 Vodafone Group 1417 The Connection 1418 Newbury, Berkshire RG14 2FN 1419 UK 1421 Email: peter.dawes@vodafone.com 1423 Chidambaram Arunachalam 1424 Cisco Systems 1425 7200-12 Kit Creek Road 1426 Research Triangle Park, NC, NC 27709 1427 US 1429 Email: carunach@cisco.com