idnits 2.17.1 draft-kaithal-sipclf-sip-log-information-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 7 has weird spacing: '...tension for ...' == Line 192 has weird spacing: '... where prox...' -- The document date (April 9, 2012) is 4399 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCLF Adarsh. Kaithal 3 Internet-Draft Sandeep. K S 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: October 11, 2012 April 9, 2012 7 Session Initiation Protocol (SIP) Extension for logging and debugging 8 draft-kaithal-sipclf-sip-log-information-00 10 Abstract 12 The current mechanisms to debug issues in SIP network are not very 13 efficient. It requires to enable debugging logs across different 14 devices, recreate the problem and then collect the logs. The idea is 15 to provide a solution to automatically enable relevant logs (SIP 16 messages and any other debugging logs meaningful to SIP devices), and 17 also to indicate where the logs are to be collected or stored. The 18 enabling of logs will happen at all the SIP devices(upstream or 19 downstream). This will help to get the logs from all the SIP devices 20 in a Common logging format (CLF). The solution extends SIP to 21 provide the infrastructure to enable logging for upstream and 22 downstream devices with each server deciding how much troubleshooting 23 information it wants to log - with freedom to simply ignore requests 24 if required. This document specifies a new header called "Log-Me" 25 Header in all the SIP messages. 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 October 11, 2012. 44 Copyright Notice 46 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 65 5. Log-me Header Field Definition and Syntax . . . . . . . . . . . 4 66 6. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Session Initiation Protocol (SIP) is gaining popularity in the VoIP 77 Network. Many deployments, currently, have deployed SIP for their 78 VoIP network. Because of the huge deployments, isolating the problem 79 in the network and troubleshooting it becomes very difficult. Also, 80 If the problem happens in high traffic condition, or happens 81 intermittently, collecting the right set of debugging logs is very 82 difficult for further fault analysis. 84 There is need for an effective troubleshooting mechanisms embedded in 85 the signalling so that logs from all the devices can be collected for 86 that particular call and stored in a common location for 87 troubleshooting. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. This 94 document only uses these key words when referencing normative 95 statements in existing RFCs." 97 3. Background 99 Troubleshooting in VOIP network is challenging as the signaling and 100 media follow different path and Different equipment. 102 Scenario 104 UA1----B2BUA1-----P1------P2-------B2BUA2------UA2 106 UA1 wishes to make a call to UA2, However, due to network Topology, 107 UA1 has to go via B2BUA1 ,Proxy 1 (P1) , Proxy2 (P2) and B2BUA2 to 108 reach UA2. Likewise, all requests between UA2 and UA1 must also 109 traverse through the same path. 111 UA1 makes a SIP call to UA2. This call has some issue. In order to 112 debug the issue, logs need to be enabled at all the SIP devices in 113 the network. It involves a lot of time and effort collect the logs 114 and troubleshoot it. 116 The "Log-Me" extension header field allows all the SIP devices 117 (upstream and downstream) to start collecting desired logs, store it 118 in to a common location and available for debugging. It may store 119 the data in Common Logging Format so that It can be fed to a device 120 which make the troubleshooting faster moreover the logs are in a 121 standard format and easier to troubleshoot. This header element's 122 function is to invoke tracing and troubleshooting functions at each 123 "hop" in the signaling path for the call. Additionally, it includes 124 a unique "tag" to allow the information to be associated with the 125 particular call for proper correlation.. 127 4. Applicability Statement 129 The Log-me mechanism is applicable to all the SIP entity in the 130 network which includes UAS,UAC, Proxy,B2BUA etc. 132 1) Each entity is free to simply ignore request , if it is not 133 interested in log collection, or busy with other activities.. 135 2) Each entity can add its own "Log-Me" header and provide the path 136 for the log collection.. 138 3) Each entity is free to log any information which is useful for 139 troubleshooting. 141 4) If an entity does not understand the header then it can simply 142 ignore it.However, it should not remove the header, as removing stops 143 the Possibility for logging at the next hop. 145 5) If SIP signalling is secure then logging MUST be secure. 147 6) If B2BUA gets a "Log-Me" header then it MUST NOT remove it. It 148 MAY modify or append "Log-Me" header. 150 5. Log-me Header Field Definition and Syntax 151 Log-Me = "Log-Me" HCOLON log-value *(COMMA log-value) 152 log-value = log-type 1*(SEMI log-params) 153 log-type = "mailto" / "http"/ "syslog" / "tftp" / 154 "ftp" /"sftp" / "local" / other-type 155 log-params = log-maddr /log-uri/ 156 log-username/log-password/log-tag 157 log-maddr= "maddr" EQUALS host 158 log-uri = "uri" EQUALS userinfo 159 userinfo = user "@" host 160 log-username = "username" EQUALS user 161 user = 1*( unreserved / escaped / user-unreserved ) 162 log-password= "password" EQUALS*( unreserved / 163 escaped / "=" / "+" / "$" / "," ) 164 log-tag = tag EQUALS token 165 other-type = token 167 Example : 168 Log-Me:mailto;uri=akaithal@cisco.com;tag=sdfrfgf43 169 Log-Me:syslog;maddr=9.45.45.34;username=akaithal; 170 password=addfere2;tag=sdfdsfe 171 Log-Me:local;tag=sdfdsfe 173 local means it should store the data locally. 175 Support for the Log-me header field MAY be indicated by a UA by 176 including the option-tag "log" in a Supported header field. 178 Log-me header field value MUST consist of exactly one log-type. If 179 the log-type is mailto then it should have a log-uri (i.e. an email 180 address). For any other log-type log-username.log-password and log- 181 maddr is MUST. One entity can put more than one Log-me header in 182 multiple line or separated by comma. In case there are more than one 183 Log-me header then it is the intermediate end point's decision to put 184 the log in all places mentioned, or choose any one of them. If log- 185 uri and log-username are present then user portion of log-uri and 186 log-username MUST be same. 188 This is an optional header and can be built only in a SIP request and 189 response. The header can also be inserted by any intermediate entity 190 in the network. 192 Header field where proxy ACK BYE CAN INV OPT REG 193 --------------------------------------------------------------- 194 Log-Me R o - o - o o o 195 1xx o - o - o o o 196 2xx o - o - o o o 197 3xx o - o - o o o 198 4xx o - o - o o o 199 5xx o - o - o o o 200 6xx o - o - o o o 202 SUB NOT REF INF UPD PRA 203 --------------------------------- 204 o o o - o - 205 o o o - o - 206 o o o - o - 207 o o o - o - 208 o o o - o - 209 o o o - o - 210 o o o - o - 212 If a SIP REFER message is sent to an endpoint and contains the 213 "Log-Me" header, not only is the REFER method itself traced, but any 214 call initiated via the REFER mechanism is also traced. If "Log-Me" 215 header is present in the request then entity should at least log SIP 216 messages and any other relevant information which is required for 217 debugging. 219 6. UAC Behaviour 221 If UAC supports this extension the it should add "log" tag in the 222 supported header in the request or response. In case UAC wants the 223 call to be logged then it MUST add a Log-me header with the details 224 to enable logging. 226 UAC receives response with the "Log-Me" header then it starts 227 collecting the data from that response on words till the end of the 228 call. It logs messages which is mandatory along with other logging 229 information which is essential for troubleshooting from that device 230 point of view. 232 7. UAS Behaviour 234 UAS receives request with the "Log-Me" header then it starts 235 collecting the data from that request on words till the end of the 236 call. It logs messages which is mandatory along with other logging 237 information which is essential for troubleshooting from that device 238 point of view. 240 If UAS supports this extension the it should add debug tag in the 241 supported header in the request or response. In case UAS wants the 242 call to be logged then it MUST add a "Log-Me" header with the details 243 in any of the responses to enable logging. 245 8. Proxy Behaviour 247 1) If proxy supports "log" extension and it gets "Log-Me" header in 248 any of the request or response then it SHOULD process it and collect 249 relevant logs. Additionally it can do one of the following 251 a) Forward the received "Log-Me" header as is. 253 b) Add additional "Log-Me" header with details. 255 c) Add its own "Log-Me" header and removing the received "Log-Me" 256 header. 258 The above action are applicable for the forked requests as well. 260 2) If proxy does not support "log" extension and it receives "Log-Me" 261 header then it MUST NOT remove it from the requests or responses. 263 9. Security Considerations 265 There are security consideration with this header as password is 266 exposed. 268 1) It is RECOMMENDED to have calls over TLS to send "Log-Me" header. 270 2) It is RECOMMENDED for Intermediate devices to remove "Log-Me" 271 header if the next hop is not TLS. Alternatively it MAY modify 272 "Log-Me" header local log type. 274 10. IANA Considerations 276 There is no IANA consideration for this draft. 278 11. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 Authors' Addresses 285 Adarsh Kaithal 286 Cisco Systems, Inc. 287 Cessna Business Park, 288 Kadabeesanahalli Village, Varthur Hobli, 289 Sarjapur-Marathahalli Outer Ring Road 290 Bangalore, Karnataka 560103 291 India 293 Email: akaithal@cisco.com 295 Sandeep K S 296 Cisco Systems, Inc. 297 Cessna Business Park, 298 Kadabeesanahalli Village, Varthur Hobli, 299 Sarjapur-Marathahalli Outer Ring Road 300 Bangalore, Karnataka 560103 301 India 303 Email: sandks@cisco.com