idnits 2.17.1 draft-ietf-insipid-logme-marking-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 169 has weird spacing: '...ple.com r1.e...' -- The document date (July 17, 2018) is 2103 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 1678, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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: January 18, 2019 Cisco Systems 6 July 17, 2018 8 Marking SIP Messages to be Logged 9 draft-ietf-insipid-logme-marking-12 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. Operators of all networks on the signaling path can agree 25 to carry such marking end-to-end, including the originating and 26 terminating SIP user agents, even if a session originates and 27 terminates in different networks. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 18, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4 66 3.1. Session-ID logme Parameter . . . . . . . . . . . . . . . 4 67 3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 4 68 3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 5 69 3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 5 70 3.4.1. To and From a User Device . . . . . . . . . . . . . . 6 71 3.4.2. To and From an External Network . . . . . . . . . . . 6 72 3.4.3. Across a Non-Supporting SIP Intermediary . . . . . . 6 73 3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 6 74 3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 6 75 3.7. Marking Related Dialogs . . . . . . . . . . . . . . . . . 7 76 3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 12 77 4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Scope of Marking . . . . . . . . . . . . . . . . . . . . 12 79 4.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.3. SIP Intermediaries Acting on Behalf of Endpoints . . . . 14 81 4.4. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.5. "Log me" Marker Processing by SIP Intermediaries . . . . 16 83 4.5.1. Stateless processing . . . . . . . . . . . . . . . . 16 84 4.5.2. Stateful processing . . . . . . . . . . . . . . . . . 16 85 4.5.2.1. "Log Me" marking not supported by Originating UA 17 86 4.5.2.2. "Log Me" marking not supported by Terminating UA 21 87 4.5.2.3. "Log Me" marking removed by Originating Network . 23 88 4.5.2.4. "Log Me" marking removed by Supporting 89 Terminating Network . . . . . . . . . . . . . . . 25 90 4.5.2.5. "Log Me" marking removed by Non-Supporting 91 Terminating Network . . . . . . . . . . . . . . . 27 92 4.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 29 93 5. Error Cases . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 5.1. Missing "Log Me" Marker Error Case . . . . . . . . . . . 29 95 5.2. "Log Me" Marker Appears Mid-Dialog Error Case . . . . . . 33 96 6. Non-Error Cases . . . . . . . . . . . . . . . . . . . . . . . 34 97 6.1. Missing "Log me" Marker Non-Error Case . . . . . . . . . 34 98 6.2. "Log Me" Marker Appears Mid-Dialog Non-Error Case . . . . 36 99 7. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 36 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 101 8.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 36 102 8.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 37 103 8.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 37 104 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37 105 8.4.1. Personal Identifiers . . . . . . . . . . . . . . . . 37 106 8.4.2. Data Stored at SIP Intermediaries . . . . . . . . . . 38 107 8.4.3. Data Visible at Network Elements . . . . . . . . . . 38 108 8.4.4. Preventing Fingerprinting . . . . . . . . . . . . . . 38 109 8.4.5. Retaining Logs . . . . . . . . . . . . . . . . . . . 39 110 8.4.6. User Control of Logging . . . . . . . . . . . . . . . 39 111 8.4.7. Recommended Defaults . . . . . . . . . . . . . . . . 39 112 8.5. Data Protection . . . . . . . . . . . . . . . . . . . . . 39 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 114 9.1. Registration of the "logme" Parameter . . . . . . . . . . 40 115 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 118 11.2. Informative References . . . . . . . . . . . . . . . . . 41 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 121 1. Introduction 123 When users experience problems with setting up sessions using SIP, 124 enterprise or service provider network operators need to identify the 125 root cause by examining the SIP signaling. Also, when network or 126 user agent software or hardware is upgraded, regression testing is 127 needed. Such diagnostics apply to a small proportion of network 128 traffic and can apply end-to-end, even if signaling crosses several 129 networks possibly belonging to several different network operators. 130 It may not be possible to predict the path through those networks in 131 advance, therefore a mechanism is needed to mark a session as being 132 of interest so that SIP entities along the signaling path can provide 133 diagnostic logging. [RFC8123] illustrates this motivating scenario. 134 This document describes a solution that meets the requirements for 135 such "log me" marking of SIP signaling also defined in [RFC8123]. 137 This document defines a new header field parameter "logme" for the 138 "Session-ID" header field [RFC7989]. Implementations of this 139 document MUST implement session identity. 141 2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. Rather than describing interoperability 148 requirements, they are used to describe requirements to be satisfied 149 by the "log me" marking solution. 151 3. "Log Me" Marking Protocol Aspects 153 3.1. Session-ID logme Parameter 155 Logging for diagnostic purposes is most effective when it is applied 156 end-to-end in a communication session. This ability requires a "log 157 me" marker to be passed through SIP intermediaries. The Session-ID 158 header defined in ([RFC7989]) was chosen to carry the "log me" marker 159 as a "logme" parameter since the session identifier is typically 160 passed through SIP B2BUAs (described in [RFC7092]) or other 161 intermediaries, as per the Session-ID requirement REQ3 in 162 ([RFC7206]). The "logme" parameter shown in Figure 1 does not 163 introduce any device-specific or user-specific information and MUST 164 be passed unchanged with the Session-ID header except for the cases 165 specified in Section 3.4.2 where the "log me" marker may be removed 166 at a network boundary. 168 Alice Proxy Registrar 169 u1.example.com p1.example.com r1.example.com 170 | | | 171 |(1) INVITE | | 172 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; 173 | remote=47755a9de7794ba387653f2099600ef2;logme 174 |----------------->| | 175 | | | 177 Figure 1: "Log Me" marking using the "logme" Session-ID header field 178 parameter 180 3.2. Starting and Stopping Logging 182 Marking starts with a dialog-initiating request (described in 183 Section 12.1 of [RFC3261]) and continues for the lifetime of the 184 dialog, and applies to each request and response in that dialog. 186 A user agent or intermediary adds a "log me" marker in an unmarked 187 request or response in two cases: firstly because it is configured to 188 do so, or secondly because it has detected that a dialog is being 189 "log me" marked, causing it to maintain state to ensure that all 190 requests and responses in the dialog are similarly "log me" marked. 191 Once the "log me" marking is started for a dialog, all subsequent 192 requests and responses in this dialog are "log me" marked and marking 193 is stopped when this dialog and its related dialogs end. It is 194 considered an error (see Section 5.2) if "log me" marking is started 195 in a mid-dialog request or response. 197 If a request or response is "log me" marked, then all re- 198 transmissions of the request or response MUST be similarly "log me" 199 marked. Likewise, re-transmissions of a request or response that was 200 not "log me" marked MUST NOT be "log me" marked. 202 For the first case, "log me" marking trigger condition configurations 203 that define whether a user agent or intermediary can initiate "log 204 me" marking for a given dialog are out of scope of this document. As 205 an example of trigger condition configurations, the user agent or 206 intermediary could be configured to add a "log me" marker for all 207 dialogs initiated during a specific time period (e.g., 9:00 am - 208 10:00 am every day), for specific dialogs that have a particular 209 "User-Agent" header value, or for a specific set of called party 210 numbers for which users are experiencing call setup failures. 212 For the second case of a user agent or intermediary detecting that a 213 dialog-initiating request is being "log me" marked, the scope of such 214 marking extends to the lifetime of the dialog. In addition, as 215 discussed in Section 3.7, "log me" marked dialogs that create related 216 dialogs (REFER) may transfer the marking to the related dialogs. In 217 such cases, the entire "session", identified by the Session-ID 218 header, is "log me" marked. 220 3.3. Identifying Test Cases 222 The local Universally Unique Identifier (UUID) portion of Session-ID 223 [RFC7989] in the initial SIP request of a dialog is used as a random 224 test case identifier (described in REQ 5 in [RFC8123]). This 225 provides the ability to collate all logged SIP requests and responses 226 to the initial SIP request in a dialog or standalone transaction. 228 3.4. Passing the Marker 229 3.4.1. To and From a User Device 231 When a user device inserts the "log me" marker, the marker MUST be 232 passed unchanged in the Session-ID header across an edge proxy or a 233 B2BUA adjacent to the user device. 235 3.4.2. To and From an External Network 237 An external network is a peer network connected at a network boundary 238 as defined in [RFC8123]. 240 External networks may be connected directly or via a peering network 241 and such networks often have specific connection agreements. Whether 242 "log me" marking is removed depends upon the policy applied at the 243 network to network interface. Troubleshooting and testing will be 244 easier if peer networks endeavor to make agreements to pass "log me" 245 marking unchanged. However, since a "log me" marker may cause a SIP 246 entity to log the SIP header and body of a request or response, if no 247 agreement exists between peer networks then the "log me" marker MUST 248 be removed at a network boundary. 250 3.4.3. Across a Non-Supporting SIP Intermediary 252 "Log me" marking is most effective if passed end-to-end. However, 253 intermediaries that do not comply with this specification might pass 254 the "log me" marker unchanged or drop it entirely. 256 3.5. Logging Multiple Simultaneous Dialogs 258 An originating or terminating user agent and SIP entities on the 259 signaling path can log multiple SIP dialogs simultaneously. These 260 dialogs are differentiated by their test case identifier (the local 261 UUID of the Session-ID header field at the originating device). 263 3.6. Format of Logged Signaling 265 The entire SIP message (SIP headers and message body) SHOULD be 266 logged since troubleshooting might be difficult if information is 267 missing. Logging SHOULD use common standard formats such as the SIP 268 CLF defined in [RFC6873] and Libpcap. If SIP CLF format is used, the 269 entire message is logged using Vendor-ID = 00000000 and Tag = 02 in 270 the portion of the SIP CLF record (see [RFC6873] 271 section 4.4). Header fields SHOULD be logged in the form in which 272 they appear in the message, they SHOULD NOT be converted between long 273 and compact forms described in [RFC3261] section 7.3.3. 275 3.7. Marking Related Dialogs 277 "Log me" marking is done per-dialog and typically begins at dialog 278 creation and ends when the dialog ends. However, dialogs related to 279 a "log me" marked dialog MAY also be "log me" marked. As described 280 in [RFC7989] section 6, related dialogs can occur when an endpoint 281 receives a 3xx message, a REFER that directs the endpoint to a 282 different peer, or an INVITE request with Replaces that also 283 potentially results in communicating with a new peer. An example is 284 call transfer described in section 6.1 of [RFC5589] and the logged 285 signaling for related dialogs can be correlated using Session-ID 286 values as described in section 10.9 of [RFC7989]. 288 In the example shown in Figure 2, Alice has reported problems making 289 call transfers. Her terminal is configured to log signaling for 290 calls from the network administrator Bob. Bob, who is troubleshooting 291 the problem, arranges to make a call that Alice can attempt to 292 transfer. Bob calls Alice, which creates initial dialog1, and then 293 Alice transfers the call to connect Bob to Carol. Logged signaling 294 is correlated using the test case identifier, which is the local UUID 295 ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of 296 INVITE request F1. Logging by Alice's terminal begins when it 297 receives and echoes the "logme" marker in INVITE F1 and ends when the 298 last request or response in the dialog is sent or received (200 OK F7 299 of dialog1). Also during dialog1, Alice's terminal logs related 300 REFER dialog2 that it initiates and terminates as part of the call 301 transfer. Alice's terminal inserts a "logme" marker in the REFER 302 request and 200 OK responses to NOTIFY requests in dialog2. Both 303 dialog1 and dialog2 have the same test case identifier. 305 Logging by Bob's terminal begins when it sends INVITE F1, which 306 includes the "logme" marker, and ends when dialog3, initiated by Bob, 307 ends. Logging by Carol's terminal begins when it receives the INVITE 308 F5 with the "log me" marker and ends when dialog3 ends. 310 dialog3 is not logged by Alice's terminal, however the test case 311 identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case 312 identifier (local-uuid) in INVITE F5. Also, the test case identifier 313 of dialog2, which is logged by Alice's terminal, can be linked to 314 dialog1 and dialog3 because the remote-uuid component of dialog2 is 315 the test case identifier ab30317f1a784dc48ff824d0d3715d86. 317 F1 - Bob's UA inserts the "logme" parameter in the Session-ID header 318 of the INVITE request that creates dialog1. 320 F3 - Alice's UA inserts the "logme" parameter in the Session-ID 321 header of the REFER request that creates dialog2 which is related to 322 dialog1. 324 F5 - Bob's UA inserts the "logme" parameter in the Session-ID header 325 of the INVITE request that creates dialog3 which is related to 326 dialog1. 328 Alice Bob Carol 329 Transferor Transferee Transfer 330 | | Target 331 | INVITE F1 | | 332 dialog1 |<-------------------| | 333 | 200 OK F2 | | 334 dialog1 |------------------->| | 335 | ACK | | 336 dialog1 |<-------------------| | 337 | INVITE (hold) | | 338 dialog1 |------------------->| | 339 | 200 OK | | 340 dialog1 |<-------------------| | 341 | ACK | | 342 dialog1 |------------------->| | 343 | REFER F3 (Target-Dialog:1) | 344 dialog2 |------------------->| | 345 | 202 Accepted | | 346 dialog2 |<-------------------| | 347 | NOTIFY (100 Trying) F4 | 348 dialog2 |<-------------------| | 349 | 200 OK | | 350 dialog2 |------------------->| | 351 | | INVITE F5 | 352 dialog3 | |------------------->| 353 | | 200 OK | 354 dialog3 | |<-------------------| 355 | | ACK | 356 dialog3 | |------------------->| 357 | NOTIFY (200 OK) F6| | 358 dialog2 |<-------------------| | 359 | 200 OK | | 360 dialog2 |------------------->| | 361 | BYE | | 362 dialog1 |------------------->| | 363 | 200 OK F7 | | 364 dialog1 |<-------------------| | 365 | | BYE | 366 dialog3 | |<-------------------| 367 | | 200 OK | 368 dialog3 | |------------------->| 370 Figure 2: "Log me" marking related dialogs in call transfer 372 F1 INVITE Transferee -> Transferor 373 INVITE sips:transferor@atlanta.example.com SIP/2.0 374 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 375 Max-Forwards: 70 376 To: 377 From: ;tag=7553452 378 Call-ID: 090459243588173445 379 Session-ID: ab30317f1a784dc48ff824d0d3715d86 380 ;remote=00000000000000000000000000000000;logme 381 CSeq: 29887 INVITE 382 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 383 Supported: replaces, gruu, tdialog 384 Contact: 385 Content-Type: application/sdp 386 Content-Length: ... 388 F2 200 OK Transferor -> Transferee 390 SIP/2.0 200 OK 391 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 392 To: ;tag=31kdl4i3k 393 From: ;tag=7553452 394 Call-ID: 090459243588173445 395 Session-ID: 47755a9de7794ba387653f2099600ef2 396 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 397 CSeq: 29887 INVITE 398 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 399 Supported: replaces, gruu, tdialog 400 Contact: 401 Content-Type: application/sdp 402 Content-Length: ... 404 F3 REFER Transferor -> Transferee 406 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 407 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 408 Max-Forwards: 70 409 To: 410 From: ;tag=1928301774 411 Call-ID: a84b4c76e66710 412 Session-ID: 47755a9de7794ba387653f2099600ef2 413 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 414 CSeq: 314159 REFER 415 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 416 Supported: gruu, replaces, tdialog 417 Require: tdialog 418 Refer-To: 419 Target-Dialog: 090459243588173445;local-tag=7553452 420 ;remote-tag=31kdl4i3k 421 Contact: 422 Content-Length: 0 424 F4 NOTIFY Transferee -> Transferor 426 NOTIFY sips:4889445d8kjtk3@atlanta.example.com 427 ;gr=723jd2d SIP/2.0 428 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 429 Max-Forwards: 70 430 To: ;tag=1928301774 431 From: 432 ;tag=a6c85cf 433 Call-ID: a84b4c76e66710 434 Session-ID: ab30317f1a784dc48ff824d0d3715d86 435 ;remote=47755a9de7794ba387653f2099600ef2;logme 436 CSeq: 73 NOTIFY 437 Contact: 438 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 439 Supported: replaces, tdialog 440 Event: refer 441 Subscription-State: active;expires=60 442 Content-Type: message/sipfrag 443 Content-Length: ... 445 F5 INVITE Transferee -> Transfer Target 447 INVITE sips:transfertarget@chicago.example.com SIP/2.0 448 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234 449 Max-Forwards: 70 450 To: 451 From: ;tag=j3kso3iqhq 452 Call-ID: 90422f3sd23m4g56832034 453 Session-ID: ab30317f1a784dc48ff824d0d3715d86 454 ;remote=00000000000000000000000000000000;logme 455 CSeq: 521 REFER 456 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 457 Supported: replaces, gruu, tdialog 458 Contact: 459 Content-Type: application/sdp 460 Content-Length: ... 462 F6 NOTIFY Transferee -> Transferor 463 NOTIFY sips:4889445d8kjtk3@atlanta.example.com 464 ;gr=723jd2d SIP/2.0 465 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432 466 Max-Forwards: 70 467 To: ;tag=1928301774 468 From: 469 ;tag=a6c85cf 470 Call-ID: a84b4c76e66710 471 Session-ID: ab30317f1a784dc48ff824d0d3715d86 472 ;remote=47755a9de7794ba387653f2099600ef2;logme 473 CSeq: 74 NOTIFY 474 Contact: 475 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 476 Supported: replaces, tdialog 477 Event: refer 478 Subscription-State: terminated;reason=noresource 479 Content-Type: message/sipfrag 480 Content-Length: ... 482 3.8. Forked Requests 484 A SIP intermediary MUST copy the "log me" marker into forked requests 485 (see sections 4, 16.6 in [RFC3261]). 487 4. SIP Entity Behavior 489 4.1. Scope of Marking 491 "Log me" marking is intended to be limited, in time period and number 492 of dialogs marked, to the minimum needed to troubleshoot a particular 493 problem or perform a particular test. 495 o SIP entities MUST be configured to "log me" mark only dialogs 496 needed for the current testing purpose e.g. troubleshooting or 497 regression testing. The mechanisms in this section ensure that 498 "log me" marking begins at dialog creation and, other than cases 499 of marking related dialogs or premature ending, ends when the 500 dialog being "log me" marked ends. 502 o The mechanisms in this section limit initiation of "log me" 503 marking only in dialog creation requests (e.g. SIP INVITE) sent 504 by an originating endpoint or an intermediary that marks on behalf 505 of the originating endpoint. The final terminating endpoint or an 506 intermediary that marks on behalf of the terminating endpoint 507 detects an incoming "log me" marker and takes action as defined in 508 Section 4.2 and Section 4.3. 510 Note that the error cases described in sections 5.1 and 5.2 cause SIP 511 entities to stop "log me" marking, and the requirements in Section 8 512 also place requirements on SIP entities, including allowing SIP 513 entities to not log signaling based on local policies (see 514 Section 8.4.6). 516 4.2. Endpoints 518 A common scenario is to have both originating and terminating 519 endpoints support "log me" marking specification with the originating 520 endpoint configured to initiate "log me" marking. In this simplest 521 use case, the originating user agent inserts a "log me" marker in the 522 dialog-creating SIP request and all subsequent SIP requests within 523 that dialog. The "log me" marker is passed through the SIP 524 intermediaries and arrives at the terminating user agent which echoes 525 the "log me" marker in the corresponding responses. If the 526 terminating user agent sends an in-dialog request on a dialog that is 527 being "log me" marked, it inserts a "log me" marker and the 528 originating user agent echoes the "log me" marker in responses. The 529 terminating user agent logs the "log me" marked SIP requests and 530 responses if it is allowed as per policy defined in the terminating 531 network. This basic use case suggests the following rules for 532 originating and terminating user agents. 534 For originating user agents: 536 o The originating user agent configured for "log me" marking MUST 537 insert a "log me" marker into the dialog-creating SIP request and 538 subsequent in-dialog SIP requests. 540 o The originating user agent itself logs marked signaling. 542 o The originating user agent echoes, in responses, the "log me" 543 marker received in in-dialog requests from the terminating side. 545 o The originating user agent logs the SIP responses that it sends in 546 response to received "log me" marked in-dialog requests. 548 o The originating user agent MAY also apply these rules to any 549 subsequent related SIP dialogs as described in Section 3.7. 551 For terminating user agents: 553 o The terminating user agent detects that a dialog is of interest to 554 logging by the existence of a "log me" marker in an incoming 555 dialog-creating SIP request. 557 o The terminating user agent itself logs marked requests and 558 corresponding marked responses if allowed as per policy. 560 o The terminating user agent MUST echo a "log me" marker in 561 responses to a SIP request that included a "log me" marker. 563 o If the terminating user agent has detected that a dialog is being 564 "log me" marked, it MUST insert a "log me" marker in any in-dialog 565 SIP requests that it sends. 567 o The terminating user agent itself logs any in-dialog SIP requests 568 that it sends if allowed as per policy. 570 o The terminating user agent MAY also apply these rules to any 571 subsequent related SIP dialogs as described in Section 3.7. 573 4.3. SIP Intermediaries Acting on Behalf of Endpoints 575 A network operator may know that some of the user agents connected to 576 the network do not support "log me" marking. Subject to the 577 authorizations in Section 8.1, a SIP intermediary close to the user 578 agent (e.g. edge proxy, B2BUA) on the originating and terminating 579 sides inserts the "log me" marker instead in order to test sessions 580 involving such user agents. 582 The originating and terminating SIP intermediaries are not identified 583 by protocol means but are designated and explicitly configured by the 584 network administrator to "log me" mark on behalf of endpoints. The 585 intermediaries that are known to be closest to the terminals can be 586 configured to "log me" mark on behalf of terminals that do not 587 support "log me" marking. The originating SIP intermediary is the 588 first one to be traversed by a SIP request sent by the originating 589 endpoint. Similarly, the terminating SIP intermediary is last 590 intermediary traversed before the terminating endpoint is reached. 592 The SIP intermediary at the originating side is configured to insert 593 the "log me" marker on behalf of the originating endpoint. If the 594 terminating user agent does not echo the "log me" marker in responses 595 to a marked request then the the SIP intermediary closest to the 596 terminating user agent inserts a "log me" marker in responses to the 597 request. Likewise, if the terminating user agent sends an in-dialog 598 request, the SIP intermediary at the terminating side inserts a "log 599 me" marker and the SIP intermediary at the originating side echoes 600 the "log me" marker in responses to that request. The SIP 601 intermediaries at the originating and terminating sides log the "log 602 me" marked SIP requests and responses if it is allowed as per policy 603 defined in the originating and terminating networks. This scenario 604 suggests the following rules when a SIP intermediary is configured to 605 initiate or handle "log me" marking on behalf of a user agent. 607 For the originating SIP intermediary: 609 o The originating SIP intermediary configured for "log me" marking 610 MUST insert a "log me" marker into the dialog-creating SIP request 611 and subsequent in-dialog SIP requests. 613 o The originating SIP intermediary itself logs marked signaling. 615 o The originating SIP intermediary detects the "log me" marker 616 received in in-dialog requests and echoes the "log me" marker in 617 the corresponding SIP responses. 619 o The originating SIP intermediary logs the SIP responses that it 620 sends in response to "log me" marked in-dialog requests. 622 o The originating SIP intermediary MAY also apply these rules to any 623 subsequent related SIP dialogs as described in Section 3.7). 625 For the terminating SIP intermediary: 627 o The terminating SIP intermediary detects that a dialog is of 628 interest to logging by the existence of a "log me" marker in an 629 incoming dialog-creating SIP request. 631 o The terminating SIP intermediary itself logs marked requests and 632 corresponding responses if allowed as per policy. 634 o The terminating SIP intermediary MUST echo a "log me" marker in 635 responses to a SIP request that included a "log me" marker. 637 o If terminating SIP intermediary has detected that a dialog is 638 being "log me" marked, it MUST insert a "log me" marker in any in- 639 dialog SIP requests from the terminating user agent. 641 o The terminating SIP intermediary itself logs any in-dialog SIP 642 requests that it sends if allowed as per policy. 644 o The terminating SIP intermediary MAY also apply these rules to any 645 subsequent related SIP dialogs as described in Section 3.7. 647 4.4. B2BUAs 649 B2BUA "log me" behavior is specified based on its different signaling 650 plane roles described in [RFC7092]. 652 A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses 653 from its terminating to the originating side without needing explicit 654 configuration to do so. 656 A dialog on one "side" of the B2BUA may or may not be coupled to a 657 related dialog on the other "side" for "log me" purposes. To allow 658 end-to-end troubleshooting of user problems and regression testing, a 659 signaling-only and SDP-modifying signaling-only B2BUA [RFC7092] 660 SHOULD couple related dialogs for "log me" marking purposes and pass 661 on the received "log me" parameter from the originating side to 662 terminating side and vice versa. For example, a SIP B2BUA handling 663 an end-to-end session between an external caller and an agent in a 664 contact center environment can couple the dialog between itself and 665 an agent with the dialog between itself and external caller and pass 666 on the "log me" marking from originating side to terminating side to 667 enable end-to-end logging of specific sessions of interest. 669 For dialogs that are being "log me" marked, all B2BUAs MUST "log me" 670 mark in-dialog SIP requests that they generate on their own, without 671 needing explicit configuration to do so. This rule applies to both 672 the originating and terminating sides of a B2BUA. 674 4.5. "Log me" Marker Processing by SIP Intermediaries 676 4.5.1. Stateless processing 678 Typically, "log me" marking will be done by an originating UA and 679 echoed by a terminating UA. SIP intermediaries on the signaling path 680 between these UAs that do not perform the tasks described in 681 Section 4.2, Section 4.3, or Section 4.4 MUST simply log any request 682 or response that contains a "log me" marker in a stateless manner, if 683 it is allowed per local policy. 685 4.5.2. Stateful processing 687 The originating and terminating SIP intermediaries that "log me" mark 688 on behalf of endpoints and SIP intermediaries that remove "log me" 689 marking at the network boundary must maintain state to enable "log 690 me" marking. Applicable scenarios are as follows. 692 o The originating UA does not support "log me" marking. This 693 scenario was described in Section 4.3 and requires support by the 694 originating SIP intermediary. "Log me" marker processing is 695 illustrated in Section 4.5.2.1. 697 o The terminating UA does not support "log me" marking. This 698 scenario was described in Section 4.3 and requires support by the 699 terminating SIP intermediary. "Log me" marker processing is 700 illustrated in Section 4.5.2.2. 702 o The originating network ensures that it does not pass marking 703 outside its boundaries in order to not impact any external 704 networks. The originating network removes "log me" marking from 705 SIP requests and responses before forwarding them from its network 706 boundary to external networks but adds marking back to any 707 incoming SIP requests and responses belonging to any "log me" 708 marked dialog. This scenario requires support by the SIP 709 intermediary at the originating network boundary and "log me" 710 marker processing is illustrated in Section 4.5.2.3. 712 o The terminating network ensures that it does not allow "log me" 713 marking from external networks to pass through its boundary to its 714 internal entities. The terminating network removes "log me" 715 marking from SIP requests and responses before forwarding them 716 internally but adds marking back to any outgoing SIP requests and 717 responses belonging to any "log me" marked dialog. This scenario 718 requires support by the SIP intermediary at the terminating 719 network boundary and "log me" marker processing is illustrated in 720 Section 4.5.2.4. 722 o The terminating network does not support "log me" marking and does 723 not echo marking that it receives. The originating network adds 724 marking back to any incoming SIP requests and responses belonging 725 to the "log me" marked dialog. This scenario requires support by 726 the SIP intermediary at the originating network boundary and "log 727 me" marker processing is illustrated in Section 4.5.2.5. 729 SIP intermediary behavior in these scenarios is illustrated using 730 [RFC3665] example call flow "Session Establishment Through Two 731 Proxies". 733 4.5.2.1. "Log Me" marking not supported by Originating UA 735 Alice's user agent does not support "log me" marking and hence Proxy 736 1, which is the SIP intermediary closest to Alice, is configured to 737 act on behalf of Alice's user agent to "log me" mark dialogs created 738 by Alice. 740 In Figure 3 below, Proxy 1 in the originating network maintains state 741 of which dialogs are being logged in order to "log me" mark all SIP 742 requests and responses that it receives from Alice's user agent 743 before forwarding them to Proxy 2. 745 [ NETWORK A ] [ NETWORK B ] 746 Alice Proxy 1 Proxy 2 Bob 747 | | | | 748 | INVITE F1 | | | 749 | (no logme) | | | 750 |--------------->| | | 751 | | INVITE F2 | | 752 | | (logme) | | 753 | |--------------->| | 754 | | | | 755 | | | | 756 | 100 F3 | | INVITE F4 | 757 | (logme) | | (logme) | 758 |<---------------| 100 F5 |--------------->| 759 | | (logme) | | 760 | |<---------------| | 761 | | | 180 F6 | 762 | | | (logme) | 763 | | 180 F7 |<---------------| 764 | | (logme) | | 765 | 180 F8 |<---------------| | 766 | (logme) | | | 767 |<---------------| | 200 F9 | 768 | | | (logme) | 769 | | 200 F10 |<---------------| 770 | | (logme) | | 771 | 200 F11 |<---------------| | 772 | (logme) | | | 773 |<---------------| | | 774 | ACK F12 | | | 775 | (no logme) | | | 776 |--------------->| | | 777 | | | | 778 | | ACK F13 | | 779 | | (logme) | | 780 | |--------------->| | 781 | | | | 782 | | | ACK F14 | 783 | | | (logme) | 784 | | |--------------->| 785 | Both Way RTP Media | 786 |<================================================>| 787 | | | BYE F15 | 788 | | | (logme) | 789 | | BYE F16 |<---------------| 790 | | (logme) | | 791 | BYE F17 |<---------------| | 792 | (logme) | | | 793 |<---------------| | | 794 | 200 F18 | | | 795 | (no logme) | | | 796 |--------------->| | | 797 | | 200 F19 | | 798 | | (logme) | | 799 | |--------------->| | 800 | | | | 801 | | | 200 F20 | 802 | | | (logme) | 803 | | |--------------->| 804 | | | | 806 Figure 3: The originating UA does not support "log me" marking 808 F1 - Alice's UA does not insert a "log me" marker in the dialog- 809 creating INVITE request F1. Nevertheless, Proxy 1 is configured to 810 initiate logging on behalf of Alice. Proxy 1 logs INVITE request F1 811 and maintains state that this dialog is being logged. 813 F2 - Proxy 1 inserts a "log me" marker in INVITE request F2 before 814 forwarding it to Proxy 2 and also logs this request. 816 F3 - Proxy 1 inserts a "log me" marker in 100 response F3 before 817 forwarding it to Alice's UA since this is a response sent on a dialog 818 that is being "log me" marked and also logs this response. 820 F4 - Bob's UA detects the "log me" marker and logs the INVITE request 821 F4 if allowed as per policy. 823 F6 - Bob's UA echoes the "log me" marker in INVITE request F4 into 824 180 response F6. It logs this response if allowed as per policy. 826 F7 and F8 - Proxy 1 logs the received the "180" response F7 and 827 passes the "log me" marker to Alice's UA in F8. 829 F12 - Proxy 1 receives ACK with no "log me" marker. It doesn't 830 consider this as an error since it is configured to "log me" mark on 831 behalf of Alice's UA. 833 F13 - Proxy 1 inserts a "log me" marker in ACK request F13 before 834 forwarding it to Proxy 2 and also logs this request. 836 F15 - Bob's UA inserts a "log me" marker in the in-dialog BYE request 837 and this "log me" marker is carried back to Alice's UA in F16 and 838 F17. Bob's UA logs this request if allowed as per policy. 840 F18 - Alice's UA does not echo the "log me" marker from BYE request 841 F17 into 200 response F18. 843 F19 - Proxy 1 inserts a "log me" marker in 200 response F19 before 844 forwarding it to Proxy 2 and also logs this response. 846 4.5.2.2. "Log Me" marking not supported by Terminating UA 848 In Figure 4 below Bob's UA does not support "log me" marking, so 849 Proxy 2 in the terminating network maintains state to ensure "log me" 850 marking of SIP requests and responses from Bob's UA. 852 [ NETWORK A ] [ NETWORK B ] 853 Alice Proxy 1 Proxy 2 Bob 854 | | | | 855 | INVITE F1 | | | 856 | (log me) | | | 857 |--------------->| | | 858 | | INVITE F2 | | 859 | | (log me) | | 860 | |--------------->| | 861 | | | | 862 | | | | 863 | 100 F3 | | | 864 | (log me) | | | 865 |<---------------| | | 866 | | | INVITE F4 | 867 | | | (log me) | 868 | | 100 F5 |--------------->| 869 | | (log me) | | 870 | |<---------------| | 871 | | | 180 F6 | 872 | | | (no log me) | 873 | | |<---------------| 874 | | | | 875 | | | | 876 | | 180 F7 | | 877 | | (log me) | | 878 | |<---------------| | 879 | | | | 880 | | | | 881 | 180 F8 | | | 882 | (log me) | | | 883 |<---------------| | 200 F9 | 884 | | | (no log me) | 885 | | 200 F10 |<---------------| 886 | | (log me) | | 887 | 200 F11 |<---------------| | 888 | (log me) | | | 889 |<---------------| | | 890 | ACK F12 | | | 891 | (log me) | | | 892 |--------------->| | | 893 | | ACK F13 | | 894 | | (log me) | | 895 | |--------------->| ACK F14 | 896 | | | (log me) | 897 | | |--------------->| 898 | Both Way RTP Media | 899 |<================================================>| 900 | | | BYE F15 | 901 | | | (no log me) | 902 | | BYE F16 |<---------------| 903 | | (log me) | | 904 | BYE F17 |<---------------| | 905 | (log me) | | | 906 |<---------------| | | 907 | 200 F18 | | | 908 | (log me) | | | 909 |--------------->| | | 910 | | 200 F19 | | 911 | | (log me) | | 912 | |--------------->| 200 F20 | 913 | | | (log me) | 914 | | |--------------->| 915 | | | | 917 Figure 4: The terminating UA does not support "log me" marking. 919 F1 - Alice's UA inserts a "log me" marker in the the dialog-creating 920 INVITE request F1. 922 F2 - INVITE F2 is "log me" marked and Proxy 2 therefore maintains 923 state that this dialog is to be logged. Proxy 2 logs the request and 924 responses of this dialog if allowed per policy. 926 F5 - Proxy 2 inserts a "log me" marker in the 100 response it sends 927 to Proxy 1. 929 F6 - Bob's UA does not support "log me" marking, therefore the 180 930 response to the INVITE request doesn't have a "log me" marker. 932 F7 - Proxy 2 inserts a "log me" marker in the 180 response on behalf 933 of Bob's UA before forwarding it. The same applies to response F10 934 and the BYE request in F16. 936 4.5.2.3. "Log Me" marking removed by Originating Network 938 If network A in Figure 5 below is performing testing independently of 939 network B then network A removes "log me" marking from SIP requests 940 and responses forwarded to network B to prevent triggering unintended 941 logging in network B. Proxy 1 removes "log me" marking from requests 942 and responses that it forwards to Proxy 2 and maintains state of 943 which dialogs are being "log me" marked in order to "log me" mark 944 requests and responses that it forwards from Proxy 2 to Alice's user 945 agent. For troubleshooting purposes, Proxy 1 MAY also log the 946 requests and responses sent to or received from Proxy 2 even though 947 it removed "log me" marker prior to forwarding the messages to Proxy 948 2. 950 [ NETWORK A ] [ NETWORK B ] 951 Alice Proxy 1 Proxy 2 Bob 952 | | | | 953 | INVITE F1 | | | 954 | (logme) | | | 955 |--------------->| | | 956 | | INVITE F2 | | 957 | | (no logme) | | 958 | |--------------->| | 959 | | | | 960 | | | | 961 | 100 F3 | | | 962 | (logme) | | INVITE F4 | 963 | | | (no logme) | 964 |<---------------| 100 F5 |--------------->| 965 | | (no logme) | | 966 | |<---------------| | 967 | | | 180 F6 | 968 | | | (no logme) | 969 | | 180 F7 |<---------------| 970 | | (no logme) | | 971 | 180 F8 |<---------------| | 972 | (logme) | | | 973 |<---------------| | 200 F9 | 974 | | | (no logme) | 975 | | 200 F10 |<---------------| 976 | | (no logme) | | 977 | 200 F11 |<---------------| | 978 | (logme) | | | 979 |<---------------| | | 980 | ACK F12 | | | 981 | (logme) | | | 982 |--------------->| | | 983 | | | | 984 | | ACK F13 | | 985 | | (no logme) | | 986 | |--------------->| | 987 | | | | 988 | | | ACK F14 | 989 | | | (no logme) | 990 | | |--------------->| 991 | Both Way RTP Media | 992 |<================================================>| 993 | | | BYE F15 | 994 | | | (no logme) | 995 | | BYE F16 |<---------------| 996 | | (no logme) | | 997 | BYE F17 |<---------------| | 998 | (logme) | | | 999 |<---------------| | | 1000 | 200 F18 | | | 1001 | (logme) | | | 1002 |--------------->| | | 1003 | | 200 F19 | | 1004 | | (no logme) | | 1005 | |--------------->| | 1006 | | | | 1007 | | | 200 F20 | 1008 | | | (no logme) | 1009 | | |--------------->| 1010 | | | | 1012 Figure 5: The originating network removes "log me" marking from 1013 outgoing SIP messages at its network edge. 1015 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1016 INVITE request and Proxy 1 therefore maintains state that this dialog 1017 is to be logged. 1019 F2 - Proxy 1 removes "log me" marking from INVITE request before 1020 forwarding it to Proxy 2. Proxy 1 logs INVITE request F2. 1022 F3 - Proxy 1 inserts a "log me" marker in 100 response sent to 1023 Alice's user agent and logs this response. 1025 F8 - Proxy 1 inserts a "log me" marker in 180 response before 1026 forwarding it to Alice's user agent and logs this response. The same 1027 applies to responses F11, F17. 1029 F13 - Proxy 1 removes "log me" marking from ACK request and logs this 1030 request before forwarding it to Proxy 2. 1032 F19 - Proxy 1 removes "log me" marking from the 200 response of the 1033 BYE request and logs this response before forwarding it to Proxy 2. 1035 4.5.2.4. "Log Me" marking removed by Supporting Terminating Network 1037 In Figure 6 below Proxy 2 removes "log me" marking from all SIP 1038 requests and responses entering network B. However, Proxy 2 supports 1039 maintaining the marking state of the dialog and "log me" marks 1040 requests and responses that it sends towards Proxy 1. For 1041 troubleshooting purposes, Proxy 2 MAY also log the requests and 1042 responses received from or sent to Bob even though it removed "log 1043 me" marker prior to forwarding the messages to Bob. 1045 [ NETWORK A ] [ NETWORK B ] 1046 Alice Proxy 1 Proxy 2 Bob 1047 | | | | 1048 | INVITE F1 | | | 1049 | (log me) | | | 1050 |--------------->| | | 1051 | | INVITE F2 | | 1052 | | (log me) | | 1053 | |--------------->| | 1054 | | | | 1055 | | | | 1056 | 100 F3 | | | 1057 | (log me) | | | 1058 |<---------------| | | 1059 | | | INVITE F4 | 1060 | | | (no log me) | 1061 | | 100 F5 |--------------->| 1062 | | (log me) | | 1063 | |<---------------| | 1064 | | | 180 F6 | 1065 | | | (no log me) | 1066 | | |<---------------| 1067 | | 180 F7 | | 1068 | | (log me) | | 1069 | |<---------------| | 1070 | | | | 1071 | | | | 1072 | 180 F8 | | | 1073 | (log me) | | | 1074 |<---------------| | 200 F9 | 1075 | | | (no log me) | 1076 | | 200 F10 |<---------------| 1077 | | (log me) | | 1078 | 200 F11 |<---------------| | 1079 | (log me) | | | 1080 |<---------------| | | 1081 | ACK F12 | | | 1082 | (log me) | | | 1083 |--------------->| | | 1084 | | ACK F13 | | 1085 | | (log me) | | 1086 | |--------------->| ACK F14 | 1087 | | | (no log me) | 1088 | | |--------------->| 1089 | Both Way RTP Media | 1090 |<================================================>| 1091 | | | BYE F15 | 1092 | | | (no log me) | 1093 | | BYE F16 |<---------------| 1094 | | (log me) | | 1095 | BYE F17 |<---------------| | 1096 | (log me) | | | 1097 |<---------------| | | 1098 | 200 F18 | | | 1099 | (log me) | | | 1100 |--------------->| | | 1101 | | 200 F19 | | 1102 | | (log me) | | 1103 | |--------------->| 200 F20 | 1104 | | | (no log me) | 1105 | | |--------------->| 1106 | | | | 1108 Figure 6: The terminating network removes "log me" marking from 1109 incoming SIP messages at its network edge. 1111 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1112 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 1113 request and maintains state that this dialog is to be logged. 1115 F2 - Proxy 2 removes "log me" marker in the INVITE request F2 before 1116 forwarding it as F4. The same applies to responses F13, F19. 1118 F6 - Proxy 2 inserts a "log me" marker in 180 response to the INVITE 1119 request and logs the request before forwarding it as F7. The same 1120 applies to response F9 and the BYE request in F15. 1122 4.5.2.5. "Log Me" marking removed by Non-Supporting Terminating Network 1124 In Figure 6 below Proxy 2 removes "log me" marking from all SIP 1125 requests and responses entering network B and Proxy 2 does not 1126 support "log me" marking. Proxy 2 does not log requests and 1127 responses in the dialog. Proxy 1 supports maintaining the marking 1128 state of the dialog. When Proxy 1 observes that requests and 1129 responses received from Proxy 2 are not marked it adds the marking. 1131 For troubleshooting purposes, Proxy 1 MAY also log the requests and 1132 responses received from or sent to Proxy 2 even though Proxy 2 didn't 1133 add "log me" to messages sent to Proxy 1. 1135 [ NETWORK A ] [ NETWORK B ] 1136 Alice Proxy 1 Proxy 2 Bob 1137 | | | | 1138 | INVITE F1 | | | 1139 | (log me) | | | 1140 |--------------->| | | 1141 | | INVITE F2 | | 1142 | | (log me) | | 1143 | |--------------->| | 1144 | | | | 1145 | | | | 1146 | 100 F3 | | | 1147 | (log me) | | | 1148 |<---------------| | | 1149 | | | INVITE F4 | 1150 | | | (no log me) | 1151 | | 100 F5 |--------------->| 1152 | | (no log me) | | 1153 | |<---------------| | 1154 | | | 180 F6 | 1155 | | | (no log me) | 1156 | | |<---------------| 1157 | | 180 F7 | | 1158 | | (no log me) | | 1159 | |<---------------| | 1160 | | | | 1161 | | | | 1162 | 180 F8 | | | 1163 | (log me) | | | 1164 |<---------------| | 200 F9 | 1165 | | | (no log me) | 1166 | | 200 F10 |<---------------| 1167 | | (no log me) | | 1168 | 200 F11 |<---------------| | 1169 | (log me) | | | 1170 |<---------------| | | 1171 | ACK F12 | | | 1172 | (log me) | | | 1173 |--------------->| | | 1174 | | ACK F13 | | 1175 | | (log me) | | 1176 | |--------------->| ACK F14 | 1177 | | | (no log me) | 1178 | | |--------------->| 1179 | Both Way RTP Media | 1180 |<================================================>| 1181 | | | BYE F15 | 1182 | | | (no log me) | 1183 | | BYE F16 |<---------------| 1184 | | (no log me) | | 1185 | BYE F17 |<---------------| | 1186 | (log me) | | | 1187 |<---------------| | | 1188 | 200 F18 | | | 1189 | (log me) | | | 1190 |--------------->| | | 1191 | | 200 F19 | | 1192 | | (log me) | | 1193 | |--------------->| 200 F20 | 1194 | | | (no log me) | 1195 | | |--------------->| 1196 | | | | 1198 Figure 7: The terminating network removes "log me" marking from 1199 incoming SIP messages at its network edge. 1201 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1202 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 1203 request and maintains state that this dialog is to be logged. 1205 F2 - Proxy 2 removes "log me" marker in the INVITE request F2 before 1206 forwarding it as F4. The same applies to responses F13 and F19. 1208 F7 - Proxy 1 inserts a "log me" marker in 180 response of the INVITE 1209 request before forwarding it as F8. The same applies to response F10 1210 and the BYE request in F16. 1212 4.6. Error Handling 1214 Two error types are defined in Section 5, a missing marker error and 1215 an error of "log me" marking that begins mid-dialog. Section 6 gives 1216 exceptions which have a missing marker or marking that begins mid- 1217 dialog but are not errors. 1219 If a missing marker error is detected by a UA, SIP intermediary, or 1220 B2BUA, it SHOULD consider this as an error condition. It MUST NOT 1221 mark subsequent requests and responses and MUST stop logging messages 1222 in the same dialog. Any previously logged messages SHOULD be 1223 retained and not deleted. 1225 If a "log me" marking that begins mid-dialog error is detected by a 1226 UA, SIP intermediary, or B2BUA, it SHOULD consider this as an error 1227 condition. It MUST NOT forward the "log me" marker and MUST NOT log 1228 the message. It MUST NOT mark subsequent requests and responses and 1229 MUST NOT log subsequent messages in the same dialog. 1231 5. Error Cases 1233 The following error cases are possible for "log me" marking. 1235 1. A "log me" marker is unexpectedly missing from a dialog that is 1236 being logged. 1238 2. A "log me" marker unexpectedly appears in a dialog that is not 1239 being logged 1241 3. A "log me" marker unexpectedly disappears and then reappears in a 1242 dialog being logged. This is treated in the same way as case 1. 1244 4. A "log me" marker is unexpectedly missing from a retransmission 1245 in a dialog being logged. This is treated in the same way as 1246 case 1. 1248 These cases apply to any request or response sent by any entity and 1249 in any direction in a dialog being "log me" marked. Detection of 1250 these error cases is described in this section. 1252 5.1. Missing "Log Me" Marker Error Case 1254 Since "log me" marking is per dialog, if a dialog is being marked and 1255 marking is missing from a request or response then this is an error. 1257 However, detecting such errors is not as simple as checking for 1258 missing markers because of cases such as non-supporting terminals 1259 where it is normal that marking is not done. 1261 Detecting errors must be evaluated separately for each neighbor. It 1262 is an error if a particular neighbor has previously sent logme in the 1263 dialog and then stops, independently of what has been happening with 1264 other neighbors. 1266 User agents and intermediaries that are stateless with respect to 1267 "log me" marking are not able detect such errors. User agents and 1268 intermediaries that are stateful with respect to "log me" marking are 1269 able to detect that a marker is missing from a dialog that has 1270 previously been "log me" marked. Error cases are illustrated in this 1271 section, and non-error cases in Section 6.1. 1273 The following figures illustrate missing "Log me" Marker errors. 1275 Figure 8 shows an error detected at Proxy 1, where an expected "log 1276 me" marker is missing. 1278 [ NETWORK A ] [ NETWORK B ] 1279 Alice Proxy 1 Proxy 2 Bob 1280 | | | | 1281 | INVITE F1 | | | 1282 | (log me) | INVITE F2 | | 1283 |--------------->| (log me) | INVITE F3 | 1284 | |--------------->| (log me) | 1285 | | |--------------->| 1286 | | | | 1287 | | | 200 F4 | 1288 | | 200 F5 | (log me) | 1289 | 200 F6 | (log me) |<---------------| 1290 | (log me) |<---------------| | 1291 |<---------------| | | 1292 | | | | 1293 | ACK F7 | | | 1294 | (no log me) | | | 1295 |--------------->| | | 1296 | | ACK F8 | | 1297 | | (no log me) | | 1298 | |--------------->| | 1299 | | | ACK F9 | 1300 | | | (no log me) | 1301 | | |--------------->| 1303 Figure 8: Error case: missing "log me" marker 1305 F1 - Proxy 1 detects the "log me" marker and maintains state that 1306 this dialog is to be logged. 1308 F7 - Proxy 1 detects that the expected "log me" marker is missing, 1309 considers it as an error and stops "log me" marking in subsequent 1310 requests and responses in this dialog. 1312 Figure 9 shows an error detected at Proxy 2 and Bob's user agent. 1314 [ NETWORK A ] [ NETWORK B ] 1315 Alice Proxy 1 Proxy 2 Bob 1316 | INVITE F1 | | | 1317 | (log me) | | | 1318 |--------------->| | | 1319 | | INVITE F2 | | 1320 | | (log me) | | 1321 | |--------------->| | 1322 | | | | 1323 | | | | 1324 | 100 F3 | | | 1325 | (log me) | | | 1326 |<---------------| | | 1327 | | | INVITE F4 | 1328 | | | (log me) | 1329 | | 100 F5 |--------------->| 1330 | | (log me) | | 1331 | |<---------------| | 1332 | | | 180 F6 | 1333 | | | (log me) | 1334 | | |<---------------| 1335 | | 180 F7 | | 1336 | | (log me) | | 1337 | |<---------------| | 1338 | | | | 1339 | | | | 1340 | 180 F8 | | | 1341 | (log me) | | | 1342 |<---------------| | 200 F9 | 1343 | | | (log me) | 1344 | | 200 F10 |<---------------| 1345 | | (log me) | | 1346 | 200 F11 |<---------------| | 1347 | (log me) | | | 1348 |<---------------| | | 1349 | ACK F12 | | | 1350 | (no log me) | | | 1351 |--------------->| | | 1352 | | ACK F13 | | 1353 | | (no log me) | | 1354 | |--------------->| ACK F14 | 1355 | | | (no log me) | 1356 | | |--------------->| 1358 Figure 9: Error case: missing "log me" marker 1360 F2 - Proxy 2 detects the "log me" marker and maintains state that 1361 this dialog is to be logged. 1363 F4 - Bob's user agent detects the "log me" marker and maintains state 1364 that this dialog is to be logged. 1366 F12 - Proxy 1 detects that the expected "log me" marker is missing, 1367 considers it as an error and stops "log me" marking in subsequent 1368 requests and responses in this dialog. Hence it does not insert a 1369 "log me" marker in F13. 1371 F13 - Proxy 2 detects that the expected "log me" marker is missing, 1372 considers it as an error and stops "log me" marking in subsequent 1373 requests and responses in this dialog. 1375 F14 - Proxy 2 does not insert a "log me" marker because it has 1376 stopped "log me" marking due to an error observed in F13. Bob's UA 1377 detects that the expected "log me" marker is missing, considers it as 1378 an error and stops "log me" marking in subsequent requests and 1379 responses in this dialog. 1381 5.2. "Log Me" Marker Appears Mid-Dialog Error Case 1383 SIP endpoints, intermediaries acting on behalf of endpoints, and 1384 B2BUAs that can perform "log me" marking are stateful. Such entities 1385 will expect a "log me" marker only for dialogs where the initial 1386 dialog-creating request was "log me" marked, either by themselves or 1387 an upstream entity."Log me" marking that subsequently begins mid- 1388 dialog is an error. 1390 Figure 10 illustrates a "log me" marking error observed in the middle 1391 of a dialog. Alice's UA supports "log me" marking but the call is 1392 not initially marked for logging i.e. INVITE F1 is not "log me" 1393 marked. But Alice's UA starts to "log me" mark at the ACK request 1394 F7. Proxy 1 supports "log me" marking at the originating network 1395 boundary and therefore detects the error, does not log signaling, and 1396 removes the "log me" marker before forwarding the ACK request F8. 1398 [ NETWORK A ] [ NETWORK B ] 1399 Alice Proxy 1 Proxy 2 Bob 1400 | | | | 1401 | INVITE F1 | | | 1402 | (no log me) | INVITE F2 | | 1403 |--------------->| (no log me) | INVITE F3 | 1404 | |--------------->| (no log me) | 1405 | | |--------------->| 1406 | | | | 1407 | | | 200 F4 | 1408 | | 200 F5 | (no log me) | 1409 | 200 F6 | (no log me) |<---------------| 1410 | (no log me) |<---------------| | 1411 |<---------------| | | 1412 | | | | 1413 | ACK F7 | | | 1414 | (log me) | | | 1415 |--------------->| | | 1416 | | ACK F8 | | 1417 | | (no log me) | | 1418 | |--------------->| | 1419 | | | ACK F9 | 1420 | | | (log me) | 1421 | | |--------------->| 1423 Figure 10: Error case: "log me" marker begins mid-dialog 1425 6. Non-Error Cases 1427 6.1. Missing "Log me" Marker Non-Error Case 1429 The following figure illustrates a non-error case. 1431 Figure 11 shows Proxy 2 receiving a response with no "log me" marker 1432 that is not an error case. Proxy 2 is configured by network B to 1433 perform "log me" marking on behalf of Bob's UA, which does not 1434 support "log me" marking. Proxy 2 does not therefore expect 1435 responses from Bob to include a "log me" marker. 1437 [ NETWORK A ] [ NETWORK B ] 1438 Alice Proxy 1 Proxy 2 Bob 1439 | | | | 1440 | INVITE F1 | | | 1441 | (log me) | | | 1442 |--------------->| | | 1443 | | INVITE F2 | | 1444 | | (log me) | | 1445 | |--------------->| | 1446 | | | | 1447 | | | | 1448 | 100 F3 | | | 1449 | (log me) | | | 1450 |<---------------| | | 1451 | | | INVITE F4 | 1452 | | | (log me) | 1453 | | 100 F5 |--------------->| 1454 | | (log me) | | 1455 | |<---------------| | 1456 | | | 180 F6 | 1457 | | | (no log me) | 1458 | | |<---------------| 1459 | | 180 F7 | | 1460 | | (log me) | | 1461 | |<---------------| | 1462 | 180 F8 | | | 1463 | (log me) | | | 1464 |<---------------| | | 1466 Figure 11: Non-error case: missing "log me" marker 1468 F2 - Proxy 2 detects the "log me" marker and maintains state that 1469 this dialog is to be logged. Proxy 2 inserts "log me" markers on 1470 behalf of Bob's user agent such as in F7. 1472 F6 - Proxy 2 detects that the "log me" marker is missing from the 1473 response but considers "log me" marking to be ongoing as a marker was 1474 not expected. 1476 F7 - Proxy 2 continues to "log me" mark requests and responses on 1477 behalf of Bob's user agent. 1479 6.2. "Log Me" Marker Appears Mid-Dialog Non-Error Case 1481 A SIP intermediary that can perform "log me" marking on behalf of an 1482 endpoint MAY optionally mark a request or response towards a non- 1483 supporting endpoint, such as the 100 response F3 in Figure 3. In 1484 this case the endpoint will receive a "log me" marker mid-dialog and 1485 is not considered an error. 1487 Another use case is a network that wants uniform "log me" marking 1488 handling across a mixture of "log me" supporting and non-supporting 1489 endpoints. In this case, the endpoint that supports "log me" is not 1490 configured to mark a dialog and the SIP intermediary is configured to 1491 perform "log me" marking on behalf of an endpoint that supports "log 1492 me". This SIP intermediary MAY optionally mark a request or response 1493 towards the endpoint, such as the 100 response F3 in Figure 3. The 1494 endpoint will receive a "log me" marker mid-dialog and this is not 1495 considered an error. 1497 7. Augmented BNF for the "logme" Parameter 1499 ABNF is described in [RFC5234]. This document introduces a new 1500 "logme"parameter for the Session-ID header field defined in Section 5 1501 of [RFC7989]. 1503 sess-id-param =/ logme-param 1505 logme-param = "logme" 1507 Figure 12: Augmented BNF for the "logme" Parameter 1509 8. Security Considerations 1511 8.1. "Log Me" Authorization 1513 An end user or network administrator MUST give permission for a 1514 terminal to perform "log me" marking in the context of regression 1515 testing or troubleshooting a problem. The permission MUST be limited 1516 to only specific calls of interest that are originated in a given 1517 time duration. The configuration of a SIP intermediary to perform 1518 "log me" marking on behalf of a terminal MUST be authorized by the 1519 network administrator. 1521 Activating a debug mode affects the operation of a terminal, 1522 therefore debugging configuration MUST be supplied by an authorized 1523 party to an authorized terminal through a secure communication 1524 channel. 1526 8.2. "Log Me" Marker Removal 1528 The log me marker is not sensitive information, although it will 1529 sometimes be inserted because a particular device is experiencing 1530 problems. 1532 The presence of a log me marker will cause some SIP entities to log 1533 signaling messages. Therefore, this marker MUST be removed at the 1534 earliest opportunity if it has been incorrectly inserted, such as 1535 appearing mid-dialog in a dialog that was not being logged or outside 1536 the configured start and stop of logging. 1538 If SIP requests and responses are exchanged with an external network 1539 with which there is no agreement to pass "log me" marking, then the 1540 "log me" marking is removed. 1542 8.3. Denial of Service Attacks 1544 Maliciously configuring a large number of terminals to simultaneously 1545 "log me" mark dialogs will cause high processor load on SIP entities 1546 that are logging signaling. Since "log me" marking is for the small 1547 number of dialogs subject to troubleshooting or regression testing, 1548 the number of dialogs that can be simultaneously logged can be 1549 statically limited without adversely affecting the usefulness of "log 1550 me" marking. Also, the SIP intermediary closest to the terminal and 1551 SIP intermediary at network edge (e.g Session Border Controllers) can 1552 be configured to screen-out "log me" markers when troubleshooting or 1553 regression testing is not in progress. 1555 8.4. Privacy 1557 Logging includes all SIP header fields. The SIP privacy mechanisms 1558 defined in [RFC3323] can be used to ensure that logs do not divulge 1559 personal identity information. 1561 8.4.1. Personal Identifiers 1563 "Log me" marking is defined for the SIP Protocol, and SIP has header 1564 fields such as From, Contact, P-Asserted-Identity that can carry 1565 personal identifiers. Different protocol interactions can be 1566 correlated using the Session-ID and Call-ID header fields, but such 1567 correlation is limited to a single end-to-end session. 1569 In order to protect user privacy during logging, privacy settings can 1570 be enabled or requested by the terminal used by the end user. 1571 [RFC3323] suggests two mechanisms: 1573 o By using the value anonymous in the From header field 1575 o By requesting privacy from SIP intermediaries using the Privacy 1576 header 1578 Intermediaries that perform "log me" marking on behalf of the 1579 endpoints (see Section 4.3) may also be configured to apply privacy 1580 (as defined in Section 3.3 of [RFC3323]) on messages that belong to a 1581 dialog that is "log me" marked. 1583 "Log me" marking is typically used for troubleshooting and regression 1584 testing, and in some cases a service provider owned device with a 1585 dummy account can be used instead of a customer device. In such 1586 cases, no personal identifiers are included in the logged signaling 1587 messages. 1589 8.4.2. Data Stored at SIP Intermediaries 1591 SIP endpoints and intermediaries that honor the "log me" request 1592 store all the SIP messages that are exchanged within a given dialog. 1593 SIP messages can contain the personal identifiers listed in 1594 Section 8.4.1 and additionally a user identity, calling party number, 1595 IP address, hostname, and other user and device related items. The 1596 SIP message bodies describe the kind of session being set up by the 1597 identified end user and device. 1599 "Log me" marking does not introduce any additional user or device 1600 data to SIP but might indicate that a specific user is experiencing a 1601 problem. 1603 8.4.3. Data Visible at Network Elements 1605 SIP messages that are logged due to "log me" requests are stored only 1606 by the SIP initiators, intermediaries and recipients. Enablers as 1607 defined in section 3.1 of [RFC6973], such as firewalls and DNS 1608 servers do not log messages due to the "log me" marking. 1610 8.4.4. Preventing Fingerprinting 1612 "Log me" functionality is typically used to troubleshoot a given 1613 problem and hence it can be used as an method to identify users and 1614 devices that are experiencing issues. The best way to prevent 1615 fingerprinting of users is to enable or request SIP privacy for the 1616 logged dialog. 1618 8.4.5. Retaining Logs 1620 The lifetime of "log me" marking is equivalent to the lifetime of the 1621 dialog that initiated the "log me" request. When "log me" is 1622 extended to related dialogs the lifetime is extended until there is 1623 no more related dialog for the end-to-end session. 1625 "Log me" automatically expires at the end of the dialog and there is 1626 no explicit mechanism to turn off logging within a dialog. 1628 The scope of "log me" Marking is limited i.e. an user or the network 1629 administrator has to enable it on a per session basis or for a 1630 specific time period. This minimizes the risk of exposing user data 1631 for an indefinite time. 1633 The retention time period for logged messages SHOULD be the minimum 1634 needed for each particular troubleshooting or testing case. The 1635 retention period is configured based on the data retention policies 1636 of service providers and enterprises. 1638 8.4.6. User Control of Logging 1640 Consent to turn on "log me" marking for a given session MUST be 1641 provided by the end user or by the network administrator. It is 1642 handled outside of the protocol through user interface or application 1643 programming interfaces at the end point, call control elements and 1644 network management systems. 1646 SIP entities across the communication path MAY be configured to pass 1647 through the "log me" marking but not honor the request i.e. not log 1648 the data based on local policies. 1650 8.4.7. Recommended Defaults 1652 The recommended defaults for "log me" marking are: 1654 o turn on SIP privacy as described in Section 8.4 or use a service 1655 provider owned device with a dummy user identity for test calls 1657 o use the local UUID of Session-ID header at the originating device 1658 as the test case identifier as described in Section 3.3 1660 8.5. Data Protection 1662 A SIP entity that has logged information MUST protect the logs. 1663 Storage of the log files are subject to the security considerations 1664 specified in [RFC6872]. 1666 9. IANA Considerations 1668 9.1. Registration of the "logme" Parameter 1670 The following parameter is to be added to the "Header Field 1671 Parameters and Parameter Values" section of the SIP parameter 1672 registry: 1674 +-------------+---------------+-------------------------+-----------+ 1675 | Header | Parameter | Predefined Values | Reference | 1676 | Field | Name | | | 1677 +-------------+---------------+-------------------------+-----------+ 1678 | Session-ID | logme | No (no values are | [RFCXXXX] | 1679 | | | allowed) | | 1680 +-------------+---------------+-------------------------+-----------+ 1682 Table 1 1684 10. Acknowledgments 1686 The authors wish to thank Paul Giralt, Paul Kyzivat, Jorgen Axell, 1687 Christer Holmberg and Vijay Gurbani for their constructive review 1688 comments and guidance while developing this document. 1690 11. References 1692 11.1. Normative References 1694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1695 Requirement Levels", BCP 14, RFC 2119, 1696 DOI 10.17487/RFC2119, March 1997, 1697 . 1699 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1700 A., Peterson, J., Sparks, R., Handley, M., and E. 1701 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1702 DOI 10.17487/RFC3261, June 2002, 1703 . 1705 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1706 Initiation Protocol (SIP)", RFC 3323, 1707 DOI 10.17487/RFC3323, November 2002, 1708 . 1710 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1711 H., and O. Festor, "The Common Log Format (CLF) for the 1712 Session Initiation Protocol (SIP): Framework and 1713 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1714 February 2013, . 1716 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1717 Session Initiation Protocol (SIP) Common Log Format 1718 (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, 1719 . 1721 [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- 1722 to-End Session Identification in IP-Based Multimedia 1723 Communication Networks", RFC 7989, DOI 10.17487/RFC7989, 1724 October 2016, . 1726 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1727 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1728 May 2017, . 1730 11.2. Informative References 1732 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1733 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1734 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1735 December 2003, . 1737 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1738 Specifications: ABNF", STD 68, RFC 5234, 1739 DOI 10.17487/RFC5234, January 2008, 1740 . 1742 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1743 Initiation Protocol (SIP) Call Control - Transfer", 1744 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1745 . 1747 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1748 Morris, J., Hansen, M., and R. Smith, "Privacy 1749 Considerations for Internet Protocols", RFC 6973, 1750 DOI 10.17487/RFC6973, July 2013, 1751 . 1753 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1754 Initiation Protocol (SIP) Back-to-Back User Agents", 1755 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1756 . 1758 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1759 Kaplan, "Requirements for an End-to-End Session 1760 Identification in IP-Based Multimedia Communication 1761 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1762 . 1764 [RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking 1765 SIP Messages to be Logged", RFC 8123, 1766 DOI 10.17487/RFC8123, March 2017, 1767 . 1769 Authors' Addresses 1771 Peter Dawes 1772 Vodafone Group 1773 The Connection 1774 Newbury, Berkshire RG14 2FN 1775 UK 1777 Email: peter.dawes@vodafone.com 1779 Chidambaram Arunachalam 1780 Cisco Systems 1781 7200-12 Kit Creek Road 1782 Research Triangle Park, NC 27709 1783 US 1785 Email: carunach@cisco.com