idnits 2.17.1 draft-dawes-dispatch-debug-00.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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 231 has weird spacing: '...orp.com p1.fo...' -- The document date (February 20, 2012) is 4442 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) == Unused Reference: 'I-D.ietf-sipping-config-framework' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 851, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.kaplan-dispatch-session-id' == Outdated reference: A later version (-08) exists of draft-worley-references-07 -- Obsolete informational reference (is this intentional?): RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 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 February 20, 2012 5 Expires: August 23, 2012 7 Session Initiation Protocol (SIP) Header Parameter for Debugging 8 draft-dawes-dispatch-debug-00 10 Abstract 12 Networks that use SIP to start and stop sessions between their users 13 will frequently be upgraded with software and hardware changes. 14 Users will similarly frequently change their client software and the 15 way they use the network. In order to allow troubleshooting and 16 regression testing, it is useful to provide debugging as part of the 17 network fabric. This draft describes an event package that provides 18 debugging configuration to SIP entities and a SIP private header that 19 triggers logging of SIP signalling and identifies logs at mulitiple 20 SIP entities as belonging to a single end-to-end session. 22 A list of related IETF drafts and non-IETF specifications is included 23 to help develop this topic. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 23, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Related Drafts and Specifications . . . . . . . . . . . . . . 4 62 4. Motivating Scenario . . . . . . . . . . . . . . . . . . . . . 4 63 5. Signalling for Example Scenario . . . . . . . . . . . . . . . 5 64 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. Configuring Entities for Debugging . . . . . . . . . . . . 5 66 5.3. Originating Session . . . . . . . . . . . . . . . . . . . 6 67 5.4. Terminating Sessions . . . . . . . . . . . . . . . . . . . 10 68 6. Providing Configuration Data to the Terminal and Network . . . 10 69 7. Avoiding Configuring all Entities on the Signalling Path . . . 10 70 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.2. Originating Sessions . . . . . . . . . . . . . . . . . . . 11 72 7.3. Terminating Sessions . . . . . . . . . . . . . . . . . . . 11 73 8. Multiple Simultaneous Events . . . . . . . . . . . . . . . . . 11 74 9. debug Parameter in SIP Requests . . . . . . . . . . . . . . . 13 75 9.1. Forked Requests . . . . . . . . . . . . . . . . . . . . . 13 76 9.2. Back-to-Back User Agents . . . . . . . . . . . . . . . . . 13 77 10. debug Parameter in SIP Responses . . . . . . . . . . . . . . . 13 78 11. Multiple Service Providers . . . . . . . . . . . . . . . . . . 13 79 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 12. Configuration for Multiple AORs . . . . . . . . . . . . . . . 14 81 13. Retrieving Debugging Logs . . . . . . . . . . . . . . . . . . 14 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 14.1. Trust Domain . . . . . . . . . . . . . . . . . . . . . . . 14 84 14.2. Security Threats . . . . . . . . . . . . . . . . . . . . . 15 85 14.3. Security Mechanisms . . . . . . . . . . . . . . . . . . . 15 86 15. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 87 15.1. debug Header Field Parameter Syntax . . . . . . . . . . . 15 88 16. XML Schema for Debug Configuration . . . . . . . . . . . . . . 16 89 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 91 17.2. Informative References . . . . . . . . . . . . . . . . . . 19 92 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 20 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 If users experience problems with setting up sessions using SIP, 98 their service provider needs to find out why by examining the SIP 99 signalling. This draft defines an event package to configure SIP 100 entities with conditions for starting and stopping logging of SIP 101 signalling a SIP header field that allows a service provider to link 102 signalling logged at various SIP entities in order to troubleshoot 103 session setup. 105 The skeleton of the debugging procedure is as follows: 107 o The user's terminal is prompted to enrol to debug configuration, 108 supplied from a debug event package 110 o The first proxy the terminal connects to, at the edge of the 111 network, either is already primed to log any signalling that is 112 identified for debug, because it is permanenently enrolled to 113 receive debug configuration for all users, or is prompted to enrol 114 in the same way as the terminal. 116 o The user's terminal receives configuration, in the form of an XML 117 file, that indicates to the terminal when it should start and stop 118 logging signalling. 120 o When user's terminal sends a SIP request that matches the pre- 121 configured criteria for logging, logging starts at the user's 122 terminal, at the first proxy the terminal connects to, and at any 123 other SIP entity within the trust domain that receives the 124 request. 126 o Subsequent responses and requests in the same dialog are logged. 128 o Logging stops, either because the dialog has ended or because a 129 'stop' event, defined in the debug configuration, occurred 131 o The user's terminal, the proxy, and any other SIP entity that has 132 logged signalling sends its logs to the debug server 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 3. Related Drafts and Specifications 142 The following drafts are related to troubleshooting SIP calls. 144 o I-D.draft-kaplan-dispatch-session-id 145 [I-D.kaplan-dispatch-session-id] 147 o I-D.worley-references [I-D.worley-references] 149 o I-D.kaithal-dispatch-sip-log-information 150 [I-D.kaithal-dispatch-sip-log-information] 152 o I-D.jones-ipmc-session-id-reqts [I-D.jones-ipmc-session-id-reqts] 154 o I-D.jones-ipmc-session-id [I-D.jones-ipmc-session-id] 156 The following non-IETF specifications include requirements for 157 troubleshooting and testing SIP calls. 159 o TS 32.422, Telecommunication management; Subscriber and equipment 160 trace; Trace control and configuration management [3GPP.32.422] 161 includes requirements for trace control and configuration for 3GPP 162 networks, including the SIP-based IP Multimedia Subsystem (IMS). 164 o OMA Service Provider Environment Requirements Candidate Version 165 1.0 - 14 June 2005 [OMAOPSEV1] contains the Open Mobile Alliance 166 requirements for regression testing after a network change or fix 167 and for service troubleshooting. 169 The following RFC describes the standardization collaboration between 170 3GPP and IETF 172 o RFC3113 [RFC3113] 174 4. Motivating Scenario 176 Alice has a SIP client on her laptop, which she has been using for 177 some time to make video calls to work colleagues inside her company, 178 FooCorp, including making video calls and sending pager-mode 179 messages. Last week, her company became able to contact staff 180 working for its principal customer BarCorp, which recently installed 181 a SIP-based network. Today, she tried to set up a call to Bob at 182 BarCorp who uses an audio-only SIP phone, but the call failed and 183 Alice does not know why. Also, she tried sending an instant message 184 to her friend Carol, also working at BarCorp, and her terminal 185 displayed 'message failed'. She contacts those who manage the SIP 186 network within FooCorp, e.g. by phone or e-mail, to ask them to 187 investigate the problem. 189 This draft discusses the properties of a solution for debugging such 190 a scenario, and outlines one possible solution. 192 5. Signalling for Example Scenario 194 5.1. General 196 The network administrators at FooCorp are first interested in whether 197 the problem is within FooCorp or BarCorp. They would like to log the 198 SIP signalling from Alice's client to the edge of the FooCorp 199 network. In order to do this, Alice's client, the SIP entity at the 200 border between FooCorp and BarCorp, and all of the SIP entities in 201 between must log signalling for both the audio call and the instant 202 message. The network administrators can then examine the logs to 203 determine the cause of the problem. 205 5.2. Configuring Entities for Debugging 207 Before any debugging can be done, Alice's SIP client needs 208 configuration information that instructs the SIP client when to log 209 SIP signalling. All debug configuration information at FooCorp is 210 hosted on a single logical debug server, debug.foocorp.com, which 211 hosts an event package that provides configuration using SUBSCRIBE 212 and NOTIFY methods. Usually, SIP clients are not subscribed to this 213 event package, since debugging is rarely used. Because debugging is 214 rare, the debug event package should be subscribed to only when 215 required, which is achieved by triggering subscription when Alice 216 refreshes her registration. The administrators cause Alice to re- 217 register by notifying her UA that its subscription has expired. When 218 Alice's UA re-registers, a session-ID header field with a debug 219 parameter is included in the 200 OK response to the REGISTER request. 220 This debug parameter causes Alice's UA to subscribe to Alice's debug 221 event package at the debug server, which returns an XML document 222 containing her debugging configuration. Typically, the Expires 223 header field in the SUBSCRIBE request will have a 0 (zero) value 224 because debugging is usually a one-off activity. Other than the 225 NOTIFY request that triggers Alice's SIP client to re-register and 226 subscribe to the debug event package, signalling is as for the 227 standardized framework for supplying configuration to a SIP client 228 described in RFC 6080 [RFC6080]. 230 Alice Proxy Registrar Debug Server 231 u1.foocorp.com p1.foocorp.com r1.foocorp.com d1.foocorp.com 232 | | | | 233 | | | | 234 |(1) NOTIFY (Alice's registration terminated) | 235 | Event: reg | | | 236 |<-------------------------------------------------------| 237 | | | | 238 |(2) REGISTER (Alice re-registers) | | 239 |----------------->| | | 240 | |(3) REGISTER | | 241 | |----------------->| | 242 | | | | 243 | |(4) 200 OK | | 244 | |session-ID:;debug | | 245 | |<-----------------| | 246 |(5) 200 OK | | | 247 |session-ID:;debug | | | 248 |<-----------------| | | 249 | | | | 250 |(6) ACK | | | 251 |------------------------------------>| | 252 | | | | 253 |(7) SUBSCRIBE | | | 254 | Event: debug | | | 255 |------------------------------------------------------->| 256 |(8) 200 OK | | | 257 |<-------------------------------------------------------| 258 | | | | 259 |(9) NOTIFY (debug configuration in body) | 260 |<-------------------------------------------------------| 261 |(10)200 OK | | | 262 |------------------------------------------------------->| 263 | | | | 265 Figure 1: Prompting Client to Retrieve Debugging Configuration 267 5.3. Originating Session 269 The XML document returned to Alice's terminal contains the debugging 270 configuration shown below. The schema for this XML file is described 271 in detail in Section 16. This configuration instructs the terminal 272 when to start logging, when to stop, and a value for the debug 273 parameter added to the session-ID header field. 275 276 bob@barcorp.com 277 278 279 T0H2M0S 280 281 282 1A346D 283 285 Figure 2: Minimal Debugging Configuration for UA 287 The start-trigger element instructs Alice's terminal to begin to log 288 signalling for any SIP request that contains bob@barcorp.com in the 289 To: header field. The stop-trigger element instructs Alice's 290 terminal end logging signalling after a time period of two minutes. 291 Alice's terminal adds a debug parameter to the session-ID header 292 field in all logged SIP requests, and the debug-control element 293 contains the value that Alice's terminal will assign to the debug 294 parameter. 296 Proxy p1.foocorp.com is supplied with similar configuration, shown 297 below, with one important difference, that the debug parameter value 298 is part of the start trigger, thereby ensuring that the session from 299 Alice is logged, not simply any request sent to Bob. 301 302 303 bob@barcorp.com 304 1A346D 305 306 307 T0H2M0S 308 309 311 Figure 3: Minimal Debugging Configuration for Proxy 313 For all entities, debug configuration is used for a single dialog and 314 then discarded, which means that once Alice's UA has started the 315 dialog with Bob, the debug configuration shown above is not re-used 316 for any subsequent dialogs. The scope of logging is the dialog for 317 which logging started, logging is not done of any other dialog that 318 was in progress or is started while logging the dialog with Bob. 320 The FooCorp network is organized such that all SIP clients route 321 requests through the first SIP proxy they connect to, and their 322 registrar, by using the path: and Service-Route: header fields. 323 Other SIP proxies may also be on the signalling path. 325 The debugging configuration causes Alice's UA and the first SIP proxy 326 connected to Alice's terminal to log SIP signalling the next time she 327 sends an INVITE request to bob@barcorp.com. Alice retries calling 328 Bob and signalling is logged for two minutes. Later examination of 329 these logs shows that although requests and responses are correctly 330 exchanged with Bob, Alice's SIP client is not accepting audio-only 331 sessions and is sending BYE immediately. This problem had not come 332 to light previously as all calls within Alice's company are video 333 calls. 335 The outline call flow below illustrates how debugging works. 336 Signalling logged at Alice's UA and the Proxy shows that requests and 337 responses are successfully exchanged, but Alice's UA will not set up 338 an audio-only session and sends BYE immediately. 340 Alice Proxy Bob 341 |(1) INVITE | | 342 | m = audio | | 343 | m = video | | 344 | From:alice at atlanta.com | 345 | Sessin-ID: | | 346 | ;debug="A076D1" | | 347 | Alice's UA starts logging | 348 |--------------------->| | 349 | | (2) INVITE | 350 | | debug value and From: | 351 | | match debugging config| 352 | | so proxy starts | 353 | | logging | 354 | |---------------------->| 355 | | | 356 | | (3) 200 OK | 357 | | m = audio | 358 | |<----------------------| 359 |(4) 200 OK | | 360 |<---------------------| | 361 | | | 362 |(5) ACK | | 363 |--------------------->| | 364 | | (6) ACK | 365 | |---------------------->| 366 | | | 367 |(7) BYE | | 368 |--------------------->| | 369 | | (8) BYE | 370 | |---------------------->| 371 | | | 372 | | (9) 200 OK | 373 | |<----------------------| 374 | | Dialog has ended so | 375 | | Proxy stops logging | 376 | (10) 200 OK | | 377 |<---------------------| | 378 | Dialog has ended, so | | 379 | Alice's UA stops | | 380 | logging | | 382 Figure 4: Example of Debugging 384 5.4. Terminating Sessions 386 Logging of a terminating session should start at the SIP proxy at the 387 incoming edge of a network. For example, Bob has been told by Alice 388 that her calls are not getting through and therefore asks the BarCorp 389 network administrators to check any incoming calls from Alice. The 390 proxy at the edge of the BarCorp network is provided with the 391 configuration below to log any incoming calls from Alice. The 392 element contains the value for the debug header field 393 parameter that the proxy will insert. 395 396 397 bob@barcorp.com 398 alice@foocorp.com 400 401 402 T0H2M0S 403 404 405 2B346D 406 407 409 Figure 5: Minimal Debugging Configuration for Proxy 411 When Alice calls Bob, the proxy at the edge of the BarCorp network 412 begins logging and inserts a debug header field parameter with the 413 value 2B346D taken from the configuration data. 415 6. Providing Configuration Data to the Terminal and Network 417 The configuration data required to trigger debugging in a network 418 entity is an XML document, and this document must be delivered to 419 network entities. RFC 6080 [RFC6080] describes a method for 420 providing such configuration data, in this case of profile type "User 421 Profile" as defined in clause 3.3 of RFC 6080 [RFC6080]. 423 7. Avoiding Configuring all Entities on the Signalling Path 425 7.1. General 427 It is desirable to minimize the need for SIP entities to enrol for 428 debug configuration for two reasons. Firstly, each enrollment 429 results in state maintained in the entity that enrols and in the 430 debug server. Secondly, the path through proxies of a SIP request 431 cannot always be predicted, therefore an indication in the signalling 432 itself that this signalling should be logged is needed. 434 The requirements above can be met by one proxy policing the debug 435 header field parameter on behalf of all other proxies downstream. 436 Two cases are possible, a sesssion originated at a terminal, and a 437 session that enters a network which will be terminated at a terminal 438 attached to that network. 440 7.2. Originating Sessions 442 Both the terminal and the proxy that it connects to at the edge of 443 the FooCorp network are configured with debug data. Since the 444 terminal is outside the trust domain, the edge proxy checks the debug 445 header field parameter inserted by the terminal, if any, against the 446 debug configuration data it has been supplied for that terminal. If 447 debug parameter should not have been inserted by the terminal, or 448 contains an incorrect value, the proxy removes it. If the SIP 449 request has no debug header field parameter but matches the debug 450 configuration data in the proxy, the proxy inserts a debug parameter 451 with the configured value. 453 7.3. Terminating Sessions 455 The SIP registrar for the address of record being debugged and the 456 terminating user's UA are provided with debug configuration. The SIP 457 request passes through this registrar on its way to the terminating 458 UA and the registrar inserts a debug header field parameter. SIP 459 entities in the same trust domain and downstream of the registrar can 460 trust that the presence of the debug parameter indicates that they 461 should log that SIP request or response. The terminating user's UA 462 is outside the trust domain and therefore requires its own 463 configuration data. 465 8. Multiple Simultaneous Events 467 At the same time as looking into the problem with calling Bob, the 468 administrators at FooCorp also want to find out why the message sent 469 to Carol caused an error display on Alice's terminal. In order to do 470 this, they add the configuration below to the debug event package 471 hosted on the debug server. Each configuration fragment enclosed by 472 the tags and applies debugging to a single 473 SIP session, and in the same way that the number of simultaneous SIP 474 sessions is not restricted there is no restriction on how many 475 sessions are being simultaneosly debugged. The configuration is a 476 new session that has a different id attribute to the previous 477 session. This configuration is supplied to the terminal, and the 478 terminal adds it to the session with id="u01" for debugging the 479 problem with calling Bob. 481 482 483 carol@barcorp.com 484 485 486 T0H2M0S 487 488 489 1A346E 490 491 493 Figure 6: Debugging Configuration for Instant Message 495 Alice then re-sends a message request to Carol and the call flow 496 below is recorded. 498 Alice Proxy Carol 499 |(1) MESSAGE | | 500 | From:alice@foocorp.com | | 501 | Session-ID: | | 502 | ;debug=1A346E | | 503 | Alice's UA starts logging | 504 |----------------------->| | 505 | | (2) MESSAGE | 506 | | debug value and To: | 507 | | match debugging config | 508 | | so proxy starts | 509 | | logging | 510 | |------------------------>| 511 | | | 512 | | (3) 501 Not Implemented | 513 | | Session-ID: | 514 | | ;debug="1A346E" | 515 | |<------------------------| 516 |(4) 501 Not Implemented | Dialog has ended, so | 517 | Session-ID: | proxy stops | 518 | debug="1A346E" | logging | 519 |<-----------------------| | 520 | Dialog has ended, so | | 521 | Alice's UA stops | | 522 | logging | | 523 Figure 7: Example of Debugging a MESSAGE Request 525 The signalling flow shows that Carol's SIP UA is not able to process 526 MESSAGE requests. In fact, Carol has an audio-only black phone. 527 Logging for the MESSAGE request sent to Carol and the INVITE request 528 sent to Bob happens simultaneously. 530 9. debug Parameter in SIP Requests 532 9.1. Forked Requests 534 Since forked requests are part of the same intention of the user to 535 communicate, the debug header field parameter is copied unchanged 536 from a single SIP request into all SIP requests that result from the 537 forking. 539 9.2. Back-to-Back User Agents 541 Since requests generated by a B2BUA as a result of an incoming 542 request that is being debugged are part of the same intention of the 543 user to communicate, the debug header field paramter is copied 544 unchanged from a SIP request into all new outgoing SIP requests that 545 a B2BUA generates as a result of the incoming SIP request that 546 contained the parameter. 548 10. debug Parameter in SIP Responses 550 The debug header field parameter is copied unchanged from a single 551 SIP request into all responses, provisional and final, to that SIP 552 request. 554 11. Multiple Service Providers 556 11.1. General 558 Foocorp is able to check signalling in its own network, but not in 559 the network of Barcorp. Two solutions are possible, either entities 560 in Barcorp are allowed to retrieve debugging configuration by sending 561 a SUBSCRIBE request to the debug server in Foocorp, or Foocorp asks 562 Barcorp to setup similar debugging in its own network to investigate 563 why the MESSAGE request to Carol is failing. The debugging 564 configuration in Barcorp would consist of logging signalling for 565 requests that are incoming to Carol (i.e., with carol@barcorp.com in 566 the From: header field). 568 12. Configuration for Multiple AORs 570 Any entity may subscribe to a URI that identifies a group of AORs. 571 If multiple NOTIFY requests carry configuration information about the 572 same AOR then the most recent configuration document is used. It 573 might be that a new NOTIFY request adds a session to existing 574 configuration for an AOR and otherwise leaves its existing 575 configuration untouched. 577 13. Retrieving Debugging Logs 579 When logging finishes, either because the stop trigger event 580 occurred, or because the dialog being logged has ended, the SIP 581 entity sends logged signalling in the body of a PUBLISH request sent 582 to the debug event server. If this PUBLISH request will cross a 583 trust domain boundary, it MUST use authentication, integrity 584 protection, and privacy protection. Logged signalling in the body of 585 the PUBLISH request will typically be text such as MIME type text/ 586 plain of SIP requests and responses and their bodies. In order to 587 correlate logged signalling, it might be useful to separate out the 588 dialog ID as described in RFC 3261 [RFC3261] clause 12, the debug 589 parameter value, and the Max Forwards: header field. 591 The debug event server reconstructs the flow of signalling using the 592 dialog identity (Call-ID: header field and the tags in the To: and 593 From: header fields) and the CSeq: and Max-Forwards: header fields. 595 14. Security Considerations 597 All drafts are required to have a security considerations section. 598 See RFC 3552 [RFC3552] for a guide. 600 14.1. Trust Domain 602 Since a non-empty header field parameter value may cause a SIP entity 603 to log the SIP header and body of a request or response, the debug 604 parameter must be removed at a trust domain boundary. If BarCorp is 605 outside the trust domain of FooCorp, then BarCorp will not receive 606 the debug parameter. However, the SIP entity at the edge of the 607 BarCorp network can attempt to subscribe to the debug configuration 608 for alice@foocorp.com and use this configuration to cause logging in 609 the BarCorp network. 611 14.2. Security Threats 613 The identity carried by the debug header parameter is not sensitive 614 information, although it will sometimes indicate that a particular 615 device is experiencing problems. If the value in the header is 616 maliciously changed, this will disrupt troubleshooting. 618 The presence of a debug header field parameter will cause some SIP 619 entities to log signalling. Therefore, this header field must be 620 removed at the earliest opportunity if it has been incorrectly 621 inserted. 623 Debug configuration affects the operation of a terminal, therefore it 624 must be supplied by an authorized server to an authorized terminal, 625 it must not be altered in transit, and it must not be readable by an 626 unauthorized third party. 628 Logged signalling is privacy-sensitive data, therefore it must be 629 passed to an authorized server, it must not be altered in transit, 630 and it must not be readable by an unauthorized third party. 632 14.3. Security Mechanisms 634 Security considerations are very similar to those in RFC 6080 635 [RFC6080], so the same mechanisms can be used to secure debugging 636 configuration and logged signalling. 638 15. Formal Syntax 640 All of the mechanisms specified in this document are described in 641 both prose and an augmented Backus-Naur Form (BNF) defined in RFC 642 2234 [RFC2234]. Further, several BNF definitions are inherited from 643 SIP and are not repeated here. Implementors need to be familiar with 644 the notation and contents of SIP RFC 3261 [RFC3261] and RFC 2234 645 [RFC2234] to understand this document. 647 15.1. debug Header Field Parameter Syntax 649 The syntax for the debug header field parameter is described as 650 follows: 652 debug = "debug" EQUAL 6*6HEXDIG 654 16. XML Schema for Debug Configuration 656 Configuration for debugging is supplied as an XML document according 657 to the schema in Figure 8. 659 660 664 665 667 672 673 674 675 676 677 678 679 680 681 683 684 685 686 687 688 689 690 691 693 694 695 696 697 698 699 700 702 703 704 706 708 709 710 711 712 713 714 715 716 718 719 720 721 722 724 726 727 728 729 730 732 733 734 735 736 737 738 739 741 742 743 744 745 746 747 748 749 751 753 754 755 756 757 758 759 760 761 762 763 764 765 767 768 769 770 771 772 773 774 775 777 778 779 780 781 782 783 784 785 787 789 Figure 8: XML schema for debugging configuration 791 17. References 793 17.1. Normative References 795 [I-D.kaplan-dispatch-session-id] 796 Kaplan, H., "A Session Identifier for the Session 797 Initiation Protocol (SIP)", 798 draft-kaplan-dispatch-session-id-03 (work in progress), 799 March 2011. 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, March 1997. 804 17.2. Informative References 806 [3GPP.32.422] 807 3GPP, "Telecommunication management; Subscriber and 808 equipment trace; Trace control and configuration 809 management", 3GPP TS 32.422 10.6.0, December 2011. 811 [I-D.ietf-sipping-config-framework] 812 Channabasappa, S., "A Framework for Session Initiation 813 Protocol User Agent Profile Delivery", 814 draft-ietf-sipping-config-framework-18 (work in progress), 815 October 2010. 817 [I-D.jones-ipmc-session-id] 818 Jones, P., Pearce, C., Polk, J., and G. Salgueiro, "End- 819 to-End Session Identification in IP-Based Multimedia 820 Communication Networks", draft-jones-ipmc-session-id-03 821 (work in progress), January 2012. 823 [I-D.jones-ipmc-session-id-reqts] 824 Jones, P., Salgueiro, G., Polk, J., R, P., Liess, L., 825 Jesske, R., Loreto, S., and H. Kaplan, "Requirements for 826 an End-to-End Session Identification in IP-Based 827 Multimedia Communication Networks", 828 draft-jones-ipmc-session-id-reqts-01 (work in progress), 829 January 2012. 831 [I-D.kaithal-dispatch-sip-log-information] 832 Kaithal, A., "Session Initiation Protocol (SIP) Extension 833 for logging and debugging.", 834 draft-kaithal-dispatch-sip-log-information-00 (work in 835 progress), October 2011. 837 [I-D.worley-references] 838 Worley, D., "The References Header for SIP", 839 draft-worley-references-07 (work in progress), 840 October 2011. 842 [OMAOPSEV1] 843 Open Mobile Alliance, "OMA Service Provider Environment 844 Requirements Candidate Version 1.0 - 14 June 2005", 2005, 845 . 848 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 849 Specifications: ABNF", RFC 2234, November 1997. 851 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 852 June 1999. 854 [RFC3113] Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin, 855 "3GPP-IETF Standardization Collaboration", RFC 3113, 856 June 2001. 858 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 859 A., Peterson, J., Sparks, R., Handley, M., and E. 860 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 861 June 2002. 863 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 864 Text on Security Considerations", BCP 72, RFC 3552, 865 July 2003. 867 [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session 868 Initiation Protocol User Agent Profile Delivery", 869 RFC 6080, March 2011. 871 Appendix A. Additional Stuff 873 This becomes an Appendix. 875 Author's Address 877 Peter Dawes 878 Vodafone Group 879 The Connection 880 Newbury, Berkshire RG14 2FN 881 UK 883 Phone: +44 7717 275009 884 Email: peter.dawes@vodafone.com