idnits 2.17.1 draft-ietf-sipclf-problem-statement-06.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2011) is 4756 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-sipclf-format-01 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: Informational E. Burger, Ed. 5 Expires: October 20, 2011 Georgetown University 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 April 18, 2011 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-06 16 Abstract 18 Well-known web servers such as Apache and web proxies like Squid 19 support event logging using a common log format. The logs produced 20 using these de-facto standard formats are invaluable to system 21 administrators for trouble-shooting a server and tool writers to 22 craft tools that mine the log files and produce reports and trends. 23 Furthermore, these log files can also be used to train anomaly 24 detection systems and feed events into a security event management 25 system. The Session Initiation Protocol does not have a common log 26 format, and as a result, each server supports a distinct log format 27 that makes it unnecessarily complex to produce tools to do trend 28 analysis and security detection. We propose a common log file format 29 for SIP servers that can be used uniformly by proxies, registrars, 30 redirect servers as well as back-to-back user agents. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 20, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 69 4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 4 70 5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 5 71 5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 5 72 5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 6 73 6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 6 74 7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 8 75 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 10 77 8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 12 78 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 14 80 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 15 81 9.3. Single downstream branch call . . . . . . . . . . . . . . 17 82 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 84 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 32 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 88 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33 89 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 92 1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 RFC 3261 [RFC3261] defines additional terms used in this document 99 that are specific to the SIP domain such as "proxy"; "registrar"; 100 "redirect server"; "user agent server" or "UAS"; "user agent client" 101 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 102 "transaction"; "server transaction". 104 This document uses the term "SIP Server" that is defined to include 105 the following SIP entities: user agent server, registrar, redirect 106 server, a SIP proxy in the role of user agent server, and a B2BUA in 107 the role of a user agent server. 109 2. Introduction 111 Servers executing on Internet hosts produce log records as part of 112 their normal operations. A log record is, in essence, a summary of 113 an application layer protocol data unit (PDU), that captures in 114 precise terms an event that was processed by the server. These log 115 records serve many purposes, including analysis and troubleshooting. 117 Well-known web servers such as Apache and Squid support event logging 118 using a Common Log Format (CLF), the common structure for logging 119 requests and responses serviced by the web server. It can be argued 120 that a good part of the success of Apache has been its CLF because it 121 allowed third parties to produce tools that analyzed the data and 122 generated traffic reports and trends. The Apache CLF has been so 123 successful that not only did it become the de-facto standard in 124 producing logging data for web servers, but also many commercial web 125 servers can be configured to produce logs in this format. An example 126 of Apache CLF is depicted next: 128 %h %l %u %t \"%r\" %s %b 129 remotehost rfc931 authuser [date] request status bytes 131 remotehost: Remote hostname (or IP number if DNS hostname is not 132 available, or if DNSLookup is Off. 134 rfc931: The remote logname of the user. 136 authuser: The username by which the user has authenticated himself. 138 [date]: Date and time of the request. 140 request: The request line exactly as it came from the client. 142 status: The HTTP status code returned to the client. 144 bytes: The content-length of the document transferred. 146 The inspiration for the SIP CLF is the Apache CLF. However, the 147 state machinery for a HTTP transaction is much simpler than that of 148 the SIP transaction (as evidenced in Section 7). The SIP CLF needs 149 to do considerably more. 151 3. Problem statement 153 The Session Initiation Protocol [RFC3261](SIP) is an Internet 154 multimedia session signaling protocol that is increasingly used for 155 other services besides session establishment. A typical deployment 156 of SIP in an enterprise will consist of SIP entities from multiple 157 vendors. Currently, if these entities are capable of producing a log 158 file of the transactions being handled by them, the log files are 159 produced in a proprietary format. The result of multiplicity of the 160 log file formats is the inability of the support staff to easily 161 trace a call from one entity to another, or even to craft common 162 tools that will perform trend analysis, debugging and troubleshooting 163 problems uniformly across the SIP entities of multiple vendors. 165 SIP does not currently have a CLF format and this document serves to 166 provide the rationale to establish a SIP CLF and identifies the 167 required minimal information that must appear in any SIP CLF record. 169 4. What SIP CLF is and what it is not 171 The SIP CLF is a standardized manner of producing a log file. This 172 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 173 The SIP CLF is simply an easily digestible log of currently occurring 174 events and past transactions. It contains enough information to 175 allow humans and automata to derive relationships between discrete 176 transactions handled at a SIP entity or to search for a certain 177 dialog or a related set of transactions. 179 The SIP CLF is amenable to quick parsing (i.e., well-delimited 180 fields) and it is platform and operating system neutral. 182 The SIP CLF is amenable to easy parsing and lends itself well to 183 creating other innovative tools. 185 The SIP CLF is not a billing tool. It is not expected that 186 enterprises will bill customers based on SIP CLF. The SIP CLF 187 records events at the signaling layer only and does not attempt to 188 correlate the veracity of these events with the media layer. Thus, 189 it cannot be used to trigger customer billing. 191 The SIP CLF is not a quality of service (QoS) measurement tool. If 192 QoS is defined as measuring the mean opinion score (MOS) of the 193 received media, then SIP CLF does not aid in this task since it does 194 not summarize events at the media layer. 196 5. Alternative approaches to SIP CLF 198 It is perhaps tempting to consider other approaches --- which though 199 not standardized, are in wide enough use in networks today --- to 200 determine whether or not a SIP CLF would benefit a SIP network 201 consisting of multi-vendor products. The two existing approaches 202 that approximate what SIP CLF does are Call Detail Records (CDRs) and 203 Wireshark packet sniffing. 205 5.1. SIP CLF and CDRs 207 CDRs are used in operator networks widely and with the adoption of 208 SIP, standardization bodies such as 3GPP have subsequently defined 209 SIP-related CDRs as well. Today, CDRs are used to implement the 210 functionality approximated by SIP CLF, however, there are important 211 differences. 213 One, SIP CLF operates natively at the transaction layer and maintains 214 enough information in the information elements being logged that 215 dialog-related data can be subsequently derived from the transaction 216 logs. Thus, esoteric SIP fields and parameters like the To header, 217 including tags; the From header, including tags, the CSeq number, 218 etc. are logged in SIP CLF. By contrast, a CDR is used mostly for 219 charging and thus saves information to facilitate that very aspect. 220 A CDR will most certainly log the public user identification of a 221 party requesting a service (which may not correspond to the From 222 header) and the public user identification of the party called party 223 (which may not correspond to the To header.) Furthermore, the 224 sequence numbers maintained by the CDR may not correspond to the SIP 225 CSeq header. Thus it will be hard to piece together the state of a 226 dialog through a sequence of CDR records. 228 Two, a CDR record will, in all probability, be generated at a SIP 229 entity performing some form of proxy-like functionality of a B2BUA 230 providing some service. By contrast, SIP CLF is light- weight enough 231 that it can be generated by a canonical SIP user agent server and 232 user agent client as well, including those that execute on resource 233 constrained devices (mobile phones). 235 Finally, SIP is also being deployed outside of operator- managed VoIP 236 networks. Universities, research laboratories, and small-to-medium 237 size companies are deploying SIP-based VoIP solutions on networks 238 owned and managed by them. Much of the latter constituencies will 239 not have an interest in generating CDRs, but they will like to have a 240 concise representation of the messages being handled by the SIP 241 entities in a common format. 243 5.2. SIP CLF and Wireshark packet capture 245 Wireshark is a popular raw packet capture tool. It contains filters 246 that can understand SIP at the protocol level and break down a 247 captured message into its individual header components. While 248 Wireshark is appropriate to capture and view discrete SIP messages, 249 it does not suffice to serve in the same capacity as SIP CLF for two 250 reasons. 252 First, all SIP entities that need to save SIP CLF records would 253 require a Wireshark library for different operating systems and 254 configurations to link into. Second, and more importantly, if the 255 SIP messages are exchanged over a TLS-oriented transport, Wireshark 256 will be unable to decrypt them and render them as individual SIP 257 headers. 259 6. Motivation and use cases 261 As SIP becomes pervasive in multiple business domains and ubiquitous 262 in academic and research environments, it is beneficial to establish 263 a CLF for the following reasons: 265 Common reference for interpreting events: In a laboratory 266 environment or an enterprise service offering there will typically 267 be SIP entities from multiple vendors participating in routing 268 requests. Absent a CLF format, each entity will produce output 269 records in a native format making it hard to establish commonality 270 for tools that operate on the log file. 272 Writing common tools: A CLF format allows independent tool providers 273 to craft tools and applications that interpret the CLF data to 274 produce insightful trend analysis and detailed traffic reports. 275 The format should be such that it retains the ability to be read 276 by humans and processed using traditional Unix text processing 277 tools. 279 Session correlation across diverse processing elements: In 280 operational SIP networks, a request will typically be processed by 281 more than one SIP server. A SIP CLF will allow the network 282 operator to trace the progression of the request (or a set of 283 requests) as they traverse through the different servers to 284 establish a concise diagnostic trail of a SIP session. 286 Note that tracing the request through a set of servers is 287 considerably less challenging if all the servers belong to the 288 same administrative domain. 290 Message correlation across transactions: A SIP CLF can enable a 291 quick lookup of all messages that comprise a transaction (e.g., 292 "Find all messages corresponding to server transaction X, 293 including all forked branches.") 295 Message correlation across dialogs: A SIP CLF can correlate 296 transactions that comprise a dialog (e.g., "Find all messages for 297 dialog created by Call-ID C, From tag F and To tag T.") 299 Trend analysis: A SIP CLF allows an administrator to collect data 300 and spot patterns or trends in the information (e.g., "What is the 301 domain where the most sessions are routed to between 9:00 AM and 302 12:00 PM?") 304 Train anomaly detection systems: A SIP CLF will allow for the 305 training of anomaly detection systems that once trained can 306 monitor the CLF file to trigger an alarm on the subsequent 307 deviations from accepted patterns in the data set. Currently, 308 anomaly detection systems monitor the network and parse raw 309 packets that comprise a SIP message -- a process that is 310 unsuitable for anomaly detection systems [rieck2008]. With all 311 the necessary event data at their disposal, network operations 312 managers and information technology operation managers are in a 313 much better position to correlate, aggregate, and prioritize log 314 data to maintain situational awareness. 316 Testing: A SIP CLF allows for automatic testing of SIP equipment by 317 writing tools that can parse a SIP CLF file to ensure behavior of 318 a device under test. 320 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 321 SIP entity (e.g., "How long did it take to generate a final 322 response for the INVITE associated with Call-ID X?") 324 Offline analysis: A SIP CLF allows for offline analysis of the data 325 gathered. Once a SIP CLF file has been generated, it can be 326 transported (subject to the security considerations in Section 10) 327 to a host with appropriate computing resources to perform 328 subsequent analysis. 330 Real-time monitoring: A SIP CLF allows administrators to visually 331 notice the events occurring at a SIP entity in real-time providing 332 accurate situational awareness. 334 7. Challenges in establishing a SIP CLF 336 Establishing a CLF for SIP is a challenging task. The behavior of a 337 SIP entity is more complex when compared to the equivalent HTTP 338 entity. 340 Base protocol services such as parallel or serial forking elicit 341 multiple final responses. Ensuing delays between sending a request 342 and receiving a final response all add complexity when considering 343 what fields should comprise a CLF and in what manner. Furthermore, 344 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 345 and these transactions may arrive at a varying inter-arrival rate at 346 a proxy. For example, the BYE transaction usually arrives much after 347 the corresponding INVITE transaction was received, serviced and 348 expunged from the transaction list. Nonetheless, it is advantageous 349 to relate these transactions such that automata or a human monitoring 350 the log file can construct a set consisting of related transactions. 352 ACK requests in SIP need careful consideration as well. In SIP, an 353 ACK is a special method that is associated with an INVITE only. It 354 does not require a response, and furthermore, if it is acknowledging 355 a non-2xx response, then the ACK is considered part of the original 356 INVITE transaction. If it is acknowledging a 2xx-class response, 357 then the ACK is a separate transaction consisting of a request only 358 (i.e., there is not a response for an ACK request.) CANCEL is 359 another method that is tied to an INVITE transaction, but unlike ACK, 360 the CANCEL request elicits a final response. 362 While most requests elicit a response immediately, the INVITE request 363 in SIP can pend at a proxy as it forks branches downstream or at a 364 user agent server while it alerts the user. RFC 3261 [RFC3261] 365 instructs the server transaction to send a 1xx-class provisional 366 response if a final response is delayed for more than 200 ms. A SIP 367 CLF log file needs to include such provisional responses because they 368 help train automata associated with anomaly detection systems and 369 provide some positive feedback for a human observer monitoring the 370 log file. 372 Finally, beyond supporting native SIP actors such as proxies, 373 registrars, redirect servers, and user agent servers (UAS), it is 374 beneficial to derive a CLF format that supports back-to-back user 375 agent (B2BUA) behavior, which may vary considerably depending on the 376 specific nature of the B2BUA. 378 8. Data model 380 The minimal SIP CLF fields are defined below. Some of these fields 381 contain URIs. If the URI contains an escaped character (""%" HEX 382 HEX" mechanism), the escaped character MUST be logged as received. 383 The maximum size (in number of bytes) for a SIP CLF field is 4096 384 bytes. This limit is the same regardless of whether the SIP CLF 385 field is a meta-field (see "Timestamp" and "Directionality" defined 386 below) or a normal SIP header. If the body of the SIP message is to 387 be logged, it MUST conform to this limit as well. 389 Logging bodies of a SIP message is left optional (and is not shown in 390 the examples of Section 9). If the body is to be logged, the 391 specific syntax and semantics used to log bodies MUST be defined by 392 the specific representation format used to generate the SIP CLF 393 record. 395 The data model supports extensibility by providing the capability to 396 log "optional fields". Optional fields are those SIP header fields 397 (or field components) that are not mandatory (see Section 8.1 for the 398 mandatory field list). Optional fields may contain SIP headers or 399 other elements present in a SIP message (for example, the Reason- 400 Phrase element from the Status-Line production rule in RFC 3261 401 [RFC3261]). Optional fields may also contain additional information 402 that a particular vendor desires to log. The specific syntax and 403 semantics to be accorded to optional fields MUST be defined by the 404 specific representation format used to generate the SIP CLF record. 406 Finally, [I-D.ietf-sipclf-format] is an example of a representation 407 format draft that provides an ASCII-based encoding scheme. 409 8.1. SIP CLF mandatory fields 411 The following SIP CLF fields are defined as minimal information that 412 MUST appear in any SIP CLF record: 414 Timestamp - Date and time of the request or response represented as 415 the number of seconds and milliseconds since the Unix epoch. 417 Message type - An indicator on whether the SIP message is a request 418 or a response. The allowable values for this field are 'R' (for 419 Request) and 'r' (for response). 421 Directionality - An indicator on whether the SIP message is received 422 by the SIP entity or sent by the SIP entity. The allowable values 423 for this field are 's' (for message sent) and 'r' (for message 424 received). 426 Transport - The transport over which a SIP message is sent or 427 received. The allowable values for the transport are governed by 428 the "transport" production rule in Section 25.1 of RFC3261 429 [RFC3261]. 431 Source-address - The IP address of the sender of the SIP message. 433 Source-port - The source port number of the sender of the SIP 434 message. 436 Destination-address - The IP address of the recipient of the SIP 437 message. 439 Destination-port - The port number of the recipient of the SIP 440 message. 442 From - The From URI. Whilst one may question the value of the From 443 URI in light of RFC4744 [RFC4474], the From URI, nonetheless, 444 imparts some information. For one, the From tag is important and, 445 in the case of a REGISTER request, the From URI can provide 446 information on whether this was a third-party registration or a 447 first-party one. It is not necessary to log any URI parameters. 449 From-tag - The tag parameter of the From header. 451 To - The To URI. It is not necessary to log any URI parameters. 453 To-tag - The tag parameter of the To header. Note that the tag 454 parameter will be absent in the initial request that forms a 455 dialog. 457 Callid - The Call-ID. 459 CSeq-Method - The method from the CSeq header. 461 CSeq-Number - The number from the CSeq header. 463 R-URI - The Request-URI, including any URI parameters. 465 Status - The SIP response status code. 467 SIP Proxies may fork, creating several client transactions that 468 correlate to a single server transaction. Responses arriving on 469 these client transactions, or new requests (CANCEL, ACK) sent on the 470 client transaction need log file entries that correlate with a server 471 transaction. Similarly, a B2BUA may create one or more client 472 transactions in response to an incoming request. These transactions 473 will require correlation as well. The last two data model elements 474 provide this correlation. 476 Server-Txn - Server transaction identification code - the 477 transaction identifier associated with the server transaction. 478 Implementations can reuse the server transaction identifier (the 479 topmost branch-id of the incoming request, with or without the 480 magic cookie), or they could generate a unique identification 481 string for a server transaction (this identifier needs to be 482 locally unique to the server only.) This identifier is used to 483 correlate ACKs and CANCELs to an INVITE transaction; it is also 484 used to aid in forking as explained later in this section. (See 485 Section 9 for usage.) 487 Client-Txn - Client transaction identification code - this field is 488 used to associate client transactions with a server transaction 489 for forking proxies or B2BUAs. Upon forking, implementations can 490 reuse the value they inserted into the topmost Via header's branch 491 parameter, or they can generate a unique identification string for 492 the client transaction. (See Section 9 for usage.) 494 This data model applies to all SIP entities --- a UAC, UAS, Proxy, a 495 B2BUA, registrar and redirect server. Note that a B2BUA is a 496 degenerate case of a proxy and as such the SIP CLF fields prescribed 497 for a proxy is equally applicable to the B2BUA. Similarly, 498 registrars and redirect servers are a degenerate case of a UAS, and 499 as such the SIP CLF fields prescribed for a UAS is equally applicable 500 to registrars and redirect servers. 502 The next section specifies the individual SIP CLF data model elements 503 that form a log record for specific instance of a SIP entity. We 504 limit our specification to using the minimum data model elements. It 505 is understood that a SIP CLF record is extensible using extension 506 mechanisms appropriate to the specific representation used to 507 generate the SIP CLF record. This document, however, does not 508 prescribe a specific representation format and it limits the 509 discussion to the mandatory data elements described above. 511 8.2. Mandatory fields and SIP entities 513 Each SIP CLF record MUST consist of all the mandatory data model 514 elements outlined in Section 8.1. This document does not specify a 515 representation of a logging format; it is expected that other 516 documents will do so. Each SIP CLF record MUST contain the mandatory 517 elements shown below: 519 Timestamp, Message type, Directionality, CSeq-Method, 520 CSeq-Number, Transport, R-URI, Destination-address, 521 Destination-port, Source-address, Source-port, To, 522 To-tag, From, From-tag, Call-ID, Status, Server-Txn, 523 Client-Txn 525 Table 1 summarizes how the mandatory fields are logged by a UAC, UAS, 526 or UAC-half, UAS-half of a SIP proxy and B2BUA. In the table below: 528 R: implies that the field is logged when a request is handled by that 529 SIP entity. 531 r: implies that the field is logged when a response is handled by 532 that SIP entity. 534 -: implies that the field is not applicable to that SIP entity. 536 +---------------------+-----+-----+----------+----------+ 537 | | UAC | UAS | UAS-half | UAC-half | 538 +---------------------+-----+-----+----------+----------+ 539 | Timestamp | R,r | R,r | R,r | R,r | 540 | Message type | R,r | R,r | R,r | R,r | 541 | Directionality | R,r | R,r | R,r | R,r | 542 | Transport | R,r | R,r | R,r | R,r | 543 | CSeq-Method | R,r | R,r | R,r | R,r | 544 | CSeq-Number | R,r | R,r | R,r | R,r | 545 | R-URI | R | R | R | R | 546 | Destination-address | R,r | R,r | R,r | R,r | 547 | Destination-port | R,r | R,r | R,r | R,r | 548 | Source-address | R,r | R,r | R,r | R,r | 549 | Source-port | R,r | R,r | R,r | R,r | 550 | To | R,r | R,r | R,r | R,r | 551 | To-tag | R,r | R,r | R,r | R,r | 552 | From | R,r | R,r | R,r | R,r | 553 | From-tag | R,r | R,r | R,r | R,r | 554 | Call-ID | R,r | R,r | R,r | R,r | 555 | Status | r | r | r | r | 556 | Server-Txn | - | R,r | R,r | R,r | 557 | Client-Txn | R,r | - | r | R,r | 558 +---------------------+-----+-----+----------+----------+ 560 SIP CLF fields logged per entity 562 Table 1 564 9. Examples 566 The examples use only the mandatory data elements defined in 567 Section 8.1. Extension elements are not considered. The examples 568 below use the template defined in Section 8.2 when logging a SIP CLF 569 record. When a given mandatory field is not applicable to a SIP 570 entity as determined by Table 1, we use the horizontal dash ("-") to 571 represent it. 573 There are five principals in the examples below. They are Alice, the 574 initiator of requests. Alice's user agent uses IPv4 address 575 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 576 on their way to Bob, the recipient of the requests. P1 also acts as 577 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 578 5060. Bob has two instances of his user agent running on different 579 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 580 5060 and the second instance uses an IPv6 address of 2001:db8::9, 581 port 5060. P2 is a proxy responsible for Bob's domain. Table 2 582 summarizes these addresses. 584 +-------------------+--------------------+-------------------+ 585 | Principal | IP:port | Host/Domain name | 586 +-------------------+--------------------+-------------------+ 587 | Alice | 198.51.100.1:5060 | alice.example.com | 588 | P1 | 198.51.100.10:5060 | p1.example.com | 589 | P2 | 203.0.113.200:5060 | p2.example.net | 590 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 591 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 592 +-------------------+--------------------+-------------------+ 594 Principal to IP address asignment 596 Table 2 598 Illustrative examples of SIP CLF follow. 600 9.1. UAC registration 602 Alice sends a registration registrar P1 and receives a 2xx-class 603 response. The register requests causes Alice's UAC to produce a log 604 record shown below. The mandatory data model elements correspond to 605 those listed in Table 1. 607 Timestamp: 1275930743.699 608 Message Type: R 609 Directionality: s 610 Transport: udp 611 CSeq-Number: 1 612 CSeq-Method: REGISTER 613 R-URI: sip:example.com 614 Destination-address: 198.51.100.10 615 Destination-port: 5060 616 Source-address: 198.51.100.1 617 Source-port: 5060 618 To: sip:example.com 619 To-tag: - 620 From: sip:alice@example.com 621 From-tag: 76yhh 622 Call-ID: f81-d4-f6@example.com 623 Status: - 624 Server-Txn: - 625 Client-Txn: c-tr-1 627 After some time, Alice's UAC will receive a response from the 628 registrar. The response causes Alice's agent to produce a log record 629 shown below. The mandatory data elements correspond to those listed 630 in Table 1. 632 Timestamp: 1275930744.100 633 Message Type: r 634 Directionality: r 635 Transport: udp 636 CSeq-Number: 1 637 CSeq-Method: REGISTER 638 R-URI: - 639 Destination-address: 198.51.100.1 640 Destination-port: 5060 641 Source-address: 198.51.100.10 642 Source-port: 5060 643 To: sip:example.com 644 To-tag: reg-1-xtr 645 From: sip:alice@example.com 646 From-tag: 76yhh 647 Call-ID: f81-d4-f6@example.com 648 Status: 100 649 Server-Txn: - 650 Client-Txn: c-tr-1 652 9.2. Direct call between Alice and Bob 654 In this example, Alice sends a session initiation request directly to 655 Bob's agent (instance 1.) Bob's agent accepts the session 656 invitation. We first present the SIP CLF logging from Alice's UAC 657 point of view. In line 1, Alice's user agent sends out the INVITE. 658 Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" 659 response (line 3). Upon the receipt of the 2xx-class response, 660 Alice's user agent sends out an ACK request (line 4). 662 Timestamp: 1275930743.699 663 Message Type: R 664 Directionality: s 665 Transport: udp 666 CSeq-Number: 32 667 CSeq-Method: INVITE 668 R-URI: sip:bob@bob1.example.net 669 Destination-address: 203.0.113.1 670 Destination-port: 5060 671 Source-address: 198.51.100.1 672 Source-port: 5060 673 To: sip:bob@example.net 674 To-tag: - 675 From: sip:alice@example.com 676 From-tag: 76yhh 677 Call-ID: f82-d4-f7@example.com 678 Status: - 679 Server-Txn: - 680 Client-Txn: c-1-xt6 682 Timestamp: 1275930745.002 683 Message Type: r 684 Directionality: r 685 Transport: udp 686 CSeq-Number: 32 687 CSeq-Method: INVITE 688 R-URI: - 689 Destination-address: 198.51.1.100 690 Destination-port: 5060 691 Source-address: 203.0.113.1 692 Source-port: 5060 693 To: sip:bob@example.net 694 To-tag: b-in6-iu 695 From: sip:alice@example.com 696 From-tag: 76yhh 697 Call-ID: f82-d4-f7@example.com 698 Status: 180 699 Server-Txn: - 700 Client-Txn: c-1-xt6 702 Timestamp: 1275930746.100 703 Message Type: r 704 Directionality: r 705 Transport: udp 706 CSeq-Number: 32 707 CSeq-Method: INVITE 708 R-URI: - 709 Destination-address: 198.51.1.100 710 Destination-port: 5060 711 Source-address: 203.0.113.1 712 Source-port: 5060 713 To: sip:bob@example.net 714 To-tag: b-in6-iu 715 From: sip:alice@example.com 716 From-tag: 76yhh 717 Call-ID: f82-d4-f7@example.com 718 Status: 200 719 Server-Txn: - 720 Client-Txn: c-1-xt6 722 Timestamp: 1275930746.120 723 Message Type: R 724 Directionality: s 725 Transport: udp 726 CSeq-Number: 32 727 CSeq-Method: ACK 728 R-URI: sip:bob@bob1.example.net 729 Destination-address: 203.0.113.1 730 Destination-port: 5060 731 Source-address: 198.51.100.1 732 Source-port: 5060 733 To: sip:bob@example.net 734 To-tag: b-in6-iu 735 From: sip:alice@example.com 736 From-tag: 76yhh 737 Call-ID: f82-d4-f7@example.com 738 Status: - 739 Server-Txn: - 740 Client-Txn: c-1-xt6 742 9.3. Single downstream branch call 744 In this example, Alice sends a session invitation request to Bob 745 through proxy P1, which inserts a Record-Route header causing 746 subsequent requests between Alice and Bob to traverse the proxy. The 747 SIP CLF log records correspond to the viewpoint of P1. The line 748 numbers below refer to Figure 1 750 Alice P1 Bob 751 +---INV--------->| | Line 1 752 | | | 753 |<---------100---+ | Line 2 754 | | | 755 | +---INV-------->| Line 3 756 | | | 757 | |<--------100---+ Line 4 758 | | | 759 | |<--------180---+ Line 5 760 | | | 761 |<---------180---+ | Line 6 762 | | | 763 | |<--------200---+ Line 7 764 | | | 765 |<---------200---+ | Line 8 766 | | | 767 +---ACK--------->| | Line 9 768 | | | 769 | |---ACK-------->| Line 10 771 Figure 1: Simple proxy-aided call flow 773 1 Timestamp: 1275930743.699 774 Message Type: R 775 Directionality: r 776 Transport: udp 777 CSeq-Number: 43 778 CSeq-Method: INVITE 779 R-URI: sip:bob@example.net 780 Destination-address: 198.51.100.10 781 Destination-port: 5060 782 Source-address: 198.51.100.1 783 Source-port: 5060 784 To: sip:bob@example.net 785 To-tag: - 786 From: sip:alice@example.com 787 From-tag: al-1 788 Call-ID: tr-87h@example.com 789 Status: - 790 Server-Txn: s-x-tr 791 Client-Txn: - 793 Note that at this point P1 has created a server transaction 794 identification code and populated the SIP CLF field Server-Txn with 795 it. P1 has not yet created a client transaction identification code, 796 thus Client-Txn contains a "-". 798 2 Timestamp: 1275930744.001 799 Message Type: r 800 Directionality: s 801 Transport: udp 802 CSeq-Number: 43 803 CSeq-Method: INVITE 804 R-URI: - 805 Destination-address: 198.51.100.1 806 Destination-port: 5060 807 Source-address: 198.51.100.10 808 Source-port: 5060 809 To: sip:bob@example.net 810 To-tag: - 811 From: sip:alice@example.com 812 From-tag: al-1 813 Call-ID: tr-87h@example.com 814 Status: 100 815 Server-Txn: s-x-tr 816 Client-Txn: - 818 In line 3 below, P1 has created a client transaction identification 819 code for the downstream branch and populated the SIP CLF field 820 Client-Txn. 822 3 Timestamp: 1275930744.998 823 Message Type: R 824 Directionality: s 825 Transport: udp 826 CSeq-Number: 43 827 CSeq-Method: INVITE 828 R-URI: sip:bob@bob1.example.net 829 Destination-address: 203.0.113.1 830 Destination-port: 5060 831 Source-address: 198.51.100.10 832 Source-port: 5060 833 To: sip:bob@example.net 834 To-tag: - 835 From: sip:alice@example.com 836 From-tag: al-1 837 Call-ID: tr-87h@example.com 838 Status: - 839 Server-Txn: s-x-tr 840 Client-Txn: c-x-tr 842 4 Timestamp: 1275930745.200 843 Message Type: r 844 Directionality: r 845 Transport: udp 846 CSeq-Number: 43 847 CSeq-Method: INVITE 848 R-URI: - 849 Destination-address: 198.51.100.10 850 Destination-port: 5060 851 Source-address: 203.0.113.1 852 Source-port: 5060 853 To: sip:bob@example.net 854 To-tag: b1-1 855 From: sip:alice@example.com 856 From-tag: al-1 857 Call-ID: tr-87h@example.com 858 Status: 100 859 Server-Txn: s-x-tr 860 Client-Txn: c-x-tr 862 5 Timestamp: 1275930745.800 863 Message Type: r 864 Directionality: r 865 Transport: udp 866 CSeq-Number: 43 867 CSeq-Method: INVITE 868 R-URI: - 869 Destination-address: 198.51.100.10 870 Destination-port: 5060 871 Source-address: 203.0.113.1 872 Source-port: 5060 873 To: sip:bob@example.net 874 To-tag: b1-1 875 From: sip:alice@example.com 876 From-tag: al-1 877 Call-ID: tr-87h@example.com 878 Status: 180 879 Server-Txn: s-x-tr 880 Client-Txn: c-x-tr 882 6 Timestamp: 1275930746.009 883 Message Type: r 884 Directionality: s 885 Transport: udp 886 CSeq-Number: 43 887 CSeq-Method: INVITE 888 R-URI: - 889 Destination-address: 198.51.100.1 890 Destination-port: 5060 891 Source-address: 198.51.100.10 892 Source-port: 5060 893 To: sip:bob@example.net 894 To-tag: b1-1 895 From: sip:alice@example.com 896 From-tag: al-1 897 Call-ID: tr-87h@example.com 898 Status: 180 899 Server-Txn: s-x-tr 900 Client-Txn: c-x-tr 902 7 Timestamp: 1275930747.120 903 Message Type: r 904 Directionality: r 905 Transport: udp 906 CSeq-Number: 43 907 CSeq-Method: INVITE 908 R-URI: - 909 Destination-address: 198.51.100.10 910 Destination-port: 5060 911 Source-address: 203.0.113.1 912 Source-port: 5060 913 To: sip:bob@example.net 914 To-tag: b1-1 915 From: sip:alice@example.com 916 From-tag: al-1 917 Call-ID: tr-87h@example.com 918 Status: 200 919 Server-Txn: s-x-tr 920 Client-Txn: c-x-tr 922 8 Timestamp: 1275930747.300 923 Message Type: r 924 Directionality: s 925 Transport: udp 926 CSeq-Number: 43 927 CSeq-Method: INVITE 928 R-URI: - 929 Destination-address: 198.51.100.1 930 Destination-port: 5060 931 Source-address: 198.51.100.10 932 Source-port: 5060 933 To: sip:bob@example.net 934 To-tag: b1-1 935 From: sip:alice@example.com 936 From-tag: al-1 937 Call-ID: tr-87h@example.com 938 Status: 200 939 Server-Txn: s-x-tr 940 Client-Txn: c-x-tr 942 9 Timestamp: 1275930749.100 943 Message Type: R 944 Directionality: r 945 Transport: udp 946 CSeq-Number: 43 947 CSeq-Method: ACK 948 R-URI: sip:bob@example.net 949 Destination-address: 198.51.100.10 950 Destination-port: 5060 951 Source-address: 198.51.100.1 952 Source-port: 5060 953 To: sip:bob@example.net 954 To-tag: b1-1 955 From: sip:alice@example.com 956 From-tag: al-1 957 Call-ID: tr-87h@example.com 958 Status: - 959 Server-Txn: s-x-tr 960 Client-Txn: c-x-tr 962 10 Timestamp: 1275930749.100 963 Message Type: R 964 Directionality: s 965 Transport: udp 966 CSeq-Number: 43 967 CSeq-Method: ACK 968 R-URI: sip:bob@bob1.example.net 969 Destination-address: 203.0.113.1 970 Destination-port: 5060 971 Source-address: 198.51.100.10 972 Source-port: 5060 973 To: sip:bob@example.net 974 To-tag: b1-1 975 From: sip:alice@example.com 976 From-tag: al-1 977 Call-ID: tr-87h@example.com 978 Status: - 979 Server-Txn: s-x-tr 980 Client-Txn: c-x-tr 982 9.4. Forked call 984 In this example, Alice sends a session invitation to Bob's proxy, P2. 985 P2 forks the session invitation request to two registered endpoints 986 corresponding to Bob's address-of-record. Both endpoints respond 987 with provisional responses. Shortly thereafter, one of Bob's user 988 agent instances accepts the call, causing P2 to send a CANCEL request 989 to the second user agent. P2 does not Record-Route, therefore the 990 subsequent ACK request from Alice to Bob's user agent does not 991 traverse through P2 (and is not shown below.) 993 Figure 2 depicts the call flow. 995 Bob Bob 996 Alice P2 (Instance 1) (Instance 2) 997 +---INV--->| | | Line 1 998 | | | | 999 |<---100---+ | | Line 2 1000 | | | | 1001 | +---INV--->| | Line 3 1002 | | | | 1003 | +---INV----+-------->| Line 4 1004 | | | | 1005 | |<---100---+ | Line 5 1006 | | | | 1007 | |<---------+---100---+ Line 6 1008 | | | | 1009 | |<---180---+---------+ Line 7 1010 | | | | 1011 |<---180---+ | | Line 8 1012 | | | | 1013 | |<---180---+ | Line 9 1014 | | | | 1015 |<---180---+ | | Line 10 1016 | | | | 1017 | |<---200---+ | Line 11 1018 | | | | 1019 |<---200---+ | | Line 12 1020 | | | | 1021 | +---CANCEL-+-------->| Line 13 1022 | | | | 1023 | |<---------+---487---+ Line 14 1024 | | | | 1025 | +---ACK----+-------->| Line 15 1026 | | | | 1027 | |<---------+---200---+ Line 16 1029 Figure 2: Forked call flow 1031 The SIP CLF log correspond to the viewpoint of P2. The fields logged 1032 are shown below; the line numbers refer to Figure 2. 1034 1 Timestamp: 1275930743.699 1035 Message Type: R 1036 Directionality: r 1037 Transport: udp 1038 CSeq-Number: 43 1039 CSeq-Method: INVITE 1040 R-URI: sip:bob@example.net 1041 Destination-address: 203.0.113.200 1042 Destination-port: 5060 1043 Source-address: 198.51.100.1 1044 Source-port: 5060 1045 To: sip:bob@example.net 1046 To-tag: - 1047 From: sip:alice@example.com 1048 From-tag: a1-1 1049 Call-ID: tr-88h@example.com 1050 Status: - 1051 Server-Txn: s-1-tr 1052 Client-Txn: - 1054 2 Timestamp: 1275930744.001 1055 Message Type: r 1056 Directionality: s 1057 Transport: udp 1058 CSeq-Number: 43 1059 CSeq-Method: INVITE 1060 R-URI: - 1061 Destination-address: 198.51.100.1 1062 Destination-port: 5060 1063 Source-address: 203.0.113.200 1064 Source-port: 5060 1065 To: sip:bob@example.net 1066 To-tag: - 1067 From: sip:alice@example.com 1068 From-tag: a1-1 1069 Call-ID: tr-88h@example.com 1070 Status: 100 1071 Server-Txn: s-1-tr 1072 Client-Txn: - 1074 3 Timestamp: 1275930744.998 1075 Message Type: R 1076 Directionality: s 1077 Transport: udp 1078 CSeq-Number: 43 1079 CSeq-Method: INVITE 1080 R-URI: sip:bob@bob1.example.net 1081 Destination-address: 203.0.113.1 1082 Destination-port: 5060 1083 Source-address: 203.0.113.200 1084 Source-port: 5060 1085 To: sip:bob@example.net 1086 To-tag: - 1087 From: sip:alice@example.com 1088 From-tag: a1-1 1089 Call-ID: tr-88h@example.com 1090 Status: - 1091 Server-Txn: s-1-tr 1092 Client-Txn: c-1-tr 1094 4 Timestamp: 1275930745.500 1095 Message Type: R 1096 Directionality: s 1097 Transport: udp 1098 CSeq-Number: 43 1099 CSeq-Method: INVITE 1100 R-URI: sip:bob@bob2.example.net 1101 Destination-address: [2001:db8::9] 1102 Destination-port: 5060 1103 Source-address: 203.0.113.200 1104 Source-port: 5060 1105 To: sip:bob@example.net 1106 To-tag: - 1107 From: sip:alice@example.com 1108 From-tag: a1-1 1109 Call-ID: tr-88h@example.com 1110 Status: - 1111 Server-Txn: s-1-tr 1112 Client-Txn: c-2-tr 1114 5 Timestamp: 1275930745.800 1115 Message Type: r 1116 Directionality: r 1117 Transport: udp 1118 CSeq-Number: 43 1119 CSeq-Method: INVITE 1120 R-URI: - 1121 Destination-address: 203.0.113.200 1122 Destination-port: 5060 1123 Source-address: 203.0.113.1 1124 Source-port: 5060 1125 To: sip:bob@example.net 1126 To-tag: b1=-1 1127 From: sip:alice@example.com 1128 From-tag: a1-1 1129 Call-ID: tr-88h@example.com 100 1130 Status: 100 1131 Server-Txn: s-1-tr 1132 Client-Txn: c-1-tr 1134 6 Timestamp: 1275930746.100 1135 Message Type: r 1136 Directionality: r 1137 Transport: udp 1138 CSeq-Number: 43 1139 CSeq-Method: INVITE 1140 R-URI: - 1141 Destination-address: 203.0.113.200 1142 Destination-port: udp 1143 Source-address: [2001:db8::9] 1144 Source-port: 5060 1145 To: sip:bob@example.net 1146 To-tag: b2-2 1147 From: sip:alice@example.com 1148 From-tag: a1-1 1149 Call-ID: tr-88h@example.com 1150 Status: 100 1151 Server-Txn: s-1-tr 1152 Client-Txn: c-2-tr 1154 7 Timestamp: 1275930746.700 1155 Message Type: r 1156 Directionality: r 1157 Transport: udp 1158 CSeq-Number: 43 1159 CSeq-Method: INVITE 1160 R-URI: - 1161 Destination-address: 203.0.113.200 1162 Destination-port: udp 1163 Source-address: [2001:db8::9] 1164 Source-port: 5060 1165 To: sip:bob@example.net 1166 To-tag: b2-2 1167 From: sip:alice@example.com 1168 From-tag: a1-1 1169 Call-ID: tr-88h@example.com 1170 Status: 180 1171 Server-Txn: s-1-tr 1172 Client-Txn: c-2-tr 1174 8 Timestamp: 1275930746.990 1175 Message Type: r 1176 Directionality: s 1177 Transport: udp 1178 CSeq-Number: 43 1179 CSeq-Method: INVITE 1180 R-URI: - 1181 Destination-address: 198.51.100.1 1182 Destination-port: 5060 1183 Source-address: 203.0.113.200 1184 Source-port: 5060 1185 To: sip:bob@example.net 1186 To-tag: b2-2 1187 From: sip:alice@example.com 1188 From-tag: a1-1 1189 Call-ID: tr-88h@example.com 1190 Status: 180 1191 Server-Txn: s-1-tr 1192 Client-Txn: c-2-tr 1194 9 Timestamp: 1275930747.100 1195 Message Type: r 1196 Directionality: r 1197 Transport: udp 1198 CSeq-Number: 43 1199 CSeq-Method: INVITE 1200 R-URI: - 1201 Destination-address: 203.0.113.200 1202 Destination-port: 5060 1203 Source-address: 203.0.113.1 1204 Source-port: 5060 1205 To: sip:bob@example.net 1206 To-tag: b1-1 1207 From: sip:alice@example.com 1208 From-tag: a1-1 1209 Call-ID: tr-88h@example.com 100 1210 Status: 180 1211 Server-Txn: s-1-tr 1212 Client-Txn: c-1-tr 1214 10 Timestamp: 1275930747.300 1215 Message Type: r 1216 Directionality: s 1217 Transport: udp 1218 CSeq-Number: 43 1219 CSeq-Method: INVITE 1220 R-URI: - 1221 Destination-address: 198.51.100.1 1222 Destination-port: 5060 1223 Source-address: 203.0.113.200 1224 Source-port: 5060 1225 To: sip:bob@example.net 1226 To-tag: b1-1 1227 From: sip:alice@example.com 1228 From-tag: a1-1 1229 Call-ID: tr-88h@example.com 1230 Status: 180 1231 Server-Txn: s-1-tr 1232 Client-Txn: c-2-tr 1234 11 Timestamp: 1275930747.800 1235 Message Type: r 1236 Directionality: r 1237 Transport: udp 1238 CSeq-Number: 43 1239 CSeq-Method: INVITE 1240 R-URI: - 1241 Destination-address: 203.0.113.200 1242 Destination-port: 5060 1243 Source-address: 203.0.113.1 1244 Source-port: 5060 1245 To: sip:bob@example.net 1246 To-tag: b1-1 1247 From: sip:alice@example.com 1248 From-tag: a1-1 1249 Call-ID: tr-88h@example.com 100 1250 Status: 200 1251 Server-Txn: s-1-tr 1252 Client-Txn: c-1-tr 1254 12 Timestamp: 1275930748.000 1255 Message Type: r 1256 Directionality: s 1257 Transport: udp 1258 CSeq-Number: 43 1259 CSeq-Method: INVITE 1260 R-URI: - 1261 Destination-address: 198.51.100.1 1262 Destination-port: 5060 1263 Source-address: 203.0.113.200 1264 Source-port: 5060 1265 To: sip:bob@example.net 1266 To-tag: b1-1 1267 From: sip:alice@example.com 1268 From-tag: a1-1 1269 Call-ID: tr-88h@example.com 1270 Status: 200 1271 Server-Txn: s-1-tr 1272 Client-Txn: c-1-tr 1274 13 Timestamp: 1275930748.201 1275 Message Type: R 1276 Directionality: s 1277 Transport: udp 1278 CSeq-Number: 43 1279 CSeq-Method: CANCEL 1280 R-URI: sip:bob@bob2.example.net 1281 Destination-address: [2001:db8::9] 1282 Destination-port: 5060 1283 Source-address: 203.0.113.200 1284 Source-port: 5060 1285 To: sip:bob@example.net 1286 To-tag: b2-2 1287 From: sip:alice@example.com 1288 From-tag: a1-1 1289 Call-ID: tr-88h@example.com 1290 Status: - 1291 Server-Txn: s-1-tr 1292 Client-Txn: c-2-tr 1294 14 Timestamp: 1275930748.991 1295 Message Type: r 1296 Directionality: r 1297 Transport: udp 1298 CSeq-Number: 43 1299 CSeq-Method: INVITE 1300 R-URI: - 1301 Destination-address: 203.0.113.200 1302 Destination-port: udp 1303 Source-address: [2001:db8::9] 1304 Source-port: 5060 1305 To: sip:bob@example.net 1306 To-tag: b2-2 1307 From: sip:alice@example.com 1308 From-tag: a1-1 1309 Call-ID: tr-88h@example.com 1310 Status: 487 1311 Server-Txn: s-1-tr 1312 Client-Txn: c-2-tr 1314 15 Timestamp: 1275930749.455 1315 Message Type: R 1316 Directionality: s 1317 Transport: udp 1318 CSeq-Number: 43 1319 CSeq-Method: ACK 1320 R-URI: sip:bob@bob2.example.net 1321 Destination-address: [2001:db8::9] 1322 Destination-port: 5060 1323 Source-address: 203.0.113.200 1324 Source-port: 5060 1325 To: sip:bob@example.net 1326 To-tag: b2-2 1327 From: sip:alice@example.com 1328 From-tag: a1-1 1329 Call-ID: tr-88h@example.com 1330 Status: - 1331 Server-Txn: s-1-tr 1332 Client-Txn: c-2-tr 1334 16 Timestamp: 1275930750.001 1335 Message Type: r 1336 Directionality: r 1337 Transport: udp 1338 CSeq-Number: 43 1339 CSeq-Method: CANCEL 1340 R-URI: - 1341 Destination-address: 203.0.113.200 1342 Destination-port: udp 1343 Source-address: [2001:db8::9] 1344 Source-port: 5060 1345 To: sip:bob@example.net 1346 To-tag: b2-2 1347 From: sip:alice@example.com 1348 From-tag: a1-1 1349 Call-ID: tr-88h@example.com 1350 Status: 200 1351 Server-Txn: s-1-tr 1352 Client-Txn: c-2-tr 1354 The above SIP CLF log makes it easy to search for a specific 1355 transaction or a state of the session. Searching for the string 1356 "c-1-tr" on the log records will readily yield the information that 1357 an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 1358 followed by a 180 and then a 200. The absence of the ACK request 1359 signifies that the ACK was exchanged end-to-end. 1361 Searching on "c-2-tr" yields a more complex scenario of sending an 1362 INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, 1363 the log makes it apparent that the request to 1364 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 1365 response was generated, and that the pending INVITE returned a 487. 1366 The ACK to the final non-2xx response and a 200 to the CANCEL request 1367 complete the exchange on that branch. 1369 10. Security Considerations 1371 A log file by its nature reveals both the state of the entity 1372 producing it and the nature of the information being logged. To the 1373 extent that this state should not be publicly accessible and that the 1374 information is to be considered private, appropriate file and 1375 directory permissions attached to the log file should be used. The 1376 following threats may be considered for the log file while it is 1377 stored: 1379 o An attacker may gain access to view the log file, or may 1380 surreptitiously make a copy of the log file for later viewing; 1381 o An attacker may mount a replay attack by modifying existing 1382 records in the log file or inserting new records; 1383 o An attacker may delete parts of --- or indeed, the whole --- file. 1385 It is outside the scope of this document to specify how to protect 1386 the log file while it is stored on disk. However, operators may 1387 consider using common administrative features such as disk encryption 1388 and securing log files [schneier-1]. Operators may also consider 1389 hardening the machine on which the log files are stored by 1390 restricting physical access to the host as well as restricting access 1391 to the files themselves. 1393 In the worst case, public access to the SIP log file provides the 1394 same information that an adversary can gain using network sniffing 1395 tools (assuming that the SIP traffic is in clear text.) If all SIP 1396 traffic on a network segment is encrypted, then as noted above, 1397 special attention must be directed to the file and directory 1398 permissions associated with the log file to preserve privacy such 1399 that only a privileged user can access the contents of the log file. 1401 Transporting SIP CLF files across the network pose special challenges 1402 as well. The following threats may be considered for transferring 1403 log files or while transferring individual log records: 1405 o An attacker may view the records; 1406 o An attacker may modify the records in transit or insert previously 1407 captured records into the stream; 1408 o An attacker may remove records in transit, or may stage a man- in- 1409 the-middle attack to deliver a partially or entirely falsified log 1410 file. 1412 It is also outside the scope of this document to specify protection 1413 methods for log files or log records that are being transferred 1414 between hosts. However, operators may consider using common security 1415 protocols described in [RFC3552] to transfer log files or individual 1416 records. Alternatively, the log file may be transferred through bulk 1417 methods that also guarantees integrity, or at least detects and 1418 alerts to modification attempts. 1420 The SIP CLF represents the minimum fields that lend themselves to 1421 trend analysis and serve as information that may be deemed useful. 1422 Other formats can be defined that include more headers (and the body) 1423 from Section 8.1. However, where to draw a judicial line regarding 1424 the inclusion of non-mandatory headers can be challenging. Clearly, 1425 the more information a SIP entity logs, the longer time the logging 1426 process will take, the more disk space the log entry will consume, 1427 and the more potentially sensitive information could be breached. 1428 Therefore, adequate tradeoffs should be taken in account when logging 1429 more fields than the ones recommended in Section 8.1. 1431 Implementers need to pay particular attention to buffer handling when 1432 reading or writing log files. SIP CLF entries can be unbounded in 1433 length. It would be reasonable for a full dump of a SIP message to 1434 be thousands of octets long. This is of particular importance to CLF 1435 log parsers, as a SIP CLF log writers may add one or more extension 1436 fields to the message to be logged. 1438 11. Operational guidance 1440 SIP CLF log files will take up substantive amount of disk space 1441 depending on traffic volume at a processing entity and the amount of 1442 information being logged. As such, any enterprise using SIP CLF 1443 should establish operational procedures for file rollovers as 1444 appropriate to the needs of the organization. 1446 Listing such operational guidelines in this document is out of scope 1447 for this work. 1449 12. IANA Considerations 1451 This document does not require any considerations from IANA. 1453 13. Acknowledgments 1455 Members of the sipping, dispatch, ipfix and syslog working groups 1456 provided invaluable input to the formulation of the draft. These 1457 include Benoit Claise, Spencer Dawkins, John Elwell, David 1458 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1459 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Simon Perreault, Adam 1460 Roach, Dan Romascanu, Robert Sparks, Brian Trammell, Dale Worley, 1461 Theo Zourzouvillys and others that we have undoubtedly, but 1462 inadvertently, missed. 1464 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1465 Salgueiro helped tremendously in discussions related to arriving at 1466 the beginnings of a data model. 1468 14. References 1469 14.1. Normative References 1471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1472 Requirement Levels", BCP 14, RFC 2119, March 1997. 1474 14.2. Informative References 1476 [I-D.ietf-sipclf-format] 1477 Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1478 Session Initiation Protocol (SIP) Common Log Format 1479 (CLF)", draft-ietf-sipclf-format-01 (work in progress), 1480 March 2011. 1482 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1483 A., Peterson, J., Sparks, R., Handley, M., and E. 1484 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1485 June 2002. 1487 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1488 Text on Security Considerations", BCP 72, RFC 3552, 1489 July 2003. 1491 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1492 Authenticated Identity Management in the Session 1493 Initiation Protocol (SIP)", RFC 4474, August 2006. 1495 [rieck2008] 1496 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1497 Muller, "A Self-learning System for Detection of Anomalous 1498 SIP Messages", Principles, Systems and Applications of IP 1499 Telecommunications Services and Security for Next 1500 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1501 2008. 1503 [schneier-1] 1504 Schneier, B. and J. Kelsey, "Secure audit logs to support 1505 computer forensics", ACM Transactions on Information and 1506 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1508 Authors' Addresses 1510 Vijay K. Gurbani (editor) 1511 Bell Laboratories, Alcatel-Lucent 1512 1960 Lucent Lane 1513 Naperville, IL 60566 1514 USA 1516 Email: vkg@bell-labs.com 1518 Eric W. Burger (editor) 1519 Georgetown University 1520 USA 1522 Email: eburger@standardstrack.com 1523 URI: http://www.standardstrack.com 1525 Tricha Anjali 1526 Illinois Institute of Technology 1527 316 Siegel Hall 1528 Chicago, IL 60616 1529 USA 1531 Email: tricha@ece.iit.edu 1533 Humberto Abdelnur 1534 INRIA 1535 INRIA - Nancy Grant Est 1536 Campus Scientifique 1537 54506, Vandoeuvre-les-Nancy Cedex 1538 France 1540 Email: Humberto.Abdelnur@loria.fr 1542 Olivier Festor 1543 INRIA 1544 INRIA - Nancy Grant Est 1545 Campus Scientifique 1546 54506, Vandoeuvre-les-Nancy Cedex 1547 France 1549 Email: Olivier.Festor@loria.fr