idnits 2.17.1 draft-ietf-sipclf-problem-statement-13.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 (January 3, 2013) is 4102 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 1567, 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: July 7, 2013 Georgetown University 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 January 3, 2013 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): 14 Framework and Information Model 15 draft-ietf-sipclf-problem-statement-13 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 July 7, 2013. 53 Copyright Notice 55 Copyright (c) 2013 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 may not always have an appropriate value to provide for 600 one of these fields, for example, the R-URI field is not applicable 601 when logging a response, the Status field is not applicable when 602 logging a request, the To-tag is not known when a request is first 603 sent out, etc. As all the mandatory fields are required to appear in 604 the SIP CLF record, the representation document MUST define how to 605 indicate a field that is not applicable in the context that the SIP 606 CLF record was generated. Similarly, to handle parsing errors in a 607 field, the representation document MUST define a means to indicate 608 that a field cannot be parsed. 610 The Client-Txn field is always applicable to a UAC. The Server- Txn 611 field does not apply to a UAC unless the element is also acting as a 612 UAS, and the message associated to this log record corresponds to a 613 message handled by that UAS. For instance, a proxy forwarding a 614 request will populate both the Client-Txn and Server-Txn fields in 615 the record corresponding to the forwarded request. 617 The Server-Txn field is always applicable to a UAS. The Client-Txn 618 field does not apply to a UAS unless the element is also acting as a 619 UAC, and the message associated to this log record corresponds to a 620 message handled by that UAC. For instance, a proxy forwarding a 621 response will populate both the Server-Txn and Client-Txn fields in 622 the record corresponding to the forwarded response. However, a proxy 623 would only populate the Client-Txn field when creating a log record 624 corresponding to a request. 626 9. Examples 628 The examples use only the mandatory data elements defined in 629 Section 8.1. Extension elements are not considered and neither are 630 SIP bodies. When a given mandatory field is not applicable to a SIP 631 entity, we use the horizontal dash ("-") to represent it. 633 There are five principals in the examples below. They are Alice, the 634 initiator of requests. Alice's user agent uses IPv4 address 635 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 636 on their way to Bob, the recipient of the requests. P1 also acts as 637 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 638 5060. Bob has two instances of his user agent running on different 639 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 640 5060 and the second instance uses an IPv6 address of 2001:db8::9, 641 port 5060. P2 is a proxy responsible for Bob's domain. Table 1 642 summarizes these addresses. 644 +-------------------+--------------------+-------------------+ 645 | Principal | IP:port | Host/Domain name | 646 +-------------------+--------------------+-------------------+ 647 | Alice | 198.51.100.1:5060 | alice.example.com | 648 | P1 | 198.51.100.10:5060 | p1.example.com | 649 | P2 | 203.0.113.200:5060 | p2.example.net | 650 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 651 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 652 +-------------------+--------------------+-------------------+ 654 Principal to IP address asignment 656 Table 1 658 Illustrative examples of SIP CLF follow. 660 9.1. UAC registration 662 Alice sends a registration registrar P1 and receives a 2xx-class 663 response. The register requests causes Alice's UAC to produce a log 664 record shown below. 666 Timestamp: 1275930743.699 667 Message Type: R 668 Directionality: s 669 Transport: udp 670 CSeq-Number: 1 671 CSeq-Method: REGISTER 672 R-URI: sip:example.com 673 Destination-address: 198.51.100.10 674 Destination-port: 5060 675 Source-address: 198.51.100.1 676 Source-port: 5060 677 To: sip:example.com 678 To-tag: - 679 From: sip:alice@example.com 680 From-tag: 76yhh 681 Call-ID: f81-d4-f6@example.com 682 Status: - 683 Server-Txn: - 684 Client-Txn: c-tr-1 686 After some time, Alice's UAC will receive a response from the 687 registrar. The response causes Alice's agent to produce a log record 688 shown below. 690 Timestamp: 1275930744.100 691 Message Type: r 692 Directionality: r 693 Transport: udp 694 CSeq-Number: 1 695 CSeq-Method: REGISTER 696 R-URI: - 697 Destination-address: 198.51.100.1 698 Destination-port: 5060 699 Source-address: 198.51.100.10 700 Source-port: 5060 701 To: sip:example.com 702 To-tag: reg-1-xtr 703 From: sip:alice@example.com 704 From-tag: 76yhh 705 Call-ID: f81-d4-f6@example.com 706 Status: 100 707 Server-Txn: - 708 Client-Txn: c-tr-1 710 9.2. Direct call between Alice and Bob 712 In this example, Alice sends a session initiation request directly to 713 Bob's agent (instance 1.) Bob's agent accepts the session 714 invitation. We first present the SIP CLF logging from the vantage 715 point of Alice's UAC. In line 1, Alice's user agent sends out the 716 INVITE. Shortly, it receives a "180 Ringing" (line 2), followed by a 717 "200 OK" response (line 3). Upon the receipt of the 2xx-class 718 response, Alice's user agent sends out an ACK request (line 4). 720 Timestamp: 1275930743.699 721 Message Type: R 722 Directionality: s 723 Transport: udp 724 CSeq-Number: 32 725 CSeq-Method: INVITE 726 R-URI: sip:bob@bob1.example.net 727 Destination-address: 203.0.113.1 728 Destination-port: 5060 729 Source-address: 198.51.100.1 730 Source-port: 5060 731 To: sip:bob@bob1.example.net 732 To-tag: - 733 From: sip:alice@example.com 734 From-tag: 76yhh 735 Call-ID: f82-d4-f7@example.com 736 Status: - 737 Server-Txn: - 738 Client-Txn: c-1-xt6 740 Timestamp: 1275930745.002 741 Message Type: r 742 Directionality: r 743 Transport: udp 744 CSeq-Number: 32 745 CSeq-Method: INVITE 746 R-URI: - 747 Destination-address: 198.51.100.1 748 Destination-port: 5060 749 Source-address: 203.0.113.1 750 Source-port: 5060 751 To: sip:bob@example.net 752 To-tag: b-in6-iu 753 From: sip:alice@example.com 754 From-tag: 76yhh 755 Call-ID: f82-d4-f7@example.com 756 Status: 180 757 Server-Txn: - 758 Client-Txn: c-1-xt6 760 Timestamp: 1275930746.100 761 Message Type: r 762 Directionality: r 763 Transport: udp 764 CSeq-Number: 32 765 CSeq-Method: INVITE 766 R-URI: - 767 Destination-address: 198.51.100.1 768 Destination-port: 5060 769 Source-address: 203.0.113.1 770 Source-port: 5060 771 To: sip:bob@example.net 772 To-tag: b-in6-iu 773 From: sip:alice@example.com 774 From-tag: 76yhh 775 Call-ID: f82-d4-f7@example.com 776 Status: 200 777 Server-Txn: - 778 Client-Txn: c-1-xt6 780 Timestamp: 1275930746.120 781 Message Type: R 782 Directionality: s 783 Transport: udp 784 CSeq-Number: 32 785 CSeq-Method: ACK 786 R-URI: sip:bob@bob1.example.net 787 Destination-address: 203.0.113.1 788 Destination-port: 5060 789 Source-address: 198.51.100.1 790 Source-port: 5060 791 To: sip:bob@example.net 792 To-tag: b-in6-iu 793 From: sip:alice@example.com 794 From-tag: 76yhh 795 Call-ID: f82-d4-f7@example.com 796 Status: - 797 Server-Txn: - 798 Client-Txn: c-1-xt6 800 9.3. Single downstream branch call 802 In this example, Alice sends a session invitation request to Bob 803 through proxy P1, which inserts a Record-Route header causing 804 subsequent requests between Alice and Bob to traverse the proxy. The 805 SIP CLF log records appears from the vantage point of P1. The line 806 numbers below refer to Figure 1 808 Alice P1 Bob 809 +---INV--------->| | Line 1 810 | | | 811 |<---------100---+ | Line 2 812 | | | 813 | +---INV-------->| Line 3 814 | | | 815 | |<--------100---+ Line 4 816 | | | 817 | |<--------180---+ Line 5 818 | | | 819 |<---------180---+ | Line 6 820 | | | 821 | |<--------200---+ Line 7 822 | | | 823 |<---------200---+ | Line 8 824 | | | 825 +---ACK--------->| | Line 9 826 | | | 827 | |---ACK-------->| Line 10 829 Figure 1: Simple proxy-aided call flow 831 1 Timestamp: 1275930743.699 832 Message Type: R 833 Directionality: r 834 Transport: udp 835 CSeq-Number: 43 836 CSeq-Method: INVITE 837 R-URI: sip:bob@example.net 838 Destination-address: 198.51.100.10 839 Destination-port: 5060 840 Source-address: 198.51.100.1 841 Source-port: 5060 842 To: sip:bob@example.net 843 To-tag: - 844 From: sip:alice@example.com 845 From-tag: al-1 846 Call-ID: tr-87h@example.com 847 Status: - 848 Server-Txn: s-x-tr 849 Client-Txn: - 851 Note that at this point P1 has created a server transaction 852 identification code and populated the SIP CLF field Server-Txn with 853 it. P1 has not yet created a client transaction identification code, 854 thus Client-Txn contains a "-". 856 2 Timestamp: 1275930744.001 857 Message Type: r 858 Directionality: s 859 Transport: udp 860 CSeq-Number: 43 861 CSeq-Method: INVITE 862 R-URI: - 863 Destination-address: 198.51.100.1 864 Destination-port: 5060 865 Source-address: 198.51.100.10 866 Source-port: 5060 867 To: sip:bob@example.net 868 To-tag: - 869 From: sip:alice@example.com 870 From-tag: al-1 871 Call-ID: tr-87h@example.com 872 Status: 100 873 Server-Txn: s-x-tr 874 Client-Txn: - 876 In line 3 below, P1 has created a client transaction identification 877 code for the downstream branch and populated the SIP CLF field 878 Client-Txn. 880 3 Timestamp: 1275930744.998 881 Message Type: R 882 Directionality: s 883 Transport: udp 884 CSeq-Number: 43 885 CSeq-Method: INVITE 886 R-URI: sip:bob@bob1.example.net 887 Destination-address: 203.0.113.1 888 Destination-port: 5060 889 Source-address: 198.51.100.10 890 Source-port: 5060 891 To: sip:bob@example.net 892 To-tag: - 893 From: sip:alice@example.com 894 From-tag: al-1 895 Call-ID: tr-87h@example.com 896 Status: - 897 Server-Txn: s-x-tr 898 Client-Txn: c-x-tr 900 4 Timestamp: 1275930745.200 901 Message Type: r 902 Directionality: r 903 Transport: udp 904 CSeq-Number: 43 905 CSeq-Method: INVITE 906 R-URI: - 907 Destination-address: 198.51.100.10 908 Destination-port: 5060 909 Source-address: 203.0.113.1 910 Source-port: 5060 911 To: sip:bob@example.net 912 To-tag: b1-1 913 From: sip:alice@example.com 914 From-tag: al-1 915 Call-ID: tr-87h@example.com 916 Status: 100 917 Server-Txn: s-x-tr 918 Client-Txn: c-x-tr 920 5 Timestamp: 1275930745.800 921 Message Type: r 922 Directionality: r 923 Transport: udp 924 CSeq-Number: 43 925 CSeq-Method: INVITE 926 R-URI: - 927 Destination-address: 198.51.100.10 928 Destination-port: 5060 929 Source-address: 203.0.113.1 930 Source-port: 5060 931 To: sip:bob@example.net 932 To-tag: b1-1 933 From: sip:alice@example.com 934 From-tag: al-1 935 Call-ID: tr-87h@example.com 936 Status: 180 937 Server-Txn: s-x-tr 938 Client-Txn: c-x-tr 940 6 Timestamp: 1275930746.009 941 Message Type: r 942 Directionality: s 943 Transport: udp 944 CSeq-Number: 43 945 CSeq-Method: INVITE 946 R-URI: - 947 Destination-address: 198.51.100.1 948 Destination-port: 5060 949 Source-address: 198.51.100.10 950 Source-port: 5060 951 To: sip:bob@example.net 952 To-tag: b1-1 953 From: sip:alice@example.com 954 From-tag: al-1 955 Call-ID: tr-87h@example.com 956 Status: 180 957 Server-Txn: s-x-tr 958 Client-Txn: c-x-tr 960 7 Timestamp: 1275930747.120 961 Message Type: r 962 Directionality: r 963 Transport: udp 964 CSeq-Number: 43 965 CSeq-Method: INVITE 966 R-URI: - 967 Destination-address: 198.51.100.10 968 Destination-port: 5060 969 Source-address: 203.0.113.1 970 Source-port: 5060 971 To: sip:bob@example.net 972 To-tag: b1-1 973 From: sip:alice@example.com 974 From-tag: al-1 975 Call-ID: tr-87h@example.com 976 Status: 200 977 Server-Txn: s-x-tr 978 Client-Txn: c-x-tr 980 8 Timestamp: 1275930747.300 981 Message Type: r 982 Directionality: s 983 Transport: udp 984 CSeq-Number: 43 985 CSeq-Method: INVITE 986 R-URI: - 987 Destination-address: 198.51.100.1 988 Destination-port: 5060 989 Source-address: 198.51.100.10 990 Source-port: 5060 991 To: sip:bob@example.net 992 To-tag: b1-1 993 From: sip:alice@example.com 994 From-tag: al-1 995 Call-ID: tr-87h@example.com 996 Status: 200 997 Server-Txn: s-x-tr 998 Client-Txn: c-x-tr 1000 9 Timestamp: 1275930749.100 1001 Message Type: R 1002 Directionality: r 1003 Transport: udp 1004 CSeq-Number: 43 1005 CSeq-Method: ACK 1006 R-URI: sip:bob@example.net 1007 Destination-address: 198.51.100.10 1008 Destination-port: 5060 1009 Source-address: 198.51.100.1 1010 Source-port: 5060 1011 To: sip:bob@example.net 1012 To-tag: b1-1 1013 From: sip:alice@example.com 1014 From-tag: al-1 1015 Call-ID: tr-87h@example.com 1016 Status: - 1017 Server-Txn: s-x-tr 1018 Client-Txn: c-x-tr 1020 10 Timestamp: 1275930749.100 1021 Message Type: R 1022 Directionality: s 1023 Transport: udp 1024 CSeq-Number: 43 1025 CSeq-Method: ACK 1026 R-URI: sip:bob@bob1.example.net 1027 Destination-address: 203.0.113.1 1028 Destination-port: 5060 1029 Source-address: 198.51.100.10 1030 Source-port: 5060 1031 To: sip:bob@example.net 1032 To-tag: b1-1 1033 From: sip:alice@example.com 1034 From-tag: al-1 1035 Call-ID: tr-87h@example.com 1036 Status: - 1037 Server-Txn: s-x-tr 1038 Client-Txn: c-x-tr 1040 9.4. Forked call 1042 In this example, Alice sends a session invitation to Bob's proxy, P2. 1043 P2 forks the session invitation request to two registered endpoints 1044 corresponding to Bob's address-of-record. Both endpoints respond 1045 with provisional responses. Shortly thereafter, one of Bob's user 1046 agent instances accepts the call, causing P2 to send a CANCEL request 1047 to the second user agent. P2 does not Record-Route, therefore the 1048 subsequent ACK request from Alice to Bob's user agent does not 1049 traverse through P2 (and is not shown below.) 1051 Figure 2 depicts the call flow. 1053 Bob Bob 1054 Alice P2 (Instance 1) (Instance 2) 1055 +---INV--->| | | Line 1 1056 | | | | 1057 |<---100---+ | | Line 2 1058 | | | | 1059 | +---INV--->| | Line 3 1060 | | | | 1061 | +---INV----+-------->| Line 4 1062 | | | | 1063 | |<---100---+ | Line 5 1064 | | | | 1065 | |<---------+---100---+ Line 6 1066 | | | | 1067 | |<---180---+---------+ Line 7 1068 | | | | 1069 |<---180---+ | | Line 8 1070 | | | | 1071 | |<---180---+ | Line 9 1072 | | | | 1073 |<---180---+ | | Line 10 1074 | | | | 1075 | |<---200---+ | Line 11 1076 | | | | 1077 |<---200---+ | | Line 12 1078 | | | | 1079 | +---CANCEL-+-------->| Line 13 1080 | | | | 1081 | |<---------+---487---+ Line 14 1082 | | | | 1083 | +---ACK----+-------->| Line 15 1084 | | | | 1085 | |<---------+---200---+ Line 16 1087 Figure 2: Forked call flow 1089 The SIP CLF log appears from the vantage point of P2. The fields 1090 logged are shown below; the line numbers refer to Figure 2. 1092 1 Timestamp: 1275930743.699 1093 Message Type: R 1094 Directionality: r 1095 Transport: udp 1096 CSeq-Number: 43 1097 CSeq-Method: INVITE 1098 R-URI: sip:bob@example.net 1099 Destination-address: 203.0.113.200 1100 Destination-port: 5060 1101 Source-address: 198.51.100.1 1102 Source-port: 5060 1103 To: sip:bob@example.net 1104 To-tag: - 1105 From: sip:alice@example.com 1106 From-tag: a1-1 1107 Call-ID: tr-88h@example.com 1108 Status: - 1109 Server-Txn: s-1-tr 1110 Client-Txn: - 1112 2 Timestamp: 1275930744.001 1113 Message Type: r 1114 Directionality: s 1115 Transport: udp 1116 CSeq-Number: 43 1117 CSeq-Method: INVITE 1118 R-URI: - 1119 Destination-address: 198.51.100.1 1120 Destination-port: 5060 1121 Source-address: 203.0.113.200 1122 Source-port: 5060 1123 To: sip:bob@example.net 1124 To-tag: - 1125 From: sip:alice@example.com 1126 From-tag: a1-1 1127 Call-ID: tr-88h@example.com 1128 Status: 100 1129 Server-Txn: s-1-tr 1130 Client-Txn: - 1132 3 Timestamp: 1275930744.998 1133 Message Type: R 1134 Directionality: s 1135 Transport: udp 1136 CSeq-Number: 43 1137 CSeq-Method: INVITE 1138 R-URI: sip:bob@bob1.example.net 1139 Destination-address: 203.0.113.1 1140 Destination-port: 5060 1141 Source-address: 203.0.113.200 1142 Source-port: 5060 1143 To: sip:bob@example.net 1144 To-tag: - 1145 From: sip:alice@example.com 1146 From-tag: a1-1 1147 Call-ID: tr-88h@example.com 1148 Status: - 1149 Server-Txn: s-1-tr 1150 Client-Txn: c-1-tr 1152 4 Timestamp: 1275930745.500 1153 Message Type: R 1154 Directionality: s 1155 Transport: udp 1156 CSeq-Number: 43 1157 CSeq-Method: INVITE 1158 R-URI: sip:bob@bob2.example.net 1159 Destination-address: [2001:db8::9] 1160 Destination-port: 5060 1161 Source-address: 203.0.113.200 1162 Source-port: 5060 1163 To: sip:bob@example.net 1164 To-tag: - 1165 From: sip:alice@example.com 1166 From-tag: a1-1 1167 Call-ID: tr-88h@example.com 1168 Status: - 1169 Server-Txn: s-1-tr 1170 Client-Txn: c-2-tr 1172 5 Timestamp: 1275930745.800 1173 Message Type: r 1174 Directionality: r 1175 Transport: udp 1176 CSeq-Number: 43 1177 CSeq-Method: INVITE 1178 R-URI: - 1179 Destination-address: 203.0.113.200 1180 Destination-port: 5060 1181 Source-address: 203.0.113.1 1182 Source-port: 5060 1183 To: sip:bob@example.net 1184 To-tag: b1=-1 1185 From: sip:alice@example.com 1186 From-tag: a1-1 1187 Call-ID: tr-88h@example.com 100 1188 Status: 100 1189 Server-Txn: s-1-tr 1190 Client-Txn: c-1-tr 1192 6 Timestamp: 1275930746.100 1193 Message Type: r 1194 Directionality: r 1195 Transport: udp 1196 CSeq-Number: 43 1197 CSeq-Method: INVITE 1198 R-URI: - 1199 Destination-address: 203.0.113.200 1200 Destination-port: udp 1201 Source-address: [2001:db8::9] 1202 Source-port: 5060 1203 To: sip:bob@example.net 1204 To-tag: b2-2 1205 From: sip:alice@example.com 1206 From-tag: a1-1 1207 Call-ID: tr-88h@example.com 1208 Status: 100 1209 Server-Txn: s-1-tr 1210 Client-Txn: c-2-tr 1212 7 Timestamp: 1275930746.700 1213 Message Type: r 1214 Directionality: r 1215 Transport: udp 1216 CSeq-Number: 43 1217 CSeq-Method: INVITE 1218 R-URI: - 1219 Destination-address: 203.0.113.200 1220 Destination-port: udp 1221 Source-address: [2001:db8::9] 1222 Source-port: 5060 1223 To: sip:bob@example.net 1224 To-tag: b2-2 1225 From: sip:alice@example.com 1226 From-tag: a1-1 1227 Call-ID: tr-88h@example.com 1228 Status: 180 1229 Server-Txn: s-1-tr 1230 Client-Txn: c-2-tr 1232 8 Timestamp: 1275930746.990 1233 Message Type: r 1234 Directionality: s 1235 Transport: udp 1236 CSeq-Number: 43 1237 CSeq-Method: INVITE 1238 R-URI: - 1239 Destination-address: 198.51.100.1 1240 Destination-port: 5060 1241 Source-address: 203.0.113.200 1242 Source-port: 5060 1243 To: sip:bob@example.net 1244 To-tag: b2-2 1245 From: sip:alice@example.com 1246 From-tag: a1-1 1247 Call-ID: tr-88h@example.com 1248 Status: 180 1249 Server-Txn: s-1-tr 1250 Client-Txn: c-2-tr 1252 9 Timestamp: 1275930747.100 1253 Message Type: r 1254 Directionality: r 1255 Transport: udp 1256 CSeq-Number: 43 1257 CSeq-Method: INVITE 1258 R-URI: - 1259 Destination-address: 203.0.113.200 1260 Destination-port: 5060 1261 Source-address: 203.0.113.1 1262 Source-port: 5060 1263 To: sip:bob@example.net 1264 To-tag: b1-1 1265 From: sip:alice@example.com 1266 From-tag: a1-1 1267 Call-ID: tr-88h@example.com 100 1268 Status: 180 1269 Server-Txn: s-1-tr 1270 Client-Txn: c-1-tr 1272 10 Timestamp: 1275930747.300 1273 Message Type: r 1274 Directionality: s 1275 Transport: udp 1276 CSeq-Number: 43 1277 CSeq-Method: INVITE 1278 R-URI: - 1279 Destination-address: 198.51.100.1 1280 Destination-port: 5060 1281 Source-address: 203.0.113.200 1282 Source-port: 5060 1283 To: sip:bob@example.net 1284 To-tag: b1-1 1285 From: sip:alice@example.com 1286 From-tag: a1-1 1287 Call-ID: tr-88h@example.com 1288 Status: 180 1289 Server-Txn: s-1-tr 1290 Client-Txn: c-2-tr 1292 11 Timestamp: 1275930747.800 1293 Message Type: r 1294 Directionality: r 1295 Transport: udp 1296 CSeq-Number: 43 1297 CSeq-Method: INVITE 1298 R-URI: - 1299 Destination-address: 203.0.113.200 1300 Destination-port: 5060 1301 Source-address: 203.0.113.1 1302 Source-port: 5060 1303 To: sip:bob@example.net 1304 To-tag: b1-1 1305 From: sip:alice@example.com 1306 From-tag: a1-1 1307 Call-ID: tr-88h@example.com 100 1308 Status: 200 1309 Server-Txn: s-1-tr 1310 Client-Txn: c-1-tr 1312 12 Timestamp: 1275930748.000 1313 Message Type: r 1314 Directionality: s 1315 Transport: udp 1316 CSeq-Number: 43 1317 CSeq-Method: INVITE 1318 R-URI: - 1319 Destination-address: 198.51.100.1 1320 Destination-port: 5060 1321 Source-address: 203.0.113.200 1322 Source-port: 5060 1323 To: sip:bob@example.net 1324 To-tag: b1-1 1325 From: sip:alice@example.com 1326 From-tag: a1-1 1327 Call-ID: tr-88h@example.com 1328 Status: 200 1329 Server-Txn: s-1-tr 1330 Client-Txn: c-1-tr 1332 13 Timestamp: 1275930748.201 1333 Message Type: R 1334 Directionality: s 1335 Transport: udp 1336 CSeq-Number: 43 1337 CSeq-Method: CANCEL 1338 R-URI: sip:bob@bob2.example.net 1339 Destination-address: [2001:db8::9] 1340 Destination-port: 5060 1341 Source-address: 203.0.113.200 1342 Source-port: 5060 1343 To: sip:bob@example.net 1344 To-tag: b2-2 1345 From: sip:alice@example.com 1346 From-tag: a1-1 1347 Call-ID: tr-88h@example.com 1348 Status: - 1349 Server-Txn: s-1-tr 1350 Client-Txn: c-2-tr 1352 14 Timestamp: 1275930748.300 1353 Message Type: r 1354 Directionality: r 1355 Transport: udp 1356 CSeq-Number: 43 1357 CSeq-Method: INVITE 1358 R-URI: - 1359 Destination-address: 203.0.113.200 1360 Destination-port: udp 1361 Source-address: [2001:db8::9] 1362 Source-port: 5060 1363 To: sip:bob@example.net 1364 To-tag: b2-2 1365 From: sip:alice@example.com 1366 From-tag: a1-1 1367 Call-ID: tr-88h@example.com 1368 Status: 487 1369 Server-Txn: s-1-tr 1370 Client-Txn: c-2-tr 1372 15 Timestamp: 1275930748.355 1373 Message Type: R 1374 Directionality: s 1375 Transport: udp 1376 CSeq-Number: 43 1377 CSeq-Method: ACK 1378 R-URI: sip:bob@bob2.example.net 1379 Destination-address: [2001:db8::9] 1380 Destination-port: 5060 1381 Source-address: 203.0.113.200 1382 Source-port: 5060 1383 To: sip:bob@example.net 1384 To-tag: b2-2 1385 From: sip:alice@example.com 1386 From-tag: a1-1 1387 Call-ID: tr-88h@example.com 1388 Status: - 1389 Server-Txn: s-1-tr 1390 Client-Txn: c-2-tr 1392 16 Timestamp: 1275930748.698 1393 Message Type: r 1394 Directionality: r 1395 Transport: udp 1396 CSeq-Number: 43 1397 CSeq-Method: CANCEL 1398 R-URI: - 1399 Destination-address: 203.0.113.200 1400 Destination-port: udp 1401 Source-address: [2001:db8::9] 1402 Source-port: 5060 1403 To: sip:bob@example.net 1404 To-tag: b2-2 1405 From: sip:alice@example.com 1406 From-tag: a1-1 1407 Call-ID: tr-88h@example.com 1408 Status: 200 1409 Server-Txn: s-1-tr 1410 Client-Txn: c-2-tr 1412 The above SIP CLF log makes it easy to search for a specific 1413 transaction or a state of the session. Searching for the string 1414 "c-1-tr" on the log records will readily yield the information that 1415 an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 1416 followed by a 180 and then a 200. Because the ACK request in this 1417 case would be exchanged end-to-end, this element does not see (and 1418 therefore will not log) the ACK. 1420 Searching on "c-2-tr" yields a more complex scenario of sending an 1421 INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, 1422 the log makes it apparent that the request to 1423 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 1424 response was generated, and that the pending INVITE returned a 487. 1425 The ACK to the final non-2xx response and a 200 to the CANCEL request 1426 complete the exchange on that branch. 1428 10. Security Considerations 1430 A log file by its nature reveals both the state of the entity 1431 producing it and the nature of the information being logged. To the 1432 extent that this state should not be publicly accessible and that the 1433 information is to be considered private, appropriate file and 1434 directory permissions attached to the log file SHOULD be used. It is 1435 outside the scope of this document to specify how to protect the log 1436 file while it is stored on disk, however, certain precautions can be 1437 taken. Operators SHOULD consider using common administrative 1438 features such as disk encryption and securing log files [schneier-1]. 1439 Operators SHOULD also consider hardening the machine on which the log 1440 file is stored by restricting physical access to the host as well as 1441 restricting access to the file itself. Depending on the specific 1442 operating system and environment, the file and directory permissions 1443 SHOULD be set to be most restrictive such that the file is not 1444 publicly readable and writable and the directory where the file is 1445 stored is not publicly accessible. 1447 The following threats may be considered for the log file while it is 1448 stored: 1450 o An attacker may gain access to view the log file, or may 1451 surreptitiously make a copy of the log file for later viewing. 1452 o An attacker who is unable to eavesdrop real-time SIP traffic on 1453 the network but nonetheless can access the log file, is able to 1454 easily mount replay attack or other attacks that result from 1455 channel eavesdropping. Encrypting SIP traffic does not help here 1456 because the SIP entity generating the log file would have 1457 decrypted the message for processing and subsequent logging. 1458 o An attacker may delete parts of --- or indeed, the whole --- file. 1460 Public access to the SIP log file creates more of a privacy leak when 1461 compared to an adversary eavesdropping cleartext SIP traffic on the 1462 network. If all SIP traffic on a network segment is encrypted, then 1463 as noted above, special attention must be directed to the file and 1464 directory permissions associated with the log file to preserve 1465 privacy such that only a privileged user can access the contents of 1466 the log file. 1468 Transporting SIP CLF files across the network pose special challenges 1469 as well. The following threats may be considered for transferring 1470 log files or while transferring individual log records: 1472 o An attacker may view the records; 1473 o An attacker may modify the records in transit or insert previously 1474 captured records into the stream; 1475 o An attacker may remove records in transit, or may stage a man- in- 1476 the-middle attack to deliver a partially or entirely falsified log 1477 file. 1479 It is also outside the scope of this document to specify protection 1480 methods for log files or log records that are being transferred 1481 between hosts, however, certain precautions can be taken. Operators 1482 SHOULD require mutual authentication, channel confidentiality and 1483 channel integrity while transferring the log file. The use of a 1484 secure shell transport layer protocol [RFC4253] or TLS [RFC5246] 1485 accomplishes this. 1487 Even with such care, sensitive information can be leaked during or 1488 after the transfer. SIP CLF fields like IP addresses and URIs 1489 contain potentially sensitive information. Before transferring the 1490 log file across domains, operators SHOULD ensure that any fields that 1491 contain sensitive information are appropriately anonymized or 1492 obfuscated. A specification for a format that describes which fields 1493 are obfuscated and with what characteristics (e.g., what correlations 1494 still work) is needed to allow interoperable but privacy-friendly 1495 exchange of SIP CLF between administrative domains. Such a 1496 specification is not attempted here, but is for further study. 1498 The SIP CLF represents the minimum fields that lend themselves to 1499 trend analysis and serve as information that may be deemed useful. 1500 Other formats can be defined that include more headers (and the body) 1501 from Section 8.1. However, where to draw a judicial line regarding 1502 the inclusion of non-mandatory headers can be challenging. Clearly, 1503 the more information a SIP entity logs, the longer time the logging 1504 process will take, the more disk space the log entry will consume, 1505 and the more potentially sensitive information could be breached. 1506 Therefore, adequate tradeoffs should be taken in account when logging 1507 more fields than the ones recommended in Section 8.1. 1509 Implementers need to pay particular attention to buffer handling when 1510 reading or writing log files. SIP CLF entries can be unbounded in 1511 length. It would be reasonable for a full dump of a SIP message to 1512 be thousands of octets long. This is of particular importance to CLF 1513 log parsers, as a SIP CLF log writers may add one or more extension 1514 fields to the message to be logged. 1516 11. Operational guidance 1518 SIP CLF log files will take up substantial amount of disk space 1519 depending on traffic volume at a processing entity and the amount of 1520 information being logged. As such, any organization using SIP CLF 1521 should establish operational procedures for file rollovers and 1522 periodic retrieval of logs before rollover as appropriate to the 1523 needs of the organization. 1525 Listing such operational guidelines in this document is out of scope 1526 for this work. 1528 12. IANA Considerations 1530 This document does not require any considerations from IANA. 1532 13. Acknowledgments 1534 Members of the sipping, dispatch, ipfix and syslog working groups 1535 provided invaluable input to the formulation of the draft. These 1536 include Benoit Claise, Spencer Dawkins, John Elwell, David 1537 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1538 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon 1539 Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, 1540 Dale Worley, Theo Zourzouvillys and others that we have undoubtedly, 1541 but inadvertently, missed. 1543 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1544 Salgueiro helped tremendously in discussions related to arriving at 1545 the beginnings of an information model. 1547 14. References 1549 14.1. Normative References 1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", BCP 14, RFC 2119, March 1997. 1554 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1555 A., Peterson, J., Sparks, R., Handley, M., and E. 1556 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1557 June 2002. 1559 14.2. Informative References 1561 [I-D.ietf-sipclf-format] 1562 Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1563 Session Initiation Protocol (SIP) Common Log Format 1564 (CLF)", draft-ietf-sipclf-format-11 (work in progress), 1565 December 2012. 1567 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1568 Resource Identifier (URI): Generic Syntax", STD 66, 1569 RFC 3986, January 2005. 1571 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1572 Transport Layer Protocol", RFC 4253, January 2006. 1574 [RFC5101] Claise, B., "Specification of the IP Flow Information 1575 Export (IPFIX) Protocol for the Exchange of IP Traffic 1576 Flow Information", RFC 5101, January 2008. 1578 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1579 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1581 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1583 [rieck2008] 1584 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1585 Muller, "A Self-learning System for Detection of Anomalous 1586 SIP Messages", Principles, Systems and Applications of IP 1587 Telecommunications Services and Security for Next 1588 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1589 2008. 1591 [schneier-1] 1592 Schneier, B. and J. Kelsey, "Secure audit logs to support 1593 computer forensics", ACM Transactions on Information and 1594 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1596 Authors' Addresses 1598 Vijay K. Gurbani (editor) 1599 Bell Laboratories, Alcatel-Lucent 1600 1960 Lucent Lane 1601 Naperville, IL 60566 1602 USA 1604 Email: vkg@bell-labs.com 1606 Eric W. Burger (editor) 1607 Georgetown University 1608 USA 1610 Email: eburger@standardstrack.com 1611 URI: http://www.standardstrack.com 1612 Tricha Anjali 1613 Illinois Institute of Technology 1614 316 Siegel Hall 1615 Chicago, IL 60616 1616 USA 1618 Email: tricha@ece.iit.edu 1620 Humberto Abdelnur 1621 INRIA 1622 INRIA - Nancy Grant Est 1623 Campus Scientifique 1624 54506, Vandoeuvre-les-Nancy Cedex 1625 France 1627 Email: humbol@gmail.com 1629 Olivier Festor 1630 INRIA 1631 INRIA - Nancy Grant Est 1632 Campus Scientifique 1633 54506, Vandoeuvre-les-Nancy Cedex 1634 France 1636 Email: Olivier.Festor@loria.fr