idnits 2.17.1 draft-ietf-sipclf-problem-statement-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 24, 2012) is 4141 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: 'RFC3986' is defined on line 1564, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCLF V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Standards Track E. Burger, Ed. 5 Expires: June 27, 2013 Georgetown University 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 December 24, 2012 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): 14 Framework and Information Model 15 draft-ietf-sipclf-problem-statement-12 17 Abstract 19 Well-known web servers such as Apache and web proxies like Squid 20 support event logging using a common log format. The logs produced 21 using these de-facto standard formats are invaluable to system 22 administrators for trouble-shooting a server and tool writers to 23 craft tools that mine the log files and produce reports and trends. 24 Furthermore, these log files can also be used to train anomaly 25 detection systems and feed events into a security event management 26 system. The Session Initiation Protocol (SIP) does not have a common 27 log format, and as a result, each server supports a distinct log 28 format that makes it unnecessarily complex to produce tools to do 29 trend analysis and security detection. This document describes a 30 framework, including requirements and analysis of existing 31 approaches, and specifies an information model for development of a 32 SIP common log file format that can be used uniformly by user agents, 33 proxies, registrars, redirect servers as well as back-to-back user 34 agents. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 27, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 73 4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 6 74 5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 6 75 5.1. SIP CLF and Call Detail Records . . . . . . . . . . . . . 7 76 5.2. SIP CLF and packet capture tools . . . . . . . . . . . . . 7 77 5.3. SIP CLF and syslog . . . . . . . . . . . . . . . . . . . . 8 78 5.4. SIP CLF and IPFIX . . . . . . . . . . . . . . . . . . . . 9 79 6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 9 80 7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 11 81 8. Information model . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 12 83 8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 14 84 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 16 86 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 17 87 9.3. Single downstream branch call . . . . . . . . . . . . . . 19 88 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 24 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 90 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 34 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 92 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 94 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 95 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 98 1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 RFC 3261 [RFC3261] defines additional terms used in this document 105 that are specific to the SIP domain such as "proxy"; "registrar"; 106 "redirect server"; "user agent server" or "UAS"; "user agent client" 107 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 108 "transaction"; "server transaction". 110 This document uses the term "SIP Server" that is defined to include 111 the following SIP entities: user agent server, registrar, redirect 112 server, a SIP proxy in the role of user agent server, and a B2BUA in 113 the role of a user agent server. 115 2. Introduction 117 Servers executing on Internet hosts produce log records as part of 118 their normal operations. Some log records are, in essence, a summary 119 of an application layer protocol data unit (PDU), that captures in 120 precise terms an event that was processed by the server. These log 121 records serve many purposes, including analysis and troubleshooting. 123 Well-known web servers such as Apache and Squid support event logging 124 using a Common Log Format (CLF), the common structure for logging 125 requests and responses serviced by the web server. It can be argued 126 that a good part of the success of Apache has been its CLF because it 127 allowed third parties to produce tools that analyzed the data and 128 generated traffic reports and trends. The Apache CLF has been so 129 successful that not only did it become the de-facto standard in 130 producing logging data for web servers, but also many commercial web 131 servers can be configured to produce logs in this format. An example 132 of Apache CLF is depicted next: 134 %h %l %u %t \"%r\" %s %b 135 remotehost rfc931 authuser [date] request status bytes 137 remotehost: Remote hostname (or IP number if DNS hostname is not 138 available, or if DNSLookup is Off. 140 rfc931: The remote logname of the user. 142 authuser: The username by which the user has authenticated himself. 144 [date]: Date and time of the request. 146 request: The request line exactly as it came from the client. 148 status: The HTTP status code returned to the client. 150 bytes: The content-length of the document transferred. 152 The inspiration for the SIP CLF is the Apache CLF. However, the 153 state machinery for a HTTP transaction is much simpler than that of 154 the SIP transaction (as evidenced in Section 7). The SIP CLF needs 155 to do considerably more. 157 This document outlines the problem statement that argues for a SIP 158 CLF. In addition, it provides an information model pertaining to the 159 minimum set of SIP headers and fields that must be logged. This 160 document does not prescribe a specific representation format for the 161 SIP CLF record and instead, allows other documents to define a 162 representation format. [I-D.ietf-sipclf-format] is an example of a 163 representation format that provides an UTF-8 based logging scheme. 165 3. Problem statement 167 The Session Initiation Protocol (SIP) [RFC3261] is an Internet 168 multimedia session signaling protocol. A typical deployment of SIP 169 in an enterprise will consist of SIP entities from multiple vendors. 170 Each SIP entity produces logs using a proprietary format. The result 171 of multiplicity of the log file formats is the inability of the 172 support staff to easily trace a call from one entity to another, or 173 even to craft common tools that will perform trend analysis, 174 debugging and troubleshooting problems uniformly across the SIP 175 entities from multiple vendors. 177 Furthermore, the log file must be easily accessible by command line 178 tools for simple text processing. This allows ad-hoc queries against 179 the elements in the log file to retrieve a log record. Furthermore, 180 the log file must be in a format that allows for rapid searches of a 181 particular log record (or records). Because of the large number of 182 records expected in the log file, the records must be in a format 183 that allows for rapid scanning and ease of skipping records that do 184 not match a search criteria. Finally, the generation of the log file 185 must not impose undue burden on the SIP implementation in the form of 186 additional libraries that may not be uniformly available on different 187 platforms and operating environments where a SIP entity generating a 188 log file record may be found. 190 SIP does not currently have a common log format and this document 191 serves to provide the rationale to establish a SIP CLF and identifies 192 the required minimal information that must appear in any SIP CLF 193 record. 195 4. What SIP CLF is and what it is not 197 The SIP CLF is a standardized manner of producing a log file. This 198 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 199 The SIP CLF is simply an easily digestible log of currently occurring 200 events and past transactions. It contains enough information to 201 allow humans and automata to derive relationships between discrete 202 transactions handled at a SIP entity or to search for a certain 203 dialog or a related set of transactions. 205 The SIP CLF is amenable to quick parsing (i.e., well-delimited 206 fields) and it is platform and operating system neutral. 208 Due to the structure imposed by delimited fields, the SIP CLF is 209 amenable to easy parsing and lends itself well to creating other 210 innovative tools such as logfile parsers and trend analytic engines. 212 The SIP CLF is not a billing tool. It is not expected that 213 enterprises will bill customers based on SIP CLF. The SIP CLF 214 records events at the signaling layer only and does not attempt to 215 correlate the veracity of these events with the media layer. Thus, 216 it cannot be used to trigger customer billing. 218 The SIP CLF is not a quality of service (QoS) measurement tool. If 219 QoS is defined as measuring the mean opinion score (MOS) of the 220 received media, then SIP CLF does not aid in this task since it does 221 not summarize events at the media layer. 223 And finally, the SIP CLF is not a tool for supporting lawful 224 intercept. 226 5. Alternative approaches to SIP CLF 228 The working group discussed four alternative approaches to determine 229 whether they fill the requirements of what is desired of a SIP CLF 230 outlined in Section 3. We conclude that while every scheme discussed 231 below comes with its advantages, its disadvantages may preclude it 232 from being used as a SIP CLF. However, we stress that the 233 information model contained in this document can be used to develop 234 alternative representation formats when desired. Currently, 235 [I-D.ietf-sipclf-format] is an example of a representation format 236 that provides an UTF-8 based logging scheme that meets all the 237 requirements of Section 3. 239 5.1. SIP CLF and Call Detail Records 241 Call Detail Records (CDRs) are used in operator networks widely and 242 with the adoption of SIP, standardization bodies such as 3GPP have 243 subsequently defined SIP-related CDRs as well. Today, CDRs are used 244 to implement the functionality approximated by SIP CLF, however, 245 there are important differences. 247 One, SIP CLF operates natively at the transaction layer and maintains 248 enough information in the information elements being logged that 249 dialog-related data can be subsequently derived from the transaction 250 logs. Thus, esoteric SIP fields and parameters like the To header, 251 including tags; the From header, including tags, the CSeq number, 252 etc. are logged in SIP CLF. By contrast, a CDR is used mostly for 253 charging and thus saves information to facilitate that very aspect. 254 A CDR will most certainly log the public user identification of a 255 party requesting a service (which may not correspond to the From 256 header) and the public user identification of the party called party 257 (which may not correspond to the To header.) Furthermore, the 258 sequence numbers maintained by the CDR may not correspond to the SIP 259 CSeq header. Thus it will be hard to piece together the state of a 260 dialog through a sequence of CDR records. 262 Two, a CDR record will, in all probability, be generated at a SIP 263 entity performing some form of proxy-like functionality of a B2BUA 264 providing some service. By contrast, SIP CLF is light- weight enough 265 that it can be generated by a canonical SIP user agent server and 266 user agent client as well, including those that execute on resource 267 constrained devices (mobile phones). 269 Finally, SIP is also being deployed outside of operator- managed VoIP 270 networks. Universities, research laboratories, and small-to-medium 271 size companies are deploying SIP-based VoIP solutions on networks 272 owned and managed by them. Much of the latter constituencies will 273 not have an interest in generating CDRs, but they will like to have a 274 concise representation of the messages being handled by the SIP 275 entities in a common format. 277 5.2. SIP CLF and packet capture tools 279 Wireshark and tcpdump are popular raw packet capture tools. 280 Wireshark even contains filters that can understand SIP at the 281 protocol level and break down a captured message into its individual 282 header components. While packet capture tools are appropriate to 283 capture and view discrete SIP messages, they do not suffice to serve 284 in the same capacity as SIP CLF for the following reasons: 286 o Using packet capturing tools will not eliminate the need for 287 agreeing to a common set of fields to represent a SIP CLF record. 288 This common understanding is important for interoperability to 289 allow one implementation to read a log file written by a different 290 implementation. 291 o The packet capture from these tools is not easily searchable by 292 simple command line tools for text processing. 293 o Using packet capture tools require that the underlying libraries 294 related to packet capture be available for all platforms on which 295 a SIP server or a SIP client can execute on. Given the different 296 platforms that a SIP client or server runs on --- mobile, fixed 297 host, tablet, etc. --- this may become an inhibiting factor when 298 compared to the SIP client or server producing a SIP CLF record 299 natively (the SIP client or server has already parsed the SIP 300 message for operation on it, therefore, it seems reasonable to 301 have it write the parsed tokens out to persistent store in an 302 agreed upon format). 303 o If SIP messages are exchanged over a secure transport (TLS), 304 packet capture tools will be unable to decrypt them and render 305 them as individual SIP headers. 306 o Using such tools and related packet capture libraries may imposes 307 a dependency on a third party library. 309 5.3. SIP CLF and syslog 311 The syslog protocol [RFC5424] conveys event notification messages 312 from an originator to a collector. While syslog protocol provides a 313 packet format and transport mechanism, it does not describe any 314 storage format for syslog messages. Pragmatically, while the syslog 315 protocol itself does not describe a storage format, the collector 316 will write the arriving messages into a disk file. A new problem 317 arises due to the general nature of syslog: the disk file will 318 contain log messages from many originators, not just SIP entities. 319 This imposes an additional burden of discarding all extraneous 320 records when analyzing the disk file for SIP CLF records of interest. 321 SIP CLF records are best stored in a log file that is easily 322 searchable by command line tools. 324 Other drawbacks of using syslog include the unavailability of the 325 collector under certain scenarios (a mobile SIP phone may be unable 326 to find a collector to which it should send the messages), and the 327 need to have syslog-specific libraries available for each platform 328 that the SIP server or the SIP client can execute on. And finally, 329 because of the frequency and size of SIP log messages, it is not 330 desirable to send every SIP CLF log message to the collector. 331 Instead, a judicious use of syslog could be that only certain events 332 -- those that are pertinent from a network situational awareness 333 perspective, or those that include a periodic statistical summary of 334 the messages processed -- are sent to the collector. 336 5.4. SIP CLF and IPFIX 338 The IPFIX protcol [RFC5101] allows network administrators to 339 aggregate IP packets characterized by some commonality (similar 340 packet header fields, one or more characteristics of the packet 341 itself) into a flow that can be subsequently collected and sent to 342 other elements for analysis and monitoring. However, IPFIX is not a 343 logging format and does not produce a log file that can be examined 344 by ad-hoc text processing tools. 346 6. Motivation and use cases 348 As SIP becomes pervasive in multiple business domains and ubiquitous 349 in academic and research environments, it is beneficial to establish 350 a CLF for the following reasons: 352 Common reference for interpreting events: In a laboratory 353 environment or an enterprise service offering there will typically 354 be SIP entities from multiple vendors participating in routing 355 requests. Absent a common log format, each entity will produce 356 output records in a native format making it hard to establish 357 commonality for tools that operate on the log file. 359 Writing common tools: A common log format allows independent tool 360 providers to craft tools and applications that interpret the CLF 361 data to produce insightful trend analysis and detailed traffic 362 reports. The format should be such that it retains the ability to 363 be read by humans and processed using traditional Unix text 364 processing tools. 366 Session correlation across diverse processing elements: In 367 operational SIP networks, a request will typically be processed by 368 more than one SIP server. A SIP CLF will allow the network 369 operator to trace the progression of the request (or a set of 370 requests) as they traverse through the different servers to 371 establish a concise diagnostic trail of a SIP session. 373 Note that tracing the request through a set of servers is 374 considerably less challenging if all the servers belong to the 375 same administrative domain. 377 Message correlation across transactions: A SIP CLF can enable a 378 quick lookup of all messages that comprise a transaction (e.g., 379 "Find all messages corresponding to server transaction X, 380 including all forked branches.") 382 Message correlation across dialogs: A SIP CLF can correlate 383 transactions that comprise a dialog (e.g., "Find all messages for 384 dialog created by Call-ID C, From tag F and To tag T.") 386 Trend analysis: A SIP CLF allows an administrator to collect data 387 and spot patterns or trends in the information (e.g., "What is the 388 domain where the most sessions are routed to between 9:00 AM and 389 1:00 PM?") 391 Train anomaly detection systems: A SIP CLF will allow for the 392 training of anomaly detection systems that once trained can 393 monitor the CLF file to trigger an alarm on the subsequent 394 deviations from accepted patterns in the data set. Currently, 395 anomaly detection systems monitor the network and parse raw 396 packets that comprise a SIP message -- a process that is 397 unsuitable for anomaly detection systems [rieck2008]. With all 398 the necessary event data at their disposal, network operations 399 managers and information technology operation managers are in a 400 much better position to correlate, aggregate, and prioritize log 401 data to maintain situational awareness. 403 Testing: A SIP CLF allows for automatic testing of SIP equipment by 404 writing tools that can parse a SIP CLF file to ensure behavior of 405 a device under test. 407 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 408 SIP entity (e.g., "How long did it take to generate a final 409 response for the INVITE associated with Call-ID X?") 411 Offline analysis: A SIP CLF allows for offline analysis of the data 412 gathered. Once a SIP CLF file has been generated, it can be 413 transported (subject to the security considerations in Section 10) 414 to a host with appropriate computing resources to perform 415 subsequent analysis. 417 Real-time monitoring: A SIP CLF allows administrators to visually 418 notice the events occurring at a SIP entity in real-time providing 419 accurate situational awareness. 421 7. Challenges in establishing a SIP CLF 423 Establishing a CLF for SIP is a challenging task. The behavior of a 424 SIP entity is more complex when compared to the equivalent HTTP 425 entity. 427 Base protocol services such as parallel or serial forking elicit 428 multiple final responses. Ensuing delays between sending a request 429 and receiving a final response all add complexity when considering 430 what fields should comprise a CLF and in what manner. Furthermore, 431 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 432 and these transactions may arrive at a varying inter-arrival rate at 433 a proxy. For example, the BYE transaction usually arrives much after 434 the corresponding INVITE transaction was received, serviced and 435 expunged from the transaction list. Nonetheless, it is advantageous 436 to relate these transactions such that automata or a human monitoring 437 the log file can construct a set consisting of related transactions. 439 ACK requests in SIP need careful consideration as well. In SIP, an 440 ACK is a special method that is associated with an INVITE only. It 441 does not require a response, and furthermore, if it is acknowledging 442 a non-2xx response, then the ACK is considered part of the original 443 INVITE transaction. If it is acknowledging a 2xx-class response, 444 then the ACK is a separate transaction consisting of a request only 445 (i.e., there is not a response for an ACK request.) CANCEL is 446 another method that is tied to an INVITE transaction, but unlike ACK, 447 the CANCEL request elicits a final response. 449 While most requests elicit a response immediately, the INVITE request 450 in SIP can remain in a pending state at a proxy as it forks branches 451 downstream or at a user agent server while it alerts the user. 452 [RFC3261] instructs the server transaction to send a 1xx-class 453 provisional response if a final response is delayed for more than 200 454 ms. A SIP CLF log file needs to include such provisional responses 455 because they help train automata associated with anomaly detection 456 systems and provide some positive feedback for a human observer 457 monitoring the log file. 459 Finally, beyond supporting native SIP actors such as proxies, 460 registrars, redirect servers, and user agent servers (UAS), it is 461 beneficial to derive a common log format that supports back-to-back 462 user agent (B2BUA) behavior, which may vary considerably depending on 463 the specific nature of the B2BUA. 465 8. Information model 467 This document defines the mandatory fields that MUST occur in a SIP 468 CLF record. The maximum size (in number of bytes) for a SIP CLF 469 field is 4096 bytes. This limit is the same regardless of whether 470 the SIP CLF field is a meta-field (see "Timestamp" and 471 "Directionality" defined below) or a normal SIP header. If the body 472 of the SIP message is to be logged, it MUST conform to this limit as 473 well. 475 SIP bodies may contain characters that do not form a valid UTF-8 476 sequence. As such, logging bodies requires understanding tradeoffs 477 with respect to a specific logging format to determine if the body 478 can be logged as-is or some encoding will be required. The specific 479 syntax and semantics used to log SIP bodies MUST be defined by the 480 specific representation format document used to generate the SIP CLF 481 record. 483 The information model supports extensibility by providing the 484 capability to log "optional fields". Optional fields are those SIP 485 header fields (or field components) that are not mandatory (see 486 Section 8.1 for the mandatory field list). Optional fields may 487 contain SIP headers or other elements present in a SIP message (for 488 example, the Reason- Phrase element from the Status-Line production 489 rule in RFC 3261 [RFC3261]). Optional fields may also contain 490 additional information that a particular vendor desires to log. The 491 specific syntax and semantics to be accorded to optional fields MUST 492 be defined by the specific representation format used to generate the 493 SIP CLF record. 495 8.1. SIP CLF mandatory fields 497 The following SIP CLF fields are defined as minimal information that 498 MUST appear in any SIP CLF record: 500 Timestamp - Date and time of the request or response represented as 501 the number of seconds and milliseconds since the Unix epoch. 503 Message type - An indicator on whether the SIP message is a request 504 or a response. The allowable values for this field are 'R' (for 505 Request) and 'r' (for response). 507 Directionality - An indicator on whether the SIP message is received 508 by the SIP entity or sent by the SIP entity. The allowable values 509 for this field are 's' (for message sent) and 'r' (for message 510 received). 512 Transport - The transport over which a SIP message is sent or 513 received. The allowable values for the transport are governed by 514 the "transport" production rule in Section 25.1 of RFC3261 515 [RFC3261]. 517 Source-address - The IPv4 or IPv6 address of the sender of the SIP 518 message. 520 Source-port - The source port number of the sender of the SIP 521 message. 523 Destination-address - The IPv4 or IPv6 address of the recipient of 524 the SIP message. 526 Destination-port - The port number of the recipient of the SIP 527 message. 529 From - The From URI. For the sake of brevity, URI parameters should 530 not be logged. 532 From-tag - The tag parameter of the From header. 534 To - The To URI. For the sake of brevity, URI parameters should not 535 be logged. 537 To-tag - The tag parameter of the To header. Note that the tag 538 parameter will be absent in the initial request that forms a 539 dialog. 541 Callid - The Call-ID. 543 CSeq-Method - The method from the CSeq header. 545 CSeq-Number - The number from the CSeq header. 547 R-URI - The Request-URI, including any URI parameters. 549 Status - The SIP response status code. 551 SIP Proxies may fork, creating several client transactions that 552 correlate to a single server transaction. Responses arriving on 553 these client transactions, or new requests (CANCEL, ACK) sent on the 554 client transaction need log file entries that correlate with a server 555 transaction. Similarly, a B2BUA may create one or more client 556 transactions in response to an incoming request. These transactions 557 will require correlation as well. The last two information model 558 elements provide this correlation. 560 Server-Txn - Server transaction identification code - the 561 transaction identifier associated with the server transaction. 562 Implementations can reuse the server transaction identifier (the 563 topmost branch-id of the incoming request, with or without the 564 magic cookie), or they could generate a unique identification 565 string for a server transaction (this identifier needs to be 566 locally unique to the server only.) This identifier is used to 567 correlate ACKs and CANCELs to an INVITE transaction; it is also 568 used to aid in forking as explained later in this section. (See 569 Section 9 for usage.) 571 Client-Txn - Client transaction identification code - this field is 572 used to associate client transactions with a server transaction 573 for forking proxies or B2BUAs. Upon forking, implementations can 574 reuse the value they inserted into the topmost Via header's branch 575 parameter, or they can generate a unique identification string for 576 the client transaction. (See Section 9 for usage.) 578 This information model applies to all SIP entities --- a UAC, UAS, 579 Proxy, a B2BUA, registrar and redirect server. The SIP CLF fields 580 prescribed for a proxy are equally applicable to the B2BUA. 581 Similarly, the SIP CLF fields prescribed for a UAS are equally 582 applicable to registrars and redirect servers. 584 The next section specifies the individual SIP CLF information model 585 elements that form a log record for specific instance of a SIP 586 entity. It is understood that a SIP CLF record is extensible using 587 extension mechanisms appropriate to the specific representation used 588 to generate the SIP CLF record. This document, however, does not 589 prescribe a specific representation format and it limits the 590 discussion to the mandatory data elements described above. 592 8.2. Mandatory fields and SIP entities 594 Each SIP CLF record must contain all the mandatory information model 595 elements outlined in Section 8.1. This document does not specify a 596 representation of a logging format; it is expected that other 597 documents will do so. 599 An element will not always have an appropriate value to provide for 600 one of these fields, even when the field is required to appear in the 601 SIP CLF record. Therefore, the representation document MUST define 602 how to indicate a field is "not applicable". For example, the R-URI 603 field is not applicable when logging a response, the Status field is 604 not applicable when logging a request, the To-tag is not known when a 605 request is first sent out, etc. 607 The Client-Txn field is always applicable to a UAC. The Server- Txn 608 field does not apply to a UAC unless the element is also acting as a 609 UAS, and the message associated to this log record corresponds to a 610 message handled by that UAS. For instance, a proxy forwarding a 611 request will populate both the Client-Txn and Server-Txn fields in 612 the record corresponding to the forwarded request. 614 The Server-Txn field is always applicable to a UAS. The Client-Txn 615 field does not apply to a UAS unless the element is also acting as a 616 UAC, and the message associated to this log record corresponds to a 617 message handled by that UAC. For instance, a proxy forwarding a 618 response will populate both the Server-Txn and Client-Txn fields in 619 the record corresponding to the forwarded response. However, a proxy 620 would only populate the Client-Txn field when creating a log record 621 corresponding to a request. 623 9. Examples 625 The examples use only the mandatory data elements defined in 626 Section 8.1. Extension elements are not considered and neither are 627 SIP bodies. When a given mandatory field is not applicable to a SIP 628 entity, we use the horizontal dash ("-") to represent it. 630 There are five principals in the examples below. They are Alice, the 631 initiator of requests. Alice's user agent uses IPv4 address 632 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 633 on their way to Bob, the recipient of the requests. P1 also acts as 634 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 635 5060. Bob has two instances of his user agent running on different 636 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 637 5060 and the second instance uses an IPv6 address of 2001:db8::9, 638 port 5060. P2 is a proxy responsible for Bob's domain. Table 1 639 summarizes these addresses. 641 +-------------------+--------------------+-------------------+ 642 | Principal | IP:port | Host/Domain name | 643 +-------------------+--------------------+-------------------+ 644 | Alice | 198.51.100.1:5060 | alice.example.com | 645 | P1 | 198.51.100.10:5060 | p1.example.com | 646 | P2 | 203.0.113.200:5060 | p2.example.net | 647 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 648 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 649 +-------------------+--------------------+-------------------+ 651 Principal to IP address asignment 653 Table 1 655 Illustrative examples of SIP CLF follow. 657 9.1. UAC registration 659 Alice sends a registration registrar P1 and receives a 2xx-class 660 response. The register requests causes Alice's UAC to produce a log 661 record shown below. 663 Timestamp: 1275930743.699 664 Message Type: R 665 Directionality: s 666 Transport: udp 667 CSeq-Number: 1 668 CSeq-Method: REGISTER 669 R-URI: sip:example.com 670 Destination-address: 198.51.100.10 671 Destination-port: 5060 672 Source-address: 198.51.100.1 673 Source-port: 5060 674 To: sip:example.com 675 To-tag: - 676 From: sip:alice@example.com 677 From-tag: 76yhh 678 Call-ID: f81-d4-f6@example.com 679 Status: - 680 Server-Txn: - 681 Client-Txn: c-tr-1 683 After some time, Alice's UAC will receive a response from the 684 registrar. The response causes Alice's agent to produce a log record 685 shown below. 687 Timestamp: 1275930744.100 688 Message Type: r 689 Directionality: r 690 Transport: udp 691 CSeq-Number: 1 692 CSeq-Method: REGISTER 693 R-URI: - 694 Destination-address: 198.51.100.1 695 Destination-port: 5060 696 Source-address: 198.51.100.10 697 Source-port: 5060 698 To: sip:example.com 699 To-tag: reg-1-xtr 700 From: sip:alice@example.com 701 From-tag: 76yhh 702 Call-ID: f81-d4-f6@example.com 703 Status: 100 704 Server-Txn: - 705 Client-Txn: c-tr-1 707 9.2. Direct call between Alice and Bob 709 In this example, Alice sends a session initiation request directly to 710 Bob's agent (instance 1.) Bob's agent accepts the session 711 invitation. We first present the SIP CLF logging from the vantage 712 point of Alice's UAC. In line 1, Alice's user agent sends out the 713 INVITE. Shortly, it receives a "180 Ringing" (line 2), followed by a 714 "200 OK" response (line 3). Upon the receipt of the 2xx-class 715 response, Alice's user agent sends out an ACK request (line 4). 717 Timestamp: 1275930743.699 718 Message Type: R 719 Directionality: s 720 Transport: udp 721 CSeq-Number: 32 722 CSeq-Method: INVITE 723 R-URI: sip:bob@bob1.example.net 724 Destination-address: 203.0.113.1 725 Destination-port: 5060 726 Source-address: 198.51.100.1 727 Source-port: 5060 728 To: sip:bob@bob1.example.net 729 To-tag: - 730 From: sip:alice@example.com 731 From-tag: 76yhh 732 Call-ID: f82-d4-f7@example.com 733 Status: - 734 Server-Txn: - 735 Client-Txn: c-1-xt6 737 Timestamp: 1275930745.002 738 Message Type: r 739 Directionality: r 740 Transport: udp 741 CSeq-Number: 32 742 CSeq-Method: INVITE 743 R-URI: - 744 Destination-address: 198.51.100.1 745 Destination-port: 5060 746 Source-address: 203.0.113.1 747 Source-port: 5060 748 To: sip:bob@example.net 749 To-tag: b-in6-iu 750 From: sip:alice@example.com 751 From-tag: 76yhh 752 Call-ID: f82-d4-f7@example.com 753 Status: 180 754 Server-Txn: - 755 Client-Txn: c-1-xt6 757 Timestamp: 1275930746.100 758 Message Type: r 759 Directionality: r 760 Transport: udp 761 CSeq-Number: 32 762 CSeq-Method: INVITE 763 R-URI: - 764 Destination-address: 198.51.100.1 765 Destination-port: 5060 766 Source-address: 203.0.113.1 767 Source-port: 5060 768 To: sip:bob@example.net 769 To-tag: b-in6-iu 770 From: sip:alice@example.com 771 From-tag: 76yhh 772 Call-ID: f82-d4-f7@example.com 773 Status: 200 774 Server-Txn: - 775 Client-Txn: c-1-xt6 777 Timestamp: 1275930746.120 778 Message Type: R 779 Directionality: s 780 Transport: udp 781 CSeq-Number: 32 782 CSeq-Method: ACK 783 R-URI: sip:bob@bob1.example.net 784 Destination-address: 203.0.113.1 785 Destination-port: 5060 786 Source-address: 198.51.100.1 787 Source-port: 5060 788 To: sip:bob@example.net 789 To-tag: b-in6-iu 790 From: sip:alice@example.com 791 From-tag: 76yhh 792 Call-ID: f82-d4-f7@example.com 793 Status: - 794 Server-Txn: - 795 Client-Txn: c-1-xt6 797 9.3. Single downstream branch call 799 In this example, Alice sends a session invitation request to Bob 800 through proxy P1, which inserts a Record-Route header causing 801 subsequent requests between Alice and Bob to traverse the proxy. The 802 SIP CLF log records appears from the vantage point of P1. The line 803 numbers below refer to Figure 1 805 Alice P1 Bob 806 +---INV--------->| | Line 1 807 | | | 808 |<---------100---+ | Line 2 809 | | | 810 | +---INV-------->| Line 3 811 | | | 812 | |<--------100---+ Line 4 813 | | | 814 | |<--------180---+ Line 5 815 | | | 816 |<---------180---+ | Line 6 817 | | | 818 | |<--------200---+ Line 7 819 | | | 820 |<---------200---+ | Line 8 821 | | | 822 +---ACK--------->| | Line 9 823 | | | 824 | |---ACK-------->| Line 10 826 Figure 1: Simple proxy-aided call flow 828 1 Timestamp: 1275930743.699 829 Message Type: R 830 Directionality: r 831 Transport: udp 832 CSeq-Number: 43 833 CSeq-Method: INVITE 834 R-URI: sip:bob@example.net 835 Destination-address: 198.51.100.10 836 Destination-port: 5060 837 Source-address: 198.51.100.1 838 Source-port: 5060 839 To: sip:bob@example.net 840 To-tag: - 841 From: sip:alice@example.com 842 From-tag: al-1 843 Call-ID: tr-87h@example.com 844 Status: - 845 Server-Txn: s-x-tr 846 Client-Txn: - 848 Note that at this point P1 has created a server transaction 849 identification code and populated the SIP CLF field Server-Txn with 850 it. P1 has not yet created a client transaction identification code, 851 thus Client-Txn contains a "-". 853 2 Timestamp: 1275930744.001 854 Message Type: r 855 Directionality: s 856 Transport: udp 857 CSeq-Number: 43 858 CSeq-Method: INVITE 859 R-URI: - 860 Destination-address: 198.51.100.1 861 Destination-port: 5060 862 Source-address: 198.51.100.10 863 Source-port: 5060 864 To: sip:bob@example.net 865 To-tag: - 866 From: sip:alice@example.com 867 From-tag: al-1 868 Call-ID: tr-87h@example.com 869 Status: 100 870 Server-Txn: s-x-tr 871 Client-Txn: - 873 In line 3 below, P1 has created a client transaction identification 874 code for the downstream branch and populated the SIP CLF field 875 Client-Txn. 877 3 Timestamp: 1275930744.998 878 Message Type: R 879 Directionality: s 880 Transport: udp 881 CSeq-Number: 43 882 CSeq-Method: INVITE 883 R-URI: sip:bob@bob1.example.net 884 Destination-address: 203.0.113.1 885 Destination-port: 5060 886 Source-address: 198.51.100.10 887 Source-port: 5060 888 To: sip:bob@example.net 889 To-tag: - 890 From: sip:alice@example.com 891 From-tag: al-1 892 Call-ID: tr-87h@example.com 893 Status: - 894 Server-Txn: s-x-tr 895 Client-Txn: c-x-tr 897 4 Timestamp: 1275930745.200 898 Message Type: r 899 Directionality: r 900 Transport: udp 901 CSeq-Number: 43 902 CSeq-Method: INVITE 903 R-URI: - 904 Destination-address: 198.51.100.10 905 Destination-port: 5060 906 Source-address: 203.0.113.1 907 Source-port: 5060 908 To: sip:bob@example.net 909 To-tag: b1-1 910 From: sip:alice@example.com 911 From-tag: al-1 912 Call-ID: tr-87h@example.com 913 Status: 100 914 Server-Txn: s-x-tr 915 Client-Txn: c-x-tr 917 5 Timestamp: 1275930745.800 918 Message Type: r 919 Directionality: r 920 Transport: udp 921 CSeq-Number: 43 922 CSeq-Method: INVITE 923 R-URI: - 924 Destination-address: 198.51.100.10 925 Destination-port: 5060 926 Source-address: 203.0.113.1 927 Source-port: 5060 928 To: sip:bob@example.net 929 To-tag: b1-1 930 From: sip:alice@example.com 931 From-tag: al-1 932 Call-ID: tr-87h@example.com 933 Status: 180 934 Server-Txn: s-x-tr 935 Client-Txn: c-x-tr 937 6 Timestamp: 1275930746.009 938 Message Type: r 939 Directionality: s 940 Transport: udp 941 CSeq-Number: 43 942 CSeq-Method: INVITE 943 R-URI: - 944 Destination-address: 198.51.100.1 945 Destination-port: 5060 946 Source-address: 198.51.100.10 947 Source-port: 5060 948 To: sip:bob@example.net 949 To-tag: b1-1 950 From: sip:alice@example.com 951 From-tag: al-1 952 Call-ID: tr-87h@example.com 953 Status: 180 954 Server-Txn: s-x-tr 955 Client-Txn: c-x-tr 957 7 Timestamp: 1275930747.120 958 Message Type: r 959 Directionality: r 960 Transport: udp 961 CSeq-Number: 43 962 CSeq-Method: INVITE 963 R-URI: - 964 Destination-address: 198.51.100.10 965 Destination-port: 5060 966 Source-address: 203.0.113.1 967 Source-port: 5060 968 To: sip:bob@example.net 969 To-tag: b1-1 970 From: sip:alice@example.com 971 From-tag: al-1 972 Call-ID: tr-87h@example.com 973 Status: 200 974 Server-Txn: s-x-tr 975 Client-Txn: c-x-tr 977 8 Timestamp: 1275930747.300 978 Message Type: r 979 Directionality: s 980 Transport: udp 981 CSeq-Number: 43 982 CSeq-Method: INVITE 983 R-URI: - 984 Destination-address: 198.51.100.1 985 Destination-port: 5060 986 Source-address: 198.51.100.10 987 Source-port: 5060 988 To: sip:bob@example.net 989 To-tag: b1-1 990 From: sip:alice@example.com 991 From-tag: al-1 992 Call-ID: tr-87h@example.com 993 Status: 200 994 Server-Txn: s-x-tr 995 Client-Txn: c-x-tr 997 9 Timestamp: 1275930749.100 998 Message Type: R 999 Directionality: r 1000 Transport: udp 1001 CSeq-Number: 43 1002 CSeq-Method: ACK 1003 R-URI: sip:bob@example.net 1004 Destination-address: 198.51.100.10 1005 Destination-port: 5060 1006 Source-address: 198.51.100.1 1007 Source-port: 5060 1008 To: sip:bob@example.net 1009 To-tag: b1-1 1010 From: sip:alice@example.com 1011 From-tag: al-1 1012 Call-ID: tr-87h@example.com 1013 Status: - 1014 Server-Txn: s-x-tr 1015 Client-Txn: c-x-tr 1017 10 Timestamp: 1275930749.100 1018 Message Type: R 1019 Directionality: s 1020 Transport: udp 1021 CSeq-Number: 43 1022 CSeq-Method: ACK 1023 R-URI: sip:bob@bob1.example.net 1024 Destination-address: 203.0.113.1 1025 Destination-port: 5060 1026 Source-address: 198.51.100.10 1027 Source-port: 5060 1028 To: sip:bob@example.net 1029 To-tag: b1-1 1030 From: sip:alice@example.com 1031 From-tag: al-1 1032 Call-ID: tr-87h@example.com 1033 Status: - 1034 Server-Txn: s-x-tr 1035 Client-Txn: c-x-tr 1037 9.4. Forked call 1039 In this example, Alice sends a session invitation to Bob's proxy, P2. 1040 P2 forks the session invitation request to two registered endpoints 1041 corresponding to Bob's address-of-record. Both endpoints respond 1042 with provisional responses. Shortly thereafter, one of Bob's user 1043 agent instances accepts the call, causing P2 to send a CANCEL request 1044 to the second user agent. P2 does not Record-Route, therefore the 1045 subsequent ACK request from Alice to Bob's user agent does not 1046 traverse through P2 (and is not shown below.) 1048 Figure 2 depicts the call flow. 1050 Bob Bob 1051 Alice P2 (Instance 1) (Instance 2) 1052 +---INV--->| | | Line 1 1053 | | | | 1054 |<---100---+ | | Line 2 1055 | | | | 1056 | +---INV--->| | Line 3 1057 | | | | 1058 | +---INV----+-------->| Line 4 1059 | | | | 1060 | |<---100---+ | Line 5 1061 | | | | 1062 | |<---------+---100---+ Line 6 1063 | | | | 1064 | |<---180---+---------+ Line 7 1065 | | | | 1066 |<---180---+ | | Line 8 1067 | | | | 1068 | |<---180---+ | Line 9 1069 | | | | 1070 |<---180---+ | | Line 10 1071 | | | | 1072 | |<---200---+ | Line 11 1073 | | | | 1074 |<---200---+ | | Line 12 1075 | | | | 1076 | +---CANCEL-+-------->| Line 13 1077 | | | | 1078 | |<---------+---487---+ Line 14 1079 | | | | 1080 | +---ACK----+-------->| Line 15 1081 | | | | 1082 | |<---------+---200---+ Line 16 1084 Figure 2: Forked call flow 1086 The SIP CLF log appears from the vantage point of P2. The fields 1087 logged are shown below; the line numbers refer to Figure 2. 1089 1 Timestamp: 1275930743.699 1090 Message Type: R 1091 Directionality: r 1092 Transport: udp 1093 CSeq-Number: 43 1094 CSeq-Method: INVITE 1095 R-URI: sip:bob@example.net 1096 Destination-address: 203.0.113.200 1097 Destination-port: 5060 1098 Source-address: 198.51.100.1 1099 Source-port: 5060 1100 To: sip:bob@example.net 1101 To-tag: - 1102 From: sip:alice@example.com 1103 From-tag: a1-1 1104 Call-ID: tr-88h@example.com 1105 Status: - 1106 Server-Txn: s-1-tr 1107 Client-Txn: - 1109 2 Timestamp: 1275930744.001 1110 Message Type: r 1111 Directionality: s 1112 Transport: udp 1113 CSeq-Number: 43 1114 CSeq-Method: INVITE 1115 R-URI: - 1116 Destination-address: 198.51.100.1 1117 Destination-port: 5060 1118 Source-address: 203.0.113.200 1119 Source-port: 5060 1120 To: sip:bob@example.net 1121 To-tag: - 1122 From: sip:alice@example.com 1123 From-tag: a1-1 1124 Call-ID: tr-88h@example.com 1125 Status: 100 1126 Server-Txn: s-1-tr 1127 Client-Txn: - 1129 3 Timestamp: 1275930744.998 1130 Message Type: R 1131 Directionality: s 1132 Transport: udp 1133 CSeq-Number: 43 1134 CSeq-Method: INVITE 1135 R-URI: sip:bob@bob1.example.net 1136 Destination-address: 203.0.113.1 1137 Destination-port: 5060 1138 Source-address: 203.0.113.200 1139 Source-port: 5060 1140 To: sip:bob@example.net 1141 To-tag: - 1142 From: sip:alice@example.com 1143 From-tag: a1-1 1144 Call-ID: tr-88h@example.com 1145 Status: - 1146 Server-Txn: s-1-tr 1147 Client-Txn: c-1-tr 1149 4 Timestamp: 1275930745.500 1150 Message Type: R 1151 Directionality: s 1152 Transport: udp 1153 CSeq-Number: 43 1154 CSeq-Method: INVITE 1155 R-URI: sip:bob@bob2.example.net 1156 Destination-address: [2001:db8::9] 1157 Destination-port: 5060 1158 Source-address: 203.0.113.200 1159 Source-port: 5060 1160 To: sip:bob@example.net 1161 To-tag: - 1162 From: sip:alice@example.com 1163 From-tag: a1-1 1164 Call-ID: tr-88h@example.com 1165 Status: - 1166 Server-Txn: s-1-tr 1167 Client-Txn: c-2-tr 1169 5 Timestamp: 1275930745.800 1170 Message Type: r 1171 Directionality: r 1172 Transport: udp 1173 CSeq-Number: 43 1174 CSeq-Method: INVITE 1175 R-URI: - 1176 Destination-address: 203.0.113.200 1177 Destination-port: 5060 1178 Source-address: 203.0.113.1 1179 Source-port: 5060 1180 To: sip:bob@example.net 1181 To-tag: b1=-1 1182 From: sip:alice@example.com 1183 From-tag: a1-1 1184 Call-ID: tr-88h@example.com 100 1185 Status: 100 1186 Server-Txn: s-1-tr 1187 Client-Txn: c-1-tr 1189 6 Timestamp: 1275930746.100 1190 Message Type: r 1191 Directionality: r 1192 Transport: udp 1193 CSeq-Number: 43 1194 CSeq-Method: INVITE 1195 R-URI: - 1196 Destination-address: 203.0.113.200 1197 Destination-port: udp 1198 Source-address: [2001:db8::9] 1199 Source-port: 5060 1200 To: sip:bob@example.net 1201 To-tag: b2-2 1202 From: sip:alice@example.com 1203 From-tag: a1-1 1204 Call-ID: tr-88h@example.com 1205 Status: 100 1206 Server-Txn: s-1-tr 1207 Client-Txn: c-2-tr 1209 7 Timestamp: 1275930746.700 1210 Message Type: r 1211 Directionality: r 1212 Transport: udp 1213 CSeq-Number: 43 1214 CSeq-Method: INVITE 1215 R-URI: - 1216 Destination-address: 203.0.113.200 1217 Destination-port: udp 1218 Source-address: [2001:db8::9] 1219 Source-port: 5060 1220 To: sip:bob@example.net 1221 To-tag: b2-2 1222 From: sip:alice@example.com 1223 From-tag: a1-1 1224 Call-ID: tr-88h@example.com 1225 Status: 180 1226 Server-Txn: s-1-tr 1227 Client-Txn: c-2-tr 1229 8 Timestamp: 1275930746.990 1230 Message Type: r 1231 Directionality: s 1232 Transport: udp 1233 CSeq-Number: 43 1234 CSeq-Method: INVITE 1235 R-URI: - 1236 Destination-address: 198.51.100.1 1237 Destination-port: 5060 1238 Source-address: 203.0.113.200 1239 Source-port: 5060 1240 To: sip:bob@example.net 1241 To-tag: b2-2 1242 From: sip:alice@example.com 1243 From-tag: a1-1 1244 Call-ID: tr-88h@example.com 1245 Status: 180 1246 Server-Txn: s-1-tr 1247 Client-Txn: c-2-tr 1249 9 Timestamp: 1275930747.100 1250 Message Type: r 1251 Directionality: r 1252 Transport: udp 1253 CSeq-Number: 43 1254 CSeq-Method: INVITE 1255 R-URI: - 1256 Destination-address: 203.0.113.200 1257 Destination-port: 5060 1258 Source-address: 203.0.113.1 1259 Source-port: 5060 1260 To: sip:bob@example.net 1261 To-tag: b1-1 1262 From: sip:alice@example.com 1263 From-tag: a1-1 1264 Call-ID: tr-88h@example.com 100 1265 Status: 180 1266 Server-Txn: s-1-tr 1267 Client-Txn: c-1-tr 1269 10 Timestamp: 1275930747.300 1270 Message Type: r 1271 Directionality: s 1272 Transport: udp 1273 CSeq-Number: 43 1274 CSeq-Method: INVITE 1275 R-URI: - 1276 Destination-address: 198.51.100.1 1277 Destination-port: 5060 1278 Source-address: 203.0.113.200 1279 Source-port: 5060 1280 To: sip:bob@example.net 1281 To-tag: b1-1 1282 From: sip:alice@example.com 1283 From-tag: a1-1 1284 Call-ID: tr-88h@example.com 1285 Status: 180 1286 Server-Txn: s-1-tr 1287 Client-Txn: c-2-tr 1289 11 Timestamp: 1275930747.800 1290 Message Type: r 1291 Directionality: r 1292 Transport: udp 1293 CSeq-Number: 43 1294 CSeq-Method: INVITE 1295 R-URI: - 1296 Destination-address: 203.0.113.200 1297 Destination-port: 5060 1298 Source-address: 203.0.113.1 1299 Source-port: 5060 1300 To: sip:bob@example.net 1301 To-tag: b1-1 1302 From: sip:alice@example.com 1303 From-tag: a1-1 1304 Call-ID: tr-88h@example.com 100 1305 Status: 200 1306 Server-Txn: s-1-tr 1307 Client-Txn: c-1-tr 1309 12 Timestamp: 1275930748.000 1310 Message Type: r 1311 Directionality: s 1312 Transport: udp 1313 CSeq-Number: 43 1314 CSeq-Method: INVITE 1315 R-URI: - 1316 Destination-address: 198.51.100.1 1317 Destination-port: 5060 1318 Source-address: 203.0.113.200 1319 Source-port: 5060 1320 To: sip:bob@example.net 1321 To-tag: b1-1 1322 From: sip:alice@example.com 1323 From-tag: a1-1 1324 Call-ID: tr-88h@example.com 1325 Status: 200 1326 Server-Txn: s-1-tr 1327 Client-Txn: c-1-tr 1329 13 Timestamp: 1275930748.201 1330 Message Type: R 1331 Directionality: s 1332 Transport: udp 1333 CSeq-Number: 43 1334 CSeq-Method: CANCEL 1335 R-URI: sip:bob@bob2.example.net 1336 Destination-address: [2001:db8::9] 1337 Destination-port: 5060 1338 Source-address: 203.0.113.200 1339 Source-port: 5060 1340 To: sip:bob@example.net 1341 To-tag: b2-2 1342 From: sip:alice@example.com 1343 From-tag: a1-1 1344 Call-ID: tr-88h@example.com 1345 Status: - 1346 Server-Txn: s-1-tr 1347 Client-Txn: c-2-tr 1349 14 Timestamp: 1275930748.300 1350 Message Type: r 1351 Directionality: r 1352 Transport: udp 1353 CSeq-Number: 43 1354 CSeq-Method: INVITE 1355 R-URI: - 1356 Destination-address: 203.0.113.200 1357 Destination-port: udp 1358 Source-address: [2001:db8::9] 1359 Source-port: 5060 1360 To: sip:bob@example.net 1361 To-tag: b2-2 1362 From: sip:alice@example.com 1363 From-tag: a1-1 1364 Call-ID: tr-88h@example.com 1365 Status: 487 1366 Server-Txn: s-1-tr 1367 Client-Txn: c-2-tr 1369 15 Timestamp: 1275930748.355 1370 Message Type: R 1371 Directionality: s 1372 Transport: udp 1373 CSeq-Number: 43 1374 CSeq-Method: ACK 1375 R-URI: sip:bob@bob2.example.net 1376 Destination-address: [2001:db8::9] 1377 Destination-port: 5060 1378 Source-address: 203.0.113.200 1379 Source-port: 5060 1380 To: sip:bob@example.net 1381 To-tag: b2-2 1382 From: sip:alice@example.com 1383 From-tag: a1-1 1384 Call-ID: tr-88h@example.com 1385 Status: - 1386 Server-Txn: s-1-tr 1387 Client-Txn: c-2-tr 1389 16 Timestamp: 1275930748.698 1390 Message Type: r 1391 Directionality: r 1392 Transport: udp 1393 CSeq-Number: 43 1394 CSeq-Method: CANCEL 1395 R-URI: - 1396 Destination-address: 203.0.113.200 1397 Destination-port: udp 1398 Source-address: [2001:db8::9] 1399 Source-port: 5060 1400 To: sip:bob@example.net 1401 To-tag: b2-2 1402 From: sip:alice@example.com 1403 From-tag: a1-1 1404 Call-ID: tr-88h@example.com 1405 Status: 200 1406 Server-Txn: s-1-tr 1407 Client-Txn: c-2-tr 1409 The above SIP CLF log makes it easy to search for a specific 1410 transaction or a state of the session. Searching for the string 1411 "c-1-tr" on the log records will readily yield the information that 1412 an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 1413 followed by a 180 and then a 200. Because the ACK request in this 1414 case would be exchanged end-to-end, this element does not see (and 1415 therefore will not log) the ACK. 1417 Searching on "c-2-tr" yields a more complex scenario of sending an 1418 INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, 1419 the log makes it apparent that the request to 1420 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 1421 response was generated, and that the pending INVITE returned a 487. 1422 The ACK to the final non-2xx response and a 200 to the CANCEL request 1423 complete the exchange on that branch. 1425 10. Security Considerations 1427 A log file by its nature reveals both the state of the entity 1428 producing it and the nature of the information being logged. To the 1429 extent that this state should not be publicly accessible and that the 1430 information is to be considered private, appropriate file and 1431 directory permissions attached to the log file SHOULD be used. It is 1432 outside the scope of this document to specify how to protect the log 1433 file while it is stored on disk, however, certain precautions can be 1434 taken. Operators SHOULD consider using common administrative 1435 features such as disk encryption and securing log files [schneier-1]. 1436 Operators SHOULD also consider hardening the machine on which the log 1437 file is stored by restricting physical access to the host as well as 1438 restricting access to the file itself. Depending on the specific 1439 operating system and environment, the file and directory permissions 1440 SHOULD be set to be most restrictive such that the file is not 1441 publicly readable and writable and the directory where the file is 1442 stored is not publicly accessible. 1444 The following threats may be considered for the log file while it is 1445 stored: 1447 o An attacker may gain access to view the log file, or may 1448 surreptitiously make a copy of the log file for later viewing. 1449 o An attacker who is unable to eavesdrop real-time SIP traffic on 1450 the network but nonetheless can access the log file, is able to 1451 easily mount replay attack or other attacks that result from 1452 channel eavesdropping. Encrypting SIP traffic does not help here 1453 because the SIP entity generating the log file would have 1454 decrypted the message for processing and subsequent logging. 1455 o An attacker may delete parts of --- or indeed, the whole --- file. 1457 Public access to the SIP log file creates more of a privacy leak when 1458 compared to an adversary eavesdropping cleartext SIP traffic on the 1459 network. If all SIP traffic on a network segment is encrypted, then 1460 as noted above, special attention must be directed to the file and 1461 directory permissions associated with the log file to preserve 1462 privacy such that only a privileged user can access the contents of 1463 the log file. 1465 Transporting SIP CLF files across the network pose special challenges 1466 as well. The following threats may be considered for transferring 1467 log files or while transferring individual log records: 1469 o An attacker may view the records; 1470 o An attacker may modify the records in transit or insert previously 1471 captured records into the stream; 1472 o An attacker may remove records in transit, or may stage a man- in- 1473 the-middle attack to deliver a partially or entirely falsified log 1474 file. 1476 It is also outside the scope of this document to specify protection 1477 methods for log files or log records that are being transferred 1478 between hosts, however, certain precautions can be taken. Operators 1479 SHOULD require mutual authentication, channel confidentiality and 1480 channel integrity while transferring the log file. The use of a 1481 secure shell transport layer protocol [RFC4253] or TLS [RFC5246] 1482 accomplishes this. 1484 Even with such care, sensitive information can be leaked during or 1485 after the transfer. SIP CLF fields like IP addresses and URIs 1486 contain potentially sensitive information. Before transferring the 1487 log file across domains, operators SHOULD ensure that any fields that 1488 contain sensitive information are appropriately anonymized or 1489 obfuscated. A specification for a format that describes which fields 1490 are obfuscated and with what characteristics (e.g., what correlations 1491 still work) is needed to allow interoperable but privacy-friendly 1492 exchange of SIP CLF between administrative domains. Such a 1493 specification is not attempted here, but is for further study. 1495 The SIP CLF represents the minimum fields that lend themselves to 1496 trend analysis and serve as information that may be deemed useful. 1497 Other formats can be defined that include more headers (and the body) 1498 from Section 8.1. However, where to draw a judicial line regarding 1499 the inclusion of non-mandatory headers can be challenging. Clearly, 1500 the more information a SIP entity logs, the longer time the logging 1501 process will take, the more disk space the log entry will consume, 1502 and the more potentially sensitive information could be breached. 1503 Therefore, adequate tradeoffs should be taken in account when logging 1504 more fields than the ones recommended in Section 8.1. 1506 Implementers need to pay particular attention to buffer handling when 1507 reading or writing log files. SIP CLF entries can be unbounded in 1508 length. It would be reasonable for a full dump of a SIP message to 1509 be thousands of octets long. This is of particular importance to CLF 1510 log parsers, as a SIP CLF log writers may add one or more extension 1511 fields to the message to be logged. 1513 11. Operational guidance 1515 SIP CLF log files will take up substantial amount of disk space 1516 depending on traffic volume at a processing entity and the amount of 1517 information being logged. As such, any organization using SIP CLF 1518 should establish operational procedures for file rollovers and 1519 periodic retrieval of logs before rollover as appropriate to the 1520 needs of the organization. 1522 Listing such operational guidelines in this document is out of scope 1523 for this work. 1525 12. IANA Considerations 1527 This document does not require any considerations from IANA. 1529 13. Acknowledgments 1531 Members of the sipping, dispatch, ipfix and syslog working groups 1532 provided invaluable input to the formulation of the draft. These 1533 include Benoit Claise, Spencer Dawkins, John Elwell, David 1534 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1535 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon 1536 Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, 1537 Dale Worley, Theo Zourzouvillys and others that we have undoubtedly, 1538 but inadvertently, missed. 1540 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1541 Salgueiro helped tremendously in discussions related to arriving at 1542 the beginnings of an information model. 1544 14. References 1546 14.1. Normative References 1548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1549 Requirement Levels", BCP 14, RFC 2119, March 1997. 1551 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1552 A., Peterson, J., Sparks, R., Handley, M., and E. 1553 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1554 June 2002. 1556 14.2. Informative References 1558 [I-D.ietf-sipclf-format] 1559 Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1560 Session Initiation Protocol (SIP) Common Log Format 1561 (CLF)", draft-ietf-sipclf-format-11 (work in progress), 1562 December 2012. 1564 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1565 Resource Identifier (URI): Generic Syntax", STD 66, 1566 RFC 3986, January 2005. 1568 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1569 Transport Layer Protocol", RFC 4253, January 2006. 1571 [RFC5101] Claise, B., "Specification of the IP Flow Information 1572 Export (IPFIX) Protocol for the Exchange of IP Traffic 1573 Flow Information", RFC 5101, January 2008. 1575 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1576 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1578 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1580 [rieck2008] 1581 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1582 Muller, "A Self-learning System for Detection of Anomalous 1583 SIP Messages", Principles, Systems and Applications of IP 1584 Telecommunications Services and Security for Next 1585 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1586 2008. 1588 [schneier-1] 1589 Schneier, B. and J. Kelsey, "Secure audit logs to support 1590 computer forensics", ACM Transactions on Information and 1591 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1593 Authors' Addresses 1595 Vijay K. Gurbani (editor) 1596 Bell Laboratories, Alcatel-Lucent 1597 1960 Lucent Lane 1598 Naperville, IL 60566 1599 USA 1601 Email: vkg@bell-labs.com 1603 Eric W. Burger (editor) 1604 Georgetown University 1605 USA 1607 Email: eburger@standardstrack.com 1608 URI: http://www.standardstrack.com 1609 Tricha Anjali 1610 Illinois Institute of Technology 1611 316 Siegel Hall 1612 Chicago, IL 60616 1613 USA 1615 Email: tricha@ece.iit.edu 1617 Humberto Abdelnur 1618 INRIA 1619 INRIA - Nancy Grant Est 1620 Campus Scientifique 1621 54506, Vandoeuvre-les-Nancy Cedex 1622 France 1624 Email: humbol@gmail.com 1626 Olivier Festor 1627 INRIA 1628 INRIA - Nancy Grant Est 1629 Campus Scientifique 1630 54506, Vandoeuvre-les-Nancy Cedex 1631 France 1633 Email: Olivier.Festor@loria.fr