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