idnits 2.17.1 draft-ietf-insipid-logme-marking-09.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 37 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 161 has weird spacing: '...ple.com p1.ex...' -- The document date (December 19, 2017) is 2320 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 1473, but not defined == Unused Reference: 'RFC7206' is defined on line 1511, 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: June 22, 2018 Cisco Systems 6 December 19, 2017 8 Marking SIP Messages to be Logged 9 draft-ietf-insipid-logme-marking-09 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 https://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 June 22, 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 (https://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 . . . . . . . . . . 6 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 Acting on Behalf of Endpoints . . . . 12 78 4.3. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.4. "Log me" Marker Processing by SIP Intermediaries . . . . 14 80 4.4.1. Stateless processing . . . . . . . . . . . . . . . . 14 81 4.4.2. Stateful processing . . . . . . . . . . . . . . . . . 14 82 4.4.2.1. "Log Me" marking not supported by Originating UA 15 83 4.4.2.2. "Log Me" marking removed by Originating Network . 19 84 4.4.2.3. "Log Me" marking not supported by Terminating UA 22 85 4.4.2.4. "Log Me" marking removed by Supporting 86 Terminating Network . . . . . . . . . . . . . . . 24 87 4.4.2.5. "Log Me" marking removed by Non-Supporting 88 Terminating Network . . . . . . . . . . . . . . . 25 89 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 27 90 5.1. Missing "Log me" Marker in Dialog Being Logged . . . . . 27 91 5.1.1. Missing "Log me" Marker Error Cases . . . . . . . . . 28 92 5.2. "Log Me" Marker Appears Mid-Dialog . . . . . . . . . . . 31 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 95 6.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 31 96 6.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 31 97 6.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 32 98 6.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 6.4.1. Personal Identifiers . . . . . . . . . . . . . . . . 32 100 6.4.2. Data Stored at SIP Intermediaries . . . . . . . . . . 33 101 6.4.3. Data Visible at Network Elements . . . . . . . . . . 33 102 6.4.4. Preventing Fingerprinting . . . . . . . . . . . . . . 33 103 6.4.5. Retaining Logs . . . . . . . . . . . . . . . . . . . 33 104 6.4.6. User Control of Logging . . . . . . . . . . . . . . . 34 105 6.4.7. Recommended Defaults . . . . . . . . . . . . . . . . 34 106 6.5. Data Protection . . . . . . . . . . . . . . . . . . . . . 34 107 7. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 34 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 109 8.1. Registration of the "logme" Parameter . . . . . . . . . . 35 110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 113 10.2. Informative References . . . . . . . . . . . . . . . . . 36 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 116 1. Introduction 118 When users experience problems with setting up sessions using SIP, 119 enterprise or service provider network operators need to identify 120 root cause by examining the SIP signaling. Also, when network or 121 user agent software or hardware is upgraded, regression testing is 122 needed. Such diagnostics apply to a small proportion of network 123 traffic and can apply end-to-end, even if signaling crosses several 124 networks possibly belonging to several different network operators. 125 It may not be possible to predict the path through those networks in 126 advance, therefore a mechanism is needed to mark a session as being 127 of interest so that SIP entities along the signaling path can provide 128 diagnostic logging. [RFC8123] illustrates this motivating scenario. 129 This document describes a solution that meets the requirements for 130 such 'log me' marking of SIP signaling also defined in [RFC8123]. 132 This document defines a new header field parameter "logme" for the 133 "Session-ID" header field. Implementations of this document MUST 134 implement session identity specified in [RFC7989]. 136 2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119], except that 141 rather than describing interoperability requirements, they are used 142 to describe requirements to be satisfied by the "log me" marking 143 solution. 145 3. "Log Me" Marking Protocol Aspects 147 3.1. Session-ID logme Parameter 149 Logging is most effective when it is applied end-to-end in a 150 communication session. This ability requires a "log me" marker to be 151 passed through SIP intermediaries. The Session-ID header defined in 152 ([RFC7989]) was chosen to carry the "log me" marker as a "log me" 153 parameter since the session identifier is passed through SIP B2BUAs 154 or other intermediaries. The "logme" parameter shown in Figure 1 155 does not introduce any device-specific or user-specific information 156 and MUST be passed unchanged through SIP B2BUAs or other 157 intermediaries. (See Section 3.4.2 where this normative behavior may 158 be relaxed for intermediaries in an external network.) 160 Alice Proxy Registrar 161 u1.example.com p1.example.com r1.example.com 162 | | | 163 |(1) INVITE | | 164 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; 165 | remote=47755a9de7794ba387653f2099600ef2;logme 166 |----------------->| | 167 | | | 169 Figure 1: "Log Me" marking using the "logme" Session-ID header field 170 parameter 172 3.2. Starting and Stopping Logging 174 As indicated in [RFC8123] REQ111, marking starts with a dialog- 175 initiating request and continues for the lifetime of the dialog, and 176 applies to each request and response in that dialog. 178 A user agent or proxy adds a "log me" marker in a request or response 179 in two cases: firstly because it is configured to do so, or secondly 180 because it has detected that a dialog is being "log me" marked, 181 causing it to maintain state to ensure that all requests and 182 responses in the dialog are similarly "log me" marked. Once the "log 183 me" marking is started for a dialog, all subsequent requests and 184 responses in this dialog are "log me" marked and marking is stopped 185 when this dialog and it's related dialogs end. It is considered an 186 error if "log me" marking is started in a mid-dialog request or 187 response. 189 If a request or response is "log me" marked, then all re- 190 transmissions of the request or response MUST be similarly "log me" 191 marked. Likewise, re-transmissions of a request or response that was 192 not "log me" marked MUST NOT be "log me" marked. 194 For the first case, "log me" marking trigger condition configurations 195 that define whether a user agent or proxy can initiate "log me" 196 marking for a given dialog is out of scope of this document. As 197 example trigger condition configurations, the user agent or proxy 198 could be configured to add a "log me" marker for all dialogs 199 initiated during a specific time period (e.g., 9:00 am - 10:00 am 200 every day), for specific dialogs that have a particular "User-Agent" 201 header value, or for a specific set of called party numbers for which 202 users are experiencing call setup failures. 204 For the second case of a user agent or proxy detecting that a dialog- 205 initiating request is being "log me" marked, the scope of such 206 marking extends to the lifetime of the dialog. In addition, as 207 discussed in Section 3.7, "log me" marked dialogs that create related 208 dialogs (REFER) may transfer the marking to the related dialogs. In 209 such cases, the entire "session", identified by the Session-ID 210 header, is "log me" marked. 212 3.3. Identifying Test Cases 214 The local Universally Unique Identifier (UUID) portion of Session-ID 215 [RFC7989] in the initial SIP request of a dialog is used as a random 216 test case identifier. This provides the ability to collate all 217 logged SIP requests and responses to the initial SIP request in a 218 dialog or standalone transaction. 220 3.4. Passing the Marker 222 3.4.1. To and From a User Device 224 When a user device inserts the "log me" marker, the marker MUST be 225 passed unchanged in the Session-ID header across an edge proxy or a 226 B2BUA adjacent to the user device. 228 3.4.2. To and From an External Network 230 An external network is a peer network connected at a network boundary 231 as defined in [RFC8123]. 233 External networks may be connected directly or via a peering network 234 and such networks SHOULD have specific connection agreements. 235 Whether "log me" marking is removed depends upon the policy applied 236 at the network to network interface. Peer networks SHOULD endeavor 237 to make agreements to pass "log me" marking unchanged. However, 238 since a "log me" marker may cause a SIP entity to log the SIP header 239 and body of a request or response, if no agreement exists between 240 peer networks then the "log me" marker MUST be removed at a network 241 boundary. 243 3.5. Logging Multiple Simultaneous Dialogs 245 An originating or terminating user agent and SIP entities on the 246 signaling path can log multiple SIP dialogs simultaneously. These 247 dialogs are differentiated by their test case identifier (the local 248 UUID of the Session-ID header field at the originating device). 250 3.6. Format of Logged Signaling 252 The entire SIP message (SIP headers and message body) MUST be logged. 253 Logging SHOULD use common standard formats such as the SIP CLF 254 defined in [RFC6873] and Libpcap. If SIP CLF format is used, the 255 entire message is logged using Vendor-ID = 00000000 and Tag = 02 in 256 the portion of the SIP CLF record (see [RFC6873] 257 clause 4.4). Header fields SHOULD be logged in the form in which 258 they appear in the message, they SHOULD NOT be converted between long 259 and compact forms described in [RFC3261] clause 7.3.3. 261 3.7. Marking Related Dialogs 263 "Log me" marking is done per-dialog and typically begins at dialog 264 creation and ends when the dialog ends. However, dialogs related to 265 a "log me" marked dialog MAY also be "log me" marked. An example is 266 call transfer described in section 6.1 of [RFC5589] and the logged 267 signalling for related dialogs can be correlated using Session-ID 268 values as described in section 10.9 of [RFC7989]. 270 In the example shown in Figure 2 below, Alice has reported problems 271 making call transfers. Her terminal is configured to log signalling 272 and the network administrator Bob, who is troubleshooting the 273 problem, arranges to make a call that Alice can attempt to transfer. 274 Bob calls Alice, which creates initial dialog1, and then Alice 275 transfers the call to connect Bob to Carol. Logged signalling is 276 correlated using the test case identifier, which is the local UUID 277 ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of 278 INVITE request F1. Logging by Alice's terminal begins when it 279 receives and echoes the "logme" marker in INVITE F1 and ends when the 280 last request or response in the dialog is sent or received (200 OK F7 281 of dialog1). Also during dialog1, Alice's terminal logs related 282 REFER dialog2 that it initiates and terminates as part of the call 283 transfer. Both dialog1 and dialog2 have the same test case 284 identifier. 286 Logging by Bob's terminal begins when it sends INVITE F1, which 287 includes the "logme" marker, and ends when dialog3, initiated by Bob, 288 ends. Logging by Carol's terminal begins when it receives the INVITE 289 F5 with the "log me" marker and ends when dialog3 ends. 291 dialog3 is not logged by Alice's terminal, however the test case 292 identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case 293 identifier local-uuid) in INVITE F5. Also, the test case identifier 294 of dialog2, which is logged by Alice's terminal, can be linked to 295 dialog1 and dialog3 because the remote-uuid component of dialog2 is 296 the test case identifier ab30317f1a784dc48ff824d0d3715d86. 298 F1 - Bob's UA inserts "logme" parameter in the Session-ID header of 299 the INVITE request that creates dialog1. 301 F3 - Alice's UA inserts "logme" parameter in the Session-ID header of 302 the REFER request that creates dialog2 which is related to dialog1. 304 F5 - Bob's UA inserts "logme" parameter in the Session-ID header of 305 the INVITE request that creates dialog3 which is related to dialog1. 307 Alice Bob Carol 308 Transferor Transferee Transfer 309 | | Target 310 | INVITE F1 | | 311 dialog1 |<-------------------| | 312 | 200 OK F2 | | 313 dialog1 |------------------->| | 314 | ACK | | 315 dialog1 |<-------------------| | 316 | INVITE (hold) | | 317 dialog1 |------------------->| | 318 | 200 OK | | 319 dialog1 |<-------------------| | 320 | ACK | | 321 dialog1 |------------------->| | 322 | REFER F3 (Target-Dialog:1) | 323 dialog2 |------------------->| | 324 | 202 Accepted | | 325 dialog2 |<-------------------| | 326 | NOTIFY (100 Trying) F4 | 327 dialog2 |<-------------------| | 328 | 200 OK | | 329 dialog2 |------------------->| | 330 | | INVITE F5 | 331 dialog3 | |------------------->| 332 | | 200 OK | 333 dialog3 | |<-------------------| 334 | | ACK | 335 dialog3 | |------------------->| 336 | NOTIFY (200 OK) F6| | 337 dialog2 |<-------------------| | 338 | 200 OK | | 339 dialog2 |------------------->| | 340 | BYE | | 341 dialog1 |------------------->| | 342 | 200 OK F7 | | 343 dialog1 |<-------------------| | 344 | | BYE | 345 dialog3 | |<-------------------| 346 | | 200 OK | 347 dialog3 | |------------------->| 349 Figure 2: "Log me" marking related dialogs in call transfer 351 F1 INVITE Transferee -> Transferor 352 INVITE sips:transferor@atlanta.example.com SIP/2.0 353 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 354 Max-Forwards: 70 355 To: 356 From: ;tag=7553452 357 Call-ID: 090459243588173445 358 Session-ID: ab30317f1a784dc48ff824d0d3715d86 359 ;remote=00000000000000000000000000000000;logme 360 CSeq: 29887 INVITE 361 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 362 Supported: replaces, gruu, tdialog 363 Contact: 364 Content-Type: application/sdp 365 Content-Length: ... 367 F2 200 OK Transferor -> Transferee 369 SIP/2.0 200 OK 370 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 371 To: ;tag=31kdl4i3k 372 From: ;tag=7553452 373 Call-ID: 090459243588173445 374 Session-ID: 47755a9de7794ba387653f2099600ef2 375 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 376 CSeq: 29887 INVITE 377 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 378 Supported: replaces, gruu, tdialog 379 Contact: 380 Content-Type: application/sdp 381 Content-Length: ... 383 F3 REFER Transferor -> Transferee 385 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 386 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 387 Max-Forwards: 70 388 To: 389 From: ;tag=1928301774 390 Call-ID: a84b4c76e66710 391 Session-ID: 47755a9de7794ba387653f2099600ef2 392 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 393 CSeq: 314159 REFER 394 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 395 Supported: gruu, replaces, tdialog 396 Require: tdialog 397 Refer-To: 398 Target-Dialog: 090459243588173445;local-tag=7553452 399 ;remote-tag=31kdl4i3k 400 Contact: 401 Content-Length: 0 403 F4 NOTIFY Transferee -> Transferor 405 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 406 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 407 Max-Forwards: 70 408 To: ;tag=1928301774 409 From: 410 ;tag=a6c85cf 411 Call-ID: a84b4c76e66710 412 Session-ID: ab30317f1a784dc48ff824d0d3715d86 413 ;remote=47755a9de7794ba387653f2099600ef2;logme 414 CSeq: 73 NOTIFY 415 Contact: 416 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 417 Supported: replaces, tdialog 418 Event: refer 419 Subscription-State: active;expires=60 420 Content-Type: message/sipfrag 421 Content-Length: ... 423 F5 INVITE Transferee -> Transfer Target 425 INVITE sips:transfertarget@chicago.example.com SIP/2.0 426 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 427 Max-Forwards: 70 428 To: 429 From: ;tag=j3kso3iqhq 430 Call-ID: 90422f3sd23m4g56832034 431 Session-ID: ab30317f1a784dc48ff824d0d3715d86 432 ;remote=00000000000000000000000000000000;logme 433 CSeq: 521 REFER 434 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 435 Supported: replaces, gruu, tdialog 436 Contact: 437 Content-Type: application/sdp 438 Content-Length: ... 440 F6 NOTIFY Transferee -> Transferor 442 NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0 443 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 444 Max-Forwards: 70 445 To: ;tag=1928301774 446 From: 447 ;tag=a6c85cf 448 Call-ID: a84b4c76e66710 449 Session-ID: ab30317f1a784dc48ff824d0d3715d86 450 ;remote=47755a9de7794ba387653f2099600ef2;logme 451 CSeq: 74 NOTIFY 452 Contact: 453 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 454 Supported: replaces, tdialog 455 Event: refer 456 Subscription-State: terminated;reason=noresource 457 Content-Type: message/sipfrag 458 Content-Length: ... 460 3.8. Forked Requests 462 The "log me" marker MUST be copied into forked requests. 464 4. SIP Entity Behavior 466 "Log me" marking is initiated on a dialog creating side controlled by 467 configuration. The dialog terminating side detects an incoming "log 468 me" marker and reacts accordingly. 470 4.1. Endpoints 472 A common scenario is to have both originating and terminating 473 endpoints support "log me" marking specification with the originating 474 endpoint configured to initiate "log me" marking. In this simplest 475 use case, the originating user agent inserts a "log me" marker in the 476 dialog-creating SIP request and all subsequent SIP requests within 477 that dialog. The "log me" marker is passed through the SIP 478 intermediaries and arrives at the terminating user agent which echoes 479 the "log me" marker in the corresponding responses. If the 480 terminating user agent sends an in-dialog request on a dialog that is 481 being "log me" marked, it inserts a "log me" marker and the 482 originating user agent echoes the "log me" marker in responses. The 483 terminating user agent logs the "log me" marked SIP requests and 484 responses if it is allowed as per policy defined in the termination 485 network. This basic use case suggests the following principles: 487 o The originating user agent configured for "log me" marking MUST 488 insert a "log me" marker into the dialog-creating SIP request and 489 subsequent in-dialog SIP requests. 491 o The originating user agent itself logs signaling. 493 o The terminating user agent detects that a dialog is of interest to 494 logging by the existence of a "log me" marker in an incoming 495 dialog-creating SIP request. 497 o The terminating user agent itself logs marked requests and 498 corresponding responses if allowed as per policy. 500 o The terminating user agent MUST echo a "log me" marker in 501 responses to a SIP request that included a "log me" marker. 503 o If the terminating user agent has detected that a dialog is being 504 "log me" marked, it MUST insert a "log me" marker in any in-dialog 505 SIP requests that it sends. 507 o The terminating user agent itself logs any in-dialog SIP requests 508 that it sends if allowed as per policy. 510 o The originating user agent echoes, in responses, the "log me" 511 marker received in in-dialog requests from the terminating side. 513 o The originating user agent logs the SIP responses that it sends in 514 response to received "log me" marked in-dialog requests. 516 4.2. SIP Intermediaries Acting on Behalf of Endpoints 518 A network operator may know that some of the user agents connected to 519 the network do not support "log me" marking. In order to test 520 sessions involving such user agents, the SIP intermediary closest to 521 the user agent (e.g. edge proxies, B2BUA) on the originating and 522 terminating sides insert the "log me" marker instead. If the 523 terminating user agent does not echo this "log me" marker in 524 responses to that request then the the SIP intermediary closest to 525 the terminating user agent inserts a "log me" marker in responses to 526 the request. Likewise, if the terminating user agent sends an in- 527 dialog request, the SIP intermediary at the termination side inserts 528 a "log me" marker and the SIP intermediary at the origination side 529 echoes the "log me" marker in responses to that request. The SIP 530 intermediary at the terminating side logs the "log me" marked SIP 531 requests and responses if it is allowed as per policy defined in the 532 termination network. The originating SIP intermediary is the first 533 one to be traversed by a SIP request sent by the originating 534 endpoint. Similarly, the terminating SIP intermediary is last 535 intermediary traversed before the terminating endpoint is reached. 536 The originating and terminating SIP intermediaries are designated and 537 explicitly configured by the network administrator to "log me" mark 538 on behalf of endpoints. The intermediaries that are known to be 539 closest to the terminals can be configured to "log me" mark on behalf 540 of terminals that do not support "log me" marking. This scenario 541 suggests the following principles when a SIP intermediary is 542 configured to initiate or handle "log me" marking on behalf of a user 543 agent: 545 o The originating SIP intermediary MUST insert a "log me" marker 546 into the dialog-creating SIP request and subsequent in-dialog SIP 547 requests. 549 o The originating SIP intermediary itself logs signaling. 551 o The terminating SIP intermediary detects that a dialog is of 552 interest to logging by the existence of a "log me" marker in an 553 incoming dialog-creating SIP request. 555 o The terminating SIP intermediary itself logs marked requests and 556 corresponding responses if allowed as per policy. 558 o The terminating SIP intermediary MUST echo a "log me" marker in 559 responses to a SIP request that included a "log me" marker. 561 o If terminating SIP intermediary has detected that a dialog is 562 being "log me" marked, it MUST insert a "log me" marker in any in- 563 dialog SIP requests from the terminating user agent. 565 o The terminating SIP intermediary itself logs any in-dialog SIP 566 requests that it sends if allowed as per policy. 568 o The originating SIP intermediary detects the "log me" marker 569 received in in-dialog requests and echoes the "log me" marker in 570 the corresponding SIP responses. 572 o The originating SIP intermediary logs the SIP responses that it 573 sends in response to "log me" marked in-dialog requests. 575 4.3. B2BUAs 577 B2BUA "log me" behavior is specified based on its different signaling 578 plane roles described in [RFC7092]. 580 A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses 581 from its terminating to the originating side without needing explicit 582 configuration to do so. 584 A dialog on one "side" of the B2BUA may or may not be coupled to a 585 related dialog on the other "side" for "log me" purposes. To allow 586 end-to-end troubleshooting of user problems and regression testing, a 587 signaling-only and SDP-modifying signaling-only B2BUA [RFC7092] 588 SHOULD couple related dialogs for "log me" marking purposes and pass 589 on the received "log me" parameter from the originating side to 590 terminating side and vice versa. For example, a SIP B2BUA handling 591 end-to-end session between an external caller and an agent in a 592 contact center environment can couple the dialog between itself and 593 an agent with the dialog between itself and external caller and pass 594 on the "log me" marking from originating side to terminating side to 595 enable end-to-end logging of specific sessions of interest. 597 For dialogs that are being "log me" marked, all B2BUAs MUST "log me" 598 mark in-dialog SIP requests that they generate on their own, without 599 needing explicit configuration to do so. This rule applies to both 600 the originating and terminating sides of a B2BUA. 602 4.4. "Log me" Marker Processing by SIP Intermediaries 604 4.4.1. Stateless processing 606 Typically, "log me" marking will be done by an originating UA and 607 echoed by a terminating UA. Any SIP intermediary on the signalling 608 path between these UAs MAY be stateless and simply log any SIP 609 request or response that contains a "log me" marker, if configured to 610 do so. 612 4.4.2. Stateful processing 614 It is possible that some or all user agents connected to a SIP 615 network do not support "log me" marking, or that "log me" marking is 616 removed from SIP messages by the originating or terminating network. 617 These scenarios require SIP intermediaries to maintain state to 618 enable "log me" marking: 620 o The originating UA does not support "log me" marking. 622 o The originating network removes "log me" marking from SIP requests 623 and responses before forwarding them from its network edge to 624 external network. 626 o The terminating UA does not support "log me" marking. 628 o The terminating network removes "log me" marking from SIP requests 629 and responses received from its network edge to internal network. 631 The sections below illustrate SIP intermediary behavior in these 632 scenarios using [RFC3665] example call flow "Session Establishment 633 Through Two Proxies". 635 4.4.2.1. "Log Me" marking not supported by Originating UA 637 Alice's user agent does not support "log me" marking and hence Proxy 638 1 which is the SIP intermediary closest to Alice is configured to act 639 on behalf of Alice's user agent to "log me" mark dialogs created by 640 Alice. 642 In Figure 3 below, Proxy 1 in the originating network maintains state 643 of which dialogs are being logged in order to "log me" mark all SIP 644 requests and responses that it receives from Alice's user agent 645 before forwarding them to Proxy 2. 647 [ NETWORK A ] [ NETWORK B ] 648 Alice Proxy 1 Proxy 2 Bob 649 | | | | 650 | INVITE F1 | | | 651 | (no logme) | | | 652 |--------------->| | | 653 | | INVITE F2 | | 654 | | (logme) | | 655 | |--------------->| | 656 | | | | 657 | | | | 658 | 100 F3 | | INVITE F4 | 659 | (logme) | | (logme) | 660 |<---------------| 100 F5 |--------------->| 661 | | (logme) | | 662 | |<---------------| | 663 | | | 180 F6 | 664 | | | (logme) | 665 | | 180 F7 |<---------------| 666 | | (logme) | | 667 | 180 F8 |<---------------| | 668 | (logme) | | | 669 |<---------------| | 200 F9 | 670 | | | (logme) | 671 | | 200 F10 |<---------------| 672 | | (logme) | | 673 | 200 F11 |<---------------| | 674 | (logme) | | | 675 |<---------------| | | 676 | ACK F12 | | | 677 | (no logme) | | | 678 |--------------->| | | 679 | | | | 680 | | ACK F13 | | 681 | | (logme) | | 682 | |--------------->| | 683 | | | | 684 | | | ACK F14 | 685 | | | (logme) | 686 | | |--------------->| 687 | Both Way RTP Media | 688 |<================================================>| 689 | | | BYE F15 | 690 | | | (logme) | 691 | | BYE F16 |<---------------| 692 | | (logme) | | 693 | BYE F17 |<---------------| | 694 | (logme) | | | 695 |<---------------| | | 696 | 200 F18 | | | 697 | (no logme) | | | 698 |--------------->| | | 699 | | 200 F19 | | 700 | | (logme) | | 701 | |--------------->| | 702 | | | | 703 | | | 200 F20 | 704 | | | (logme) | 705 | | |--------------->| 706 | | | | 708 Figure 3: Case 1: The originating UA does not support "log me" 709 marking 711 F1 - Alice's UA does not insert a "log me" marker in the dialog- 712 creating INVITE request F1. Nevertheless, Proxy 1 is configured to 713 initiate logging on behalf of Alice. Proxy 1 logs INVITE request F1 714 and maintains state that this dialog is being logged. 716 F2 - Proxy 1 inserts a "log me" marker in INVITE request F2 before 717 forwarding it to Proxy 2 and also logs this request. 719 F3 - Proxy 1 inserts a "log me" marker in 100 response F3 before 720 forwarding it to Alice's UA since this is a response sent on a dialog 721 that is being "log me" marked and also logs this response. 723 F4 - Bob's UA detects the "log me" marker and logs the INVITE request 724 F4 if allowed as per policy. 726 F6 - Bob's UA echoes the "log me" marker in INVITE request F4 into 727 180 response F6. It logs this response if allowed as per policy. 729 F7 and F8 - Proxy 1 logs the received the "180" response F7 and 730 passes the "log me" marker to Alice's UA in F8. 732 F12 - Proxy 1 receives ACK with with no "log me" marker. It doesn't 733 consider this as an error since it is configured to "log me" mark on 734 behalf of Bob's UA. 736 F13 - Proxy 1 inserts a "log me" marker in ACK request F13 before 737 forwarding it to Proxy 2 and also logs this request. 739 F15 - Bob's UA inserts a "log me" marker in the in-dialog BYE request 740 and this "log me" marker is carried back to Alice's UA in F16 and 741 F17. Bob's UA logs this request if allowed as per policy. 743 F18 - Alice's UA does not echo the "log me" marker from BYE request 744 F17 into 200 response F18. 746 F19 - Proxy 1 inserts a "log me" marker in 200 response F19 before 747 forwarding it to Proxy 2 and also logs this response. 749 4.4.2.1.1. Missing "Log me" Marker Non-Error Cases 751 The following figure illustrates a non-error case. 753 Figure 4 shows Proxy 2 receiving a response with no "log me" marker 754 that is not an error case. Proxy 2 is configured by network B to 755 perform "log me" marking on behalf of Bob's UA, which does not 756 support "log me" marking. Proxy 2 does not therefore expect 757 responses from Bob to include a "log me" marker. 759 [ NETWORK A ] [ NETWORK B ] 760 Alice Proxy 1 Proxy 2 Bob 761 | | | | 762 | INVITE F1 | | | 763 | (log me) | | | 764 |--------------->| | | 765 | | INVITE F2 | | 766 | | (log me) | | 767 | |--------------->| | 768 | | | | 769 | | | | 770 | 100 F3 | | | 771 | (log me) | | | 772 |<---------------| | | 773 | | | INVITE F4 | 774 | | | (log me) | 775 | | 100 F5 |--------------->| 776 | | (log me) | | 777 | |<---------------| | 778 | | | 180 F6 | 779 | | | (no log me) | 780 | | |<---------------| 781 | | 180 F7 | | 782 | | (log me) | | 783 | |<---------------| | 784 | | | | 786 Figure 4: Non-error case: missing "log me" marker 788 F2 - Proxy 2 detects the "log me" marker and maintains state that 789 this dialog is to be logged. Proxy 2 inserts "log me" markers on 790 behalf of Bob's user agent such as in F7. 792 F6 - Proxy 2 detects that the "log me" marker is missing from the 793 response but considers "log me" marking to be ongoing as a marker was 794 not expected. 796 F7 - Proxy 2 continues to "log me" mark requests and responses on 797 behalf of Bob's user agent. 799 4.4.2.2. "Log Me" marking removed by Originating Network 801 If network A in Figure 5 below is performing testing independently of 802 network B then network A removes "log me" marking from SIP requests 803 and responses forwarded to network B to prevent triggering unintended 804 logging in network B. Proxy 1 removes "log me" marking from requests 805 and responses that it forwards to Proxy 2 and maintains state of 806 which dialogs are being "log me" marked in order to "log me" mark 807 requests and responses that it forwards from Proxy 2 to Alice's user 808 agent. For troubleshooting purposes, Proxy 1 MAY also log the 809 requests and responses sent to or received from Proxy 2 even though 810 it removed "log me" marker prior to forwarding the messages to Proxy 811 2. 813 [ NETWORK A ] [ NETWORK B ] 814 Alice Proxy 1 Proxy 2 Bob 815 | | | | 816 | INVITE F1 | | | 817 | (logme) | | | 818 |--------------->| | | 819 | | INVITE F2 | | 820 | | (no logme) | | 821 | |--------------->| | 822 | | | | 823 | | | | 824 | 100 F3 | | | 825 | (logme) | | INVITE F4 | 826 | | | (no logme) | 827 |<---------------| 100 F5 |--------------->| 828 | | (no logme) | | 829 | |<---------------| | 830 | | | 180 F6 | 831 | | | (no logme) | 832 | | 180 F7 |<---------------| 833 | | (no logme) | | 834 | 180 F8 |<---------------| | 835 | (logme) | | | 836 |<---------------| | 200 F9 | 837 | | | (no logme) | 838 | | 200 F10 |<---------------| 839 | | (no logme) | | 840 | 200 F11 |<---------------| | 841 | (logme) | | | 842 |<---------------| | | 843 | ACK F12 | | | 844 | (logme) | | | 845 |--------------->| | | 846 | | | | 847 | | ACK F13 | | 848 | | (no logme) | | 849 | |--------------->| | 850 | | | | 851 | | | ACK F14 | 852 | | | (no logme) | 853 | | |--------------->| 854 | Both Way RTP Media | 855 |<================================================>| 856 | | | BYE F15 | 857 | | | (no logme) | 858 | | BYE F16 |<---------------| 859 | | (no logme) | | 860 | BYE F17 |<---------------| | 861 | (logme) | | | 862 |<---------------| | | 863 | 200 F18 | | | 864 | (logme) | | | 865 |--------------->| | | 866 | | 200 F19 | | 867 | | (no logme) | | 868 | |--------------->| | 869 | | | | 870 | | | 200 F20 | 871 | | | (no logme) | 872 | | |--------------->| 873 | | | | 875 Figure 5: Case 2: The originating network removes "log me" marking 876 from outgoing SIP messages at its network edge. 878 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 879 INVITE request and Proxy 1 therefore maintains state that this dialog 880 is to be logged. 882 F2 - Proxy 1 removes "log me" marking from INVITE request before 883 forwarding it to Proxy 2. Proxy 1 logs INVITE request F2. 885 F3 - Proxy 1 inserts a "log me" marker in 100 response sent to 886 Alice's user agent and logs this response. 888 F8 - Proxy 1 inserts a "log me" marker in 180 response before 889 forwarding it to Alice's user agent and logs this response. The same 890 applies to responses F11, F17. 892 F13 - Proxy 1 removes "log me" marking from ACK request and logs this 893 request before forwarding it to Proxy 2. 895 F19 - Proxy 1 removes "log me" marking from the 200 response of the 896 BYE request and logs this response before forwarding it to Proxy 2. 898 4.4.2.3. "Log Me" marking not supported by Terminating UA 900 In Figure 6 below Bob's UA does not support "log me" marking, so 901 Proxy 2 in the terminating network maintains state to ensure "log me" 902 marking of SIP requests and responses from Bob's UA. 904 [ NETWORK A ] [ NETWORK B ] 905 Alice Proxy 1 Proxy 2 Bob 906 | | | | 907 | INVITE F1 | | | 908 | (log me) | | | 909 |--------------->| | | 910 | | INVITE F2 | | 911 | | (log me) 912 | |--------------->| | 913 | | | | 914 | | | | 915 | 100 F3 | | | 916 | (log me) | | | 917 |<---------------| | | 918 | | | INVITE F4 | 919 | | | (log me) | 920 | | 100 F5 |--------------->| 921 | | (log me) | | 922 | |<---------------| | 923 | | | 180 F6 | 924 | | | (no log me) | 925 | | |<---------------| 926 | | | | 927 | | | | 928 | | 180 F7 | | 929 | | (log me) | | 930 | |<---------------| | 931 | | | | 932 | | | | 933 | 180 F8 | | | 934 | (log me) | | | 935 |<---------------| | 200 F9 | 936 | | | (no log me) | 937 | | 200 F10 |<---------------| 938 | | (log me) | | 939 | 200 F11 |<---------------| | 940 | (log me) | | | 941 |<---------------| | | 942 | ACK F12 | | | 943 | (log me) | | | 944 |--------------->| | | 945 | | ACK F13 | | 946 | | (log me) | | 947 | |--------------->| ACK F14 | 948 | | | (log me) | 949 | | |--------------->| 950 | Both Way RTP Media | 951 |<================================================>| 952 | | | BYE F15 | 953 | | | (no log me) | 954 | | BYE F16 |<---------------| 955 | | (log me) | | 956 | BYE F17 |<---------------| | 957 | (log me) | | | 958 |<---------------| | | 959 | 200 F18 | | | 960 | (log me) | | | 961 |--------------->| 962 | | 200 F19 | | 963 | | (log me) | | 964 | |--------------->| 200 F20 | 965 | | | (log me) | 966 | | |--------------->| 967 | | | | 969 Figure 6: Case 3: The terminating UA does not support "log me" 970 marking. 972 F1 - Alice's UA inserts a "log me" marker in the the dialog-creating 973 INVITE request F1. 975 F2 - INVITE F2 is "log me" marked and Proxy 2 therefore maintains 976 state that this dialog is to be logged. Proxy 2 logs the request and 977 responses of this dialog if allowed per policy. 979 F5 - Proxy 2 inserts a "log me" marker in the 100 response it sends 980 to Proxy 1. 982 F6 - Bob's UA does not support "log me" marking, therefore the 180 983 response to the INVITE request doesn't have a "log me" marker. 985 F7 - Proxy 2 inserts a "log me" marker in the 180 response on behalf 986 of Bob's UA before forwarding it. The same applies to response F10 987 and the BYE request in F16. 989 4.4.2.4. "Log Me" marking removed by Supporting Terminating Network 991 In Figure 7 below Proxy 2 removes "log me" marking from all SIP 992 requests and responses entering network B. However, Proxy 2 supports 993 maintains the marking state of the dialog and "log me" marks requests 994 and responses that it sends towards Proxy 1. For troubleshooting 995 purposes, Proxy 2 MAY also log the requests and responses received 996 from or sent to Bob even though it removed "log me" marker prior to 997 forwarding the messages to Bob. 999 [ NETWORK A ] [ NETWORK B ] 1000 Alice Proxy 1 Proxy 2 Bob 1001 | | | | 1002 | INVITE F1 | | | 1003 | (log me) | | | 1004 |--------------->| | | 1005 | | INVITE F2 | | 1006 | | (log me) | | 1007 | |--------------->| | 1008 | | | | 1009 | | | | 1010 | 100 F3 | | | 1011 | (log me) | | | 1012 |<---------------| | | 1013 | | | INVITE F4 | 1014 | | | (no log me) | 1015 | | 100 F5 |--------------->| 1016 | | (log me) | | 1017 | |<---------------| | 1018 | | | 180 F6 | 1019 | | | (no log me) | 1020 | | |<---------------| 1021 | | 180 F7 | | 1022 | | (log me) | | 1023 | |<---------------| | 1024 | | | | 1025 | | | | 1026 | 180 F8 | | | 1027 | (log me) | | | 1028 |<---------------| | 200 F9 | 1029 | | | (no log me) | 1030 | | 200 F10 |<---------------| 1031 | | (log me) | | 1032 | 200 F11 |<---------------| | 1033 | (log me) | | | 1034 |<---------------| | | 1035 | ACK F12 | | | 1036 | (log me) | | | 1037 |--------------->| | | 1038 | | ACK F13 | | 1039 | | (log me) | | 1040 | |--------------->| ACK F14 | 1041 | | | (no log me) | 1042 | | |--------------->| 1043 | Both Way RTP Media | 1044 |<================================================>| 1045 | | | BYE F15 | 1046 | | | (no log me) | 1047 | | BYE F16 |<---------------| 1048 | | (log me) | | 1049 | BYE F17 |<---------------| | 1050 | (log me) | | | 1051 |<---------------| | | 1052 | 200 F18 | | | 1053 | (log me) | | | 1054 |--------------->| | | 1055 | | 200 F19 | | 1056 | | (log me) | | 1057 | |--------------->| 200 F20 | 1058 | | | (no log me) | 1059 | | |--------------->| 1060 | | | | 1062 Figure 7: Case 2: The terminating network removes "log me" marking 1063 from incoming SIP messages at its network edge. 1065 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1066 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 1067 request and maintains state that this dialog is to be logged. 1069 F2 - Proxy 2 removes "log me" marker in the INVITE request F2 before 1070 forwarding it as F7. 1072 F6 - Proxy 2 inserts a "log me" marker in 180 response to the INVITE 1073 request and logs the request before forwarding it as F7. The same 1074 applies to response F9 and the BYE request in F15. 1076 4.4.2.5. "Log Me" marking removed by Non-Supporting Terminating Network 1078 In Figure 7 below Proxy 2 removes "log me" marking from all SIP 1079 requests and responses entering network B and Proxy 2 does not 1080 support "log me" marking. Proxy 2 does not log requests and 1081 responses in the dialog. Proxy 1 maintains the marking state of the 1082 dialog. When Proxy 1 observes that requests and responses received 1083 from Proxy 2 are not marked it adds the marking. 1085 For troubleshooting purposes, Proxy 1 MAY also log the requests and 1086 responses received from or sent to Proxy 2 even though Proxy 2 didn't 1087 add "log me" to messages sent to Proxy 1. 1089 [ NETWORK A ] [ NETWORK B ] 1090 Alice Proxy 1 Proxy 2 Bob 1091 | | | | 1092 | INVITE F1 | | | 1093 | (log me) | | | 1094 |--------------->| | | 1095 | | INVITE F2 | | 1096 | | (log me) | | 1097 | |--------------->| | 1098 | | | | 1099 | | | | 1100 | 100 F3 | | | 1101 | (log me) | | | 1102 |<---------------| | | 1103 | | | INVITE F4 | 1104 | | | (no log me) | 1105 | | 100 F5 |--------------->| 1106 | | (no log me) | | 1107 | |<---------------| | 1108 | | | 180 F6 | 1109 | | | (no log me) | 1110 | | |<---------------| 1111 | | 180 F7 | | 1112 | | (no log me) | | 1113 | |<---------------| | 1114 | | | | 1115 | | | | 1116 | 180 F8 | | | 1117 | (log me) | | | 1118 |<---------------| | 200 F9 | 1119 | | | (no log me) | 1120 | | 200 F10 |<---------------| 1121 | | (no log me) | | 1122 | 200 F11 |<---------------| | 1123 | (log me) | | | 1124 |<---------------| | | 1125 | ACK F12 | | | 1126 | (log me) | | | 1127 |--------------->| | | 1128 | | ACK F13 | | 1129 | | (log me) | | 1130 | |--------------->| ACK F14 | 1131 | | | (no log me) | 1132 | | |--------------->| 1133 | Both Way RTP Media | 1134 |<================================================>| 1135 | | | BYE F15 | 1136 | | | (no log me) | 1137 | | BYE F16 |<---------------| 1138 | | (no log me) | | 1139 | BYE F17 |<---------------| | 1140 | (log me) | | | 1141 |<---------------| | | 1142 | 200 F18 | | | 1143 | (log me) | | | 1144 |--------------->| | | 1145 | | 200 F19 | | 1146 | | (log me) | | 1147 | |--------------->| 200 F20 | 1148 | | | (no log me) | 1149 | | |--------------->| 1150 | | | | 1152 Figure 8: Case 2: The terminating network removes "log me" marking 1153 from incoming SIP messages at its network edge. 1155 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1156 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 1157 request and maintains state that this dialog is to be logged. 1159 F2 - Proxy 2 removes "log me" marker in the INVITE request F2 before 1160 forwarding it as F7. 1162 F7 - Proxy 1 inserts a "log me" marker in 180 response of the INVITE 1163 request before forwarding it as F8. The same applies to response F10 1164 and the BYE request in F16. 1166 5. Error Handling 1168 5.1. Missing "Log me" Marker in Dialog Being Logged 1170 Since "log me" marking is per dialog, if a dialog is being marked and 1171 marking is missing then this is an error. 1173 However, detecting such errors does not as simple as checking for 1174 missing markers because of cases such as non-supporting terminals 1175 where it is normal that marking is not done. 1177 Detecting errors must be evaluated separately for each neighbor. It 1178 is an error if a particular neighbor has previously sent logme in the 1179 dialog and then stops, independently of what has been happening with 1180 other neighbors. 1182 User agents and proxies that are stateless with respect to "log me" 1183 marking are not able detect such errors. User agents and proxies 1184 that are stateful with respect to "log me" marking are able to detect 1185 that a marker is missing from a dialog that has previously been "log 1186 me" marked. 1188 If a missing marker error is detected, then the user agent or proxy 1189 SHOULD consider "log me" marking to have ended and MUST NOT mark the 1190 forwarded request or response to the unmarked request, responses to 1191 subsequent requests in the dialog, or in-dialog requests sent from 1192 the terminating side. 1194 5.1.1. Missing "Log me" Marker Error Cases 1196 The following figures illustrate error cases. 1198 Figure 9 shows an error detected at Proxy 1. 1200 [ NETWORK A ] [ NETWORK B ] 1201 Alice Proxy 1 Proxy 2 Bob 1202 | | | | 1203 | INVITE F1 | | | 1204 | (log me) | | | 1205 |--------------->| | | 1206 | | | | 1207 | | | | 1208 | 200 F2 | | | 1209 | (log me) | | | 1210 |<---------------| | | 1211 | | | | 1212 | ACK F3 | | | 1213 | (no log me) | | | 1214 |--------------->| | | 1216 Figure 9: Error cases: missing "log me" marker 1218 F1 - Proxy 1 detects the "log me" marker and maintains state that 1219 this dialog is to be logged. 1221 F3 - Proxy 1 detects that the expected "log me" marker is missing, 1222 considers it as an error and stops "log me" marking in subsequent 1223 requests and responses in this dialog. 1225 Figure 10 shows an error detected at Proxy 2 and Bob's user agent. 1227 [ NETWORK A ] [ NETWORK B ] 1228 Alice Proxy 1 Proxy 2 Bob 1229 | INVITE F1 | | | 1230 | (log me) | | | 1231 |--------------->| | | 1232 | | INVITE F2 | | 1233 | | (log me) | | 1234 | |--------------->| | 1235 | | | | 1236 | | | | 1237 | 100 F3 | | | 1238 | (log me) | | | 1239 |<---------------| | | 1240 | | | INVITE F4 | 1241 | | | (log me) | 1242 | | 100 F5 |--------------->| 1243 | | (log me) | | 1244 | |<---------------| | 1245 | | | 180 F6 | 1246 | | | (log me) | 1247 | | |<---------------| 1248 | | 180 F7 | | 1249 | | (log me) | | 1250 | |<---------------| | 1251 | | | | 1252 | | | | 1253 | 180 F8 | | | 1254 | (log me) | | | 1255 |<---------------| | 200 F9 | 1256 | | | (log me) | 1257 | | 200 F10 |<---------------| 1258 | | (log me) | | 1259 | 200 F11 |<---------------| | 1260 | (log me) | | | 1261 |<---------------| | | 1262 | ACK F12 | | | 1263 | (no log me) | | | 1264 |--------------->| | | 1265 | | ACK F13 | | 1266 | | (no log me) | | 1267 | |--------------->| ACK F14 | 1268 | | | (no log me) | 1269 | | |--------------->| 1271 Figure 10: Error cases: missing "log me" marker 1273 F2 - Proxy 2 detects the "log me" marker and maintains state that 1274 this dialog is to be logged. 1276 F4 - Bob's user agent detects the "log me" marker and maintains state 1277 that this dialog is to be logged. 1279 F12 - Proxy 1 detects that the expected "log me" marker is missing, 1280 considers it as an error and stops "log me" marking in subsequent 1281 requests and responses in this dialog. Hence it does not insert a 1282 "log me" marker in F13. 1284 F13 - Proxy 2 detects that the expected "log me" marker is missing, 1285 considers it as an error and stops "log me" marking in subsequent 1286 requests and responses in this dialog. 1288 F14 - Proxy 2 does not insert a "log me" marker because it has 1289 stopped "log me" marking due to an error observed in F13. Bob's UA 1290 detects that the expected "log me" marker is missing, considers it as 1291 an error and stops "log me" marking in subsequent requests and 1292 responses in this dialog. 1294 5.2. "Log Me" Marker Appears Mid-Dialog 1296 "log me" marking that begins mid-dialog is an error case and the 1297 terminating user agent or edge proxy MUST NOT "log me" mark responses 1298 to the marked request, responses to subsequent requests in the 1299 dialog, or in-dialog requests from the terminating side. 1301 6. Security Considerations 1303 6.1. "Log Me" Authorization 1305 An end user or network administrator MUST give permission for a 1306 terminal to perform "log me" marking. The configuration of a SIP 1307 intermediary to perform "log me" marking on behalf of a terminal MUST 1308 be authorized by the network administrator. 1310 Activating a debug mode affects the operation of a terminal, 1311 therefore debugging configuration MUST be supplied by an authorized 1312 party to an authorized terminal through a secure communication 1313 channel. 1315 6.2. "Log Me" Marker Removal 1317 The log me marker is not sensitive information, although it will 1318 sometimes be inserted because a particular device is experiencing 1319 problems. 1321 The presence of a log me marker will cause some SIP entities to log 1322 signaling messages. Therefore, this marker MUST be removed at the 1323 earliest opportunity if it has been incorrectly inserted, such as 1324 appearing mid-dialog in a dialog that was not being logged or outside 1325 the configured start and stop of logging. 1327 If SIP requests and responses are exchanged with an external network 1328 with which there is no agreement to pass "log me" marking, then the 1329 "log me" marking is removed. 1331 6.3. Denial of Service Attacks 1333 Maliciously configuring a large number of terminals to simultaneously 1334 "log me" mark dialogs will cause high processor load on SIP entities 1335 that are logging signalling. Since "log me" marking is for the small 1336 number of dialogs subject to troubleshooting or regression testing, 1337 the number of dialogs that can be simultaneously logged can be 1338 statically limited without adversely affecting the usefulness of "log 1339 me" marking. Also, the SIP intermediary closest to the terminal and 1340 SIP intermediary at network edge (e.g Session Border Controllers) can 1341 be configured to screen-out "log me" markers when troubleshooting or 1342 regression testing is not in progress. 1344 6.4. Privacy 1346 Logging includes all SIP header fields, the SIP privacy mechanisms 1347 defined in [RFC3323] can be used to ensure that logs do not divulge 1348 personal identity information. 1350 6.4.1. Personal Identifiers 1352 "Log me" marking is defined for the SIP Protocol, and SIP has header 1353 fields such as From, Contact, P-Asserted-Identity that can carry 1354 personal identifiers. Different protocol interactions can be 1355 correlated using the Session-ID and Call-ID header fields, but such 1356 correlation is limited to a single end-to-end session. 1358 In order to protect user privacy during logging, privacy settings can 1359 be enabled or requested by the terminal used by the end user. 1360 [RFC3323] suggests two mechanisms: 1362 o By using the value anonymous in the From header field 1364 o By requesting privacy from SIP intermediaries using the Privacy 1365 header 1367 "Log me" marking is typically used for troubleshooting and regression 1368 testing, and in some cases a service provider owned device with a 1369 dummy account can be used instead of a customer device. In such 1370 cases, no personal identifiers are included in the logged signaling 1371 messages. 1373 6.4.2. Data Stored at SIP Intermediaries 1375 SIP endpoints and intermediaries that honor the "log me" request 1376 store all the SIP messages that are exchanged within a given dialog. 1377 SIP messages can contain the personal identifiers listed in 1378 Section 6.4.1 and additionally a user identity, calling party number, 1379 IP address, hostname, and other user and device related items. The 1380 SIP message bodies describe the kind of session being set up by the 1381 identified end user and device. 1383 "Log me" marking does not introduce any additional user or device 1384 data to SIP but might indicate that a specific user is experiencing a 1385 problem. 1387 6.4.3. Data Visible at Network Elements 1389 SIP messages that are logged due to "log me" requests are stored only 1390 by the SIP initiators, intermediaries and recipients. Enablers as 1391 defined in section 3.1 of [RFC6973], such as firewalls and DNS 1392 servers do not log messages due to the "log me" marking. 1394 6.4.4. Preventing Fingerprinting 1396 "Log me" functionality is typically used to troubleshoot a given 1397 problem and hence it can be used as an method to identify users and 1398 devices that are experiencing issues. The best way to prevent 1399 fingerprinting is to enable or request SIP privacy for the logged 1400 dialog. 1402 6.4.5. Retaining Logs 1404 The lifetime of "log me" marking is equivalent to the lifetime of the 1405 dialog that initiated the "log me" request. When "log me" is 1406 extended to related dialogs the lifetime is extended until there is 1407 no more related dialog for the end-to-end session. 1409 "log me" automatically expires at the end of the dialog and there is 1410 no explicit mechanism to turn off logging within a dialog. 1412 The scope of "log me" Marking is limited i.e. an user or the network 1413 administrator has to enable it on a per session basis or for a 1414 specific time period. This minimizes the risk of exposing user data 1415 for an indefinite time. 1417 The retention time period for logged messages is out of scope for 1418 this document and is expected to be configured based on the data 1419 storage policies of service providers and enterprises. 1421 6.4.6. User Control of Logging 1423 Consent to turn on "log me" for a given session MUST be provided by 1424 the end user or by the network administrator. It is handled outside 1425 of the protocol through user interface or application programming 1426 interfaces at the end point, call control elements and network 1427 management systems. 1429 SIP entities across the communication path can be configured to pass 1430 through the "log me" marking but not honor the request i.e. not log 1431 the data based on local policies. 1433 6.4.7. Recommended Defaults 1435 The recommended defaults for "log me" marking are: 1437 o turn on SIP privacy as described in Section 6.4 or use a service 1438 provider owned device with a dummy user identity for test calls 1440 o use the local UUID of Session-ID header at the originating device 1441 as the test case identifier as described in Section 3.3 1443 6.5. Data Protection 1445 A SIP entity that has logged information MUST protect the logs. 1446 Storage of the log files are subject to the security considerations 1447 specified in [RFC6872]. 1449 7. Augmented BNF for the "logme" Parameter 1451 ABNF is described in [RFC5234]. This document introduces a new 1452 "logme"parameter for the Session-ID header field defined in Section 5 1453 of [RFC7989]. 1455 sess-id-param =/ logme-param 1457 logme-param = "logme" 1459 Figure 11: Augmented BNF for the "logme" Parameter 1461 8. IANA Considerations 1463 8.1. Registration of the "logme" Parameter 1465 The following parameter is to be added to the "Header Field 1466 Parameters and Parameter Values" section of the SIP parameter 1467 registry: 1469 +-------------+---------------+-------------------------+-----------+ 1470 | Header | Parameter | Predefined Values | Reference | 1471 | Field | Name | | | 1472 +-------------+---------------+-------------------------+-----------+ 1473 | Session-ID | logme | No (no values are | [RFCXXXX] | 1474 | | | allowed) | | 1475 +-------------+---------------+-------------------------+-----------+ 1477 Table 1 1479 9. Acknowledgments 1481 The authors wish to thank Paul Giralt, Paul Kyzivat, Jorgen Axell, 1482 Christer Holmberg and Vijay Gurbani for their constructive review 1483 comments and guidance while developing this document. 1485 10. References 1487 10.1. Normative References 1489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1490 Requirement Levels", BCP 14, RFC 2119, 1491 DOI 10.17487/RFC2119, March 1997, 1492 . 1494 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1495 A., Peterson, J., Sparks, R., Handley, M., and E. 1496 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1497 DOI 10.17487/RFC3261, June 2002, 1498 . 1500 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1501 H., and O. Festor, "The Common Log Format (CLF) for the 1502 Session Initiation Protocol (SIP): Framework and 1503 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1504 February 2013, . 1506 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1507 Session Initiation Protocol (SIP) Common Log Format 1508 (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, 1509 . 1511 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1512 Kaplan, "Requirements for an End-to-End Session 1513 Identification in IP-Based Multimedia Communication 1514 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1515 . 1517 [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- 1518 to-End Session Identification in IP-Based Multimedia 1519 Communication Networks", RFC 7989, DOI 10.17487/RFC7989, 1520 October 2016, . 1522 10.2. Informative References 1524 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1525 Initiation Protocol (SIP)", RFC 3323, 1526 DOI 10.17487/RFC3323, November 2002, 1527 . 1529 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1530 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1531 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1532 December 2003, . 1534 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1535 Specifications: ABNF", STD 68, RFC 5234, 1536 DOI 10.17487/RFC5234, January 2008, 1537 . 1539 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1540 Initiation Protocol (SIP) Call Control - Transfer", 1541 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1542 . 1544 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1545 Morris, J., Hansen, M., and R. Smith, "Privacy 1546 Considerations for Internet Protocols", RFC 6973, 1547 DOI 10.17487/RFC6973, July 2013, 1548 . 1550 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1551 Initiation Protocol (SIP) Back-to-Back User Agents", 1552 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1553 . 1555 [RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking 1556 SIP Messages to be Logged", RFC 8123, 1557 DOI 10.17487/RFC8123, March 2017, 1558 . 1560 Authors' Addresses 1562 Peter Dawes 1563 Vodafone Group 1564 The Connection 1565 Newbury, Berkshire RG14 2FN 1566 UK 1568 Email: peter.dawes@vodafone.com 1570 Chidambaram Arunachalam 1571 Cisco Systems 1572 7200-12 Kit Creek Road 1573 Research Triangle Park, NC, NC 27709 1574 US 1576 Email: carunach@cisco.com