idnits 2.17.1 draft-dawes-dispatch-logme-reqs-04.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 16, 2014) is 3724 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: 'RFC2234' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC3311' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC3428' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC3903' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC6086' is defined on line 303, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-insipid-session-id-reqts-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 (~~), 10 warnings (==), 3 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 January 16, 2014 5 Expires: July 20, 2014 7 Requirements for Marking SIP Messages to be Logged 8 draft-dawes-dispatch-logme-reqs-04 10 Abstract 12 SIP networks use signalling monitoring tools to diagnose user 13 reported problem and for regression testing if network or client 14 software is upgraded. As networks grow and become interconnected, 15 including connection via transit networks, it becomes impractical to 16 predict the path that SIP signalling will take between clients, and 17 therefore impractical to monitor SIP signalling end-to-end. 19 This draft describes requirements for adding an indicator to the SIP 20 protocol which can be used to mark signalling as of interest to 21 logging. Such marking will typically be applied as part of network 22 testing controlled by the network operator and not used in regular 23 client signalling. However, such marking can be carried end-to-end 24 including the SIP terminals, even if a session originates and 25 terminates in different networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 20, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 63 3. Motivating Scenario . . . . . . . . . . . . . . . . . . . . . 3 64 4. Skeleton Diagnostic Procedure . . . . . . . . . . . . . . . . 4 65 5. Requirements for a Log Me Marker . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6.1. Trust Domain . . . . . . . . . . . . . . . . . . . . . . 6 68 6.2. Security Threats . . . . . . . . . . . . . . . . . . . . 6 69 6.2.1. Log-me marking . . . . . . . . . . . . . . . . . . . 6 70 6.2.2. Sending logged information . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 If users experience problems with setting up sessions using SIP, 80 their service provider needs to find out why by examining the SIP 81 signalling. Also, if network or client software or hardware is 82 upgraded regression testing is needed. Such diagnostics apply to a 83 small proportion of network traffic and can apply end-to-end, even if 84 signalling crosses several networks possibly belonging to several 85 different network operators. It may not be possible to predict the 86 path through those networks in advance, therefore a mechanism is 87 needed to mark a session as being of interest to enable SIP entities 88 along the signalling path to provide diagnostic logging. This draft 89 describes the requirements for such a 'log me' marker for SIP 90 signalling. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Motivating Scenario 100 Signalling for SIP session setup can cross several networks, and 101 these networks may not have common ownership and also may be in 102 differrent countries. If a single operator wishes to perform 103 regression testing or fault diagnosis end-to-end, the separate 104 ownership of networks that carry the signalling and the explosion in 105 the number of possible signalling paths through SIP entities from the 106 originating to the terminating user make it impractical to pre- 107 configure logging of an end-to-end SIP signalling of a session of 108 interest. 110 The figure below shows an example of a signalling path through 111 multiple networks. 113 +------------------+ +------------------+ 114 | COUNTRY A | | COUNTRY B | 115 | Operator A | | Operator A | 116 | | | | 117 | SIP Phones | | SIP Phones | 118 | | //| | 119 +------------------+ // +------------------+ 120 | // 121 | // 122 ,'```', // +------------------+ 123 .`',.' `..'``',<==// | COUNTRY B | 124 ,' Operator A `', | Operator A | 125 ; Backbone Network ..'-------| | 126 ', ,., .'` | PSTN phones | 127 '.,.`'.,,,.` `''` | | 128 || +------------------+ 129 || 130 \/ 131 +------------------+ 132 | | 133 | Transit Network | 134 | | 135 | |\\ 136 +------------------+ \\ 137 | \\ 138 | \\ 139 +------------------+ \\ +------------------+ 140 | COUNTRY D | \\ | COUNTRY C | 141 | Operator C | \\=>| Operator B | 142 | | | | 143 | SIP Phones | | SIP Phones | 144 | | | | 145 +------------------+ +------------------+ 147 Figure 1: Example signalling path through multiple networks 149 4. Skeleton Diagnostic Procedure 151 The skeleton diagnostic procedure is as follows: 153 o The user's terminal is placed in debug mode. The terminal logs 154 its own signalling and inserts a log me marker into SIP requests 155 for session setup 157 o All SIP entities that the signalling traverses, from the first 158 proxy the terminal connects to at the edge of the network to the 159 destination client terminal, can detect that the log me marker is 160 present and can log SIP requests and responses that contain the 161 marker if configured to do so. 163 o Subsequent responses and requests in the same dialog are logged. 165 o Logging stops, either because the dialog has ended or because a 166 'stop event', typically expiry of a certain amount of time, 167 occurred 169 o The user's terminal and any other SIP entity that has logged 170 signalling sends logs to a server that is co-ordinating 171 diagnostics. 173 5. Requirements for a Log Me Marker 175 o REQ1: It shall be possible to mark a SIP request or response as of 176 interest for logging by inserting a log me marker. This is known 177 as log-me marking. 179 o REQ2: It shall be possible for a log-me marker to cross network 180 boundaries. 182 o REQ3: A log-me marker is most effective if it passes end-to-end. 183 However, source networks should behave responsibly and not leave 184 it to a downstream network to detect and remove a marker that it 185 will not use. A log-me marker should be removed at trust domain 186 boundaries. 188 o REQ4: SIP entities should log SIP requests or responses with a 189 log-me marker. 191 o REQ5: If a UA receives a request with a log-me marker, it shall 192 echo that log-me marker in responses to that request. 194 o REQ6: A SIP proxy may perform log-me marking of requests and 195 responses. Typical cases where a proxy needs to perform log-me 196 marking are when a UA has not marked a request and when responses 197 received on a dialog of interest for logging do not contain a log- 198 me marker. In these cases, the entity that performs log-me 199 marking is stateful inasmuch as it must remember when a dialog is 200 of interest for logging. 202 o REQ7: For SIP proxies, logging of SIP requests that contain a log- 203 me marker may be stateless. For example, it is not required for a 204 SIP entity to maintain state of which SIP requests contained a 205 log-me marker in order to log responses to those requests. 206 Echoing a log-me marker in responses is the responsibility of the 207 UA that receives a request. 209 o REQ8: A log-me marker may include an identifier that indicates the 210 test case that caused it to be inserted, known as a test case 211 identifier. The test case identifier does not have any impact on 212 session setup, it is used by the diagnostic server to collate all 213 logged SIP requests and responses to the initial SIP request in a 214 dialog or standalone transaction. The Session-ID described in I-D 215 .ietf-insipid-session-id-reqts [I-D.ietf-insipid-session-id-reqts] 216 could be used as the test case identifier but it would be useful 217 for the UA to log a human readable name together with this 218 Session-ID when it performs log me marking of an initial SIP 219 request. 221 6. Security Considerations 223 All drafts are required to have a security considerations section. 224 See RFC 3552 [RFC3552] for a guide. 226 6.1. Trust Domain 228 Since a log me marker may cause a SIP entity to log the SIP header 229 and body of a request or response, the log me marker should be 230 removed at a trust domain boundary. If a prior agreement to log 231 sessions exists with the net hop network then the log me marker might 232 not be removed. 234 6.2. Security Threats 236 6.2.1. Log-me marking 238 The log me marker is not sensitive information, although it will 239 sometimes be inserted because a particular device is experiencing 240 problems. 242 The presence of a log me marker will cause some SIP entities to log 243 signalling. Therefore, this marker must be removed at the earliest 244 opportunity if it has been incorrectly inserted. 246 Activating a debug mode affects the operation of a terminal, 247 therefore it must be supplied by an authorized server to an 248 authorized terminal, it must not be altered in transit, and it must 249 not be readable by an unauthorized third party. 251 Logged signalling is privacy-sensitive data, therefore it must be 252 passed to an authorized server, it must not be altered in transit, 253 and it must not be readable by an unauthorized third party. 255 6.2.2. Sending logged information 257 A SIP entity that has logged information should encrypt it, such that 258 it can be decrypted only by the debug server, before sending it to a 259 debug server in order to protect the content of logs from a third 260 party. 262 7. References 264 7.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 7.2. Informative References 271 [I-D.ietf-insipid-session-id-reqts] 272 Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 273 Kaplan, "Requirements for an End-to-End Session 274 Identification in IP-Based Multimedia Communication 275 Networks", draft-ietf-insipid-session-id-reqts-07 (work in 276 progress), June 2013. 278 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 279 Specifications: ABNF", RFC 2234, November 1997. 281 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 282 June 1999. 284 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 285 A., Peterson, J., Sparks, R., Handley, M., and E. 286 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 287 June 2002. 289 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 290 UPDATE Method", RFC 3311, October 2002. 292 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 293 and D. Gurle, "Session Initiation Protocol (SIP) Extension 294 for Instant Messaging", RFC 3428, December 2002. 296 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 297 Text on Security Considerations", BCP 72, RFC 3552, July 298 2003. 300 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 301 for Event State Publication", RFC 3903, October 2004. 303 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 304 Initiation Protocol (SIP) INFO Method and Package 305 Framework", RFC 6086, January 2011. 307 Appendix A. Additional Stuff 309 This becomes an Appendix. 311 Author's Address 313 Peter Dawes 314 Vodafone Group 315 The Connection 316 Newbury, Berkshire RG14 2FN 317 UK 319 Phone: +44 7717 275009 320 Email: peter.dawes@vodafone.com