idnits 2.17.1 draft-ietf-sipclf-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (October 25, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4475' is defined on line 1487, but no explicit reference was found in the text -- 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: April 28, 2011 Georgetown University 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 October 25, 2010 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-04 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 April 28, 2011. 49 Copyright Notice 51 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . 9 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. 384 OPEN ISSUE: 4K limit for mandatory headers. There has been some 385 discussion in the WG mailing list (see 386 http://www.ietf.org/mail-archive/ web/sip-clf/current/msg00238.html) 387 to have a limit for headers. 4K has been mentioned. What are folks 388 thinking here ... is this limit for URIs only? For all headers that 389 are part of SIP CLF? For each header that is part of SIP CLF? For 390 the entire SIP CLF record? 392 The SIP CLF record does not contain any provisions for logging 393 bodies, whether or not the body appears as part of a SIP message, 394 separated by a CRLF, or the body appears as the special hname "body" 395 in a SIP URI. In SIP, bodies can be of arbitrary length and 396 composition, resulting in unwieldy and overtly verbose SIP CLF 397 records. If required, certain aspects of the SIP body can be logged 398 as extension elements; however, whether or not to do so depends on 399 the specific logging implementation. 401 8.1. SIP CLF mandatory fields 403 The following SIP CLF fields are defined as minimal information that 404 MUST appear in any SIP CLF record: 406 Timestamp - Date and time of the request or response represented as 407 the number of seconds and milliseconds since the Unix epoch. 409 Message type - An indicator on whether the SIP message is a request 410 or a response. The allowable values for this field are 'R' (for 411 Request) and 'r' (for response). 413 Directionality - An indicator on whether the SIP message is received 414 by the SIP entity or sent by the SIP entity. The allowable values 415 for this field are 's' (for message sent) and 'r' (for message 416 received). 418 Transport - The transport over which a SIP message is sent or 419 received. The allowable values for the transport are governed by 420 the "transport" production rule in Section 25.1 of RFC3261 421 [RFC3261]. 423 Source-address - The DNS name or IP address of the sender of the SIP 424 message. 426 Source-port - The source port number of the sender of the SIP 427 message. 429 Destination-address - The DNS name or IP address of the recipient of 430 the SIP message. 432 Destination-port - The port number of the recipient of the SIP 433 message. 435 From - The From URI. Whilst one may question the value of the From 436 URI in light of RFC4744 [RFC4474], the From URI, nonetheless, 437 imparts some information. For one, the From tag is important and, 438 in the case of a REGISTER request, the From URI can provide 439 information on whether this was a third-party registration or a 440 first-party one. It is not necessary to log any URI parameters. 442 From-tag - The tag parameter of the From header. 444 To - The To URI. It is not necessary to log any URI parameters. 446 To-tag - The tag parameter of the To header. Note that the tag 447 parameter will be absent in the initial request that forms a 448 dialog. 450 Callid - The Call-ID. 452 CSeq-Method - The method from the CSeq header. 454 CSeq-Number - The number from the CSeq header. 456 R-URI - The Request-URI, including any URI parameters. 458 Status - The SIP response status code. 460 SIP Proxies may fork, creating several client transactions that 461 correlate to a single server transaction. Responses arriving on 462 these client transactions, or new requests (CANCEL, ACK) sent on the 463 client transaction need log file entries that correlate with a server 464 transaction. Similarly, a B2BUA may create one or more client 465 transactions in response to an incoming request. These transactions 466 will require correlation as well. The last two data model elements 467 provide this correlation. 469 Server-Txn - Server transaction identification code - the 470 transaction identifier associated with the server transaction. 471 Implementations can reuse the server transaction identifier (the 472 topmost branch-id of the incoming request, with or without the 473 magic cookie), or they could generate a unique identification 474 string for a server transaction (this identifier needs to be 475 locally unique to the server only.) This identifier is used to 476 correlate ACKs and CANCELs to an INVITE transaction; it is also 477 used to aid in forking as explained later in this section. (See 478 Section 9 for usage.) 480 Client-Txn - Client transaction identification code - this field is 481 used to associate client transactions with a server transaction 482 for forking proxies or B2BUAs. Upon forking, implementations can 483 reuse the value they inserted into the topmost Via header's branch 484 parameter, or they can generate a unique identification string for 485 the client transaction. (See Section 9 for usage.) 487 Finally, the SIP CLF should be extensible such that future SIP 488 methods, headers and bodies can be represented as well. Besides the 489 mandatory fields listed above, any other SIP header that needs to be 490 logged will appear as an ordered pair of header field name and value. 492 This data model applies to all SIP entities --- a UAC, UAS, Proxy, a 493 B2BUA, registrar and redirect server. Note that a B2BUA is a 494 degenerate case of a proxy and as such the SIP CLF fields prescribed 495 for a proxy is equally applicable to the B2BUA. Similarly, 496 registrars and redirect servers are a degenerate case of a UAS, and 497 as such the SIP CLF fields prescribed for a UAS is equally applicable 498 to registrars and redirect servers. 500 The next section specifies the individual SIP CLF data model elements 501 that form a log record for specific instance of a SIP entity. We 502 limit our specification to using the minimum data model elements. It 503 is understood that a SIP CLF record is extensible using extension 504 mechanisms appropriate to the specific representation used to 505 generate the SIP CLF record. This document, however, does not 506 prescribe a specific representation format and it limits the 507 discussion to the mandatory data elements described above. 509 8.2. Mandatory fields and SIP entities 511 Each SIP CLF record MUST consist of all the mandatory data model 512 elements outlined in Section 8.1. This document does not specify a 513 representation of a logging format; it is expected that other 514 documents will do so. Each SIP CLF record MUST contain the mandatory 515 elements shown below: 517 Timestamp, Message type, Directionality, CSeq-Method, 518 CSeq-Number, Transport, R-URI, Destination-address, 519 Destination-port, Source-address, Source-port, To, 520 To-tag, From, From-tag, Call-ID, Status, Server-Txn, 521 Client-Txn 523 Table 1 summarizes how the mandatory fields are logged by a UAC, UAS, 524 or UAC-half, UAS-half of a SIP proxy and B2BUA. In the table below: 526 R: implies that the field is logged when a request is handled by that 527 SIP entity. 529 r: implies that the field is logged when a response is handled by 530 that SIP entity. 532 -: implies that the field is not applicable to that SIP entity. 534 +---------------------+-----+-----+----------+----------+ 535 | | UAC | UAS | UAS-half | UAC-half | 536 +---------------------+-----+-----+----------+----------+ 537 | Timestamp | R,r | R,r | R,r | R,r | 538 | Message type | R,r | R,r | R,r | R,r | 539 | Directionality | R,r | R,r | R,r | R,r | 540 | Transport | R,r | R,r | R,r | R,r | 541 | CSeq-Method | R,r | R,r | R,r | R,r | 542 | CSeq-Number | R,r | R,r | R,r | R,r | 543 | R-URI | R | R | R | R | 544 | Destination-address | R,r | R,r | R,r | R,r | 545 | Destination-port | R,r | R,r | R,r | R,r | 546 | Source-address | R,r | R,r | R,r | R,r | 547 | Source-port | R,r | R,r | R,r | R,r | 548 | To | R,r | R,r | R,r | R,r | 549 | To-tag | R,r | R,r | R,r | R,r | 550 | From | R,r | R,r | R,r | R,r | 551 | From-tag | R,r | R,r | R,r | R,r | 552 | Call-ID | R,r | R,r | R,r | R,r | 553 | Status | r | r | r | r | 554 | Server-Txn | - | R,r | R,r | R,r | 555 | Client-Txn | R,r | - | r | R,r | 556 +---------------------+-----+-----+----------+----------+ 558 SIP CLF fields logged per entity 560 Table 1 562 9. Examples 564 The examples use only the mandatory data elements defined in 565 Section 8.1. Extension elements are not considered. The examples 566 below use the template defined in Section 8.2 when logging a SIP CLF 567 record. When a given mandatory field is not applicable to a SIP 568 entity as determined by Table 1, we use the horizontal dash ("-") to 569 represent it. 571 There are five principals in the examples below. They are Alice, the 572 initiator of requests. Alice's user agent uses IPv4 address 573 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 574 on their way to Bob, the recipient of the requests. P1 also acts as 575 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 576 5060. Bob has two instances of his user agent running on different 577 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 578 5060 and the second instance uses an IPv6 address of 2001:db8::9, 579 port 5060. P2 is a proxy responsible for Bob's domain. Table 2 580 summarizes these addresses. 582 +-------------------+--------------------+-------------------+ 583 | Principal | IP:port | Host/Domain name | 584 +-------------------+--------------------+-------------------+ 585 | Alice | 198.51.100.1:5060 | alice.example.com | 586 | P1 | 198.51.100.10:5060 | p1.example.com | 587 | P2 | 203.0.113.200:5060 | p2.example.net | 588 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 589 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 590 +-------------------+--------------------+-------------------+ 592 Principal to IP address asignment 594 Table 2 596 Illustrative examples of SIP CLF follow. 598 9.1. UAC registration 600 Alice sends a registration registrar P1 and receives a 2xx-class 601 response. The register requests causes Alice's UAC to produce a log 602 record shown below. The mandatory data model elements correspond to 603 those listed in Table 1. 605 Timestamp: 1275930743.699 606 Message Type: R 607 Directionality: s 608 Transport: udp 609 CSeq-Number: 1 610 CSeq-Method: REGISTER 611 R-URI: sip:example.com 612 Destination-address: 198.51.100.10 613 Destination-port: 5060 614 Source-address: 198.51.100.1 615 Source-port: 5060 616 To: sip:example.com 617 To-tag: - 618 From: sip:alice@example.com 619 From-tag: 76yhh 620 Call-ID: f81-d4-f6@example.com 621 Status: - 622 Server-Txn: - 623 Client-Txn: c-tr-1 625 After some time, Alice's UAC will receive a response from the 626 registrar. The response causes Alice's agent to produce a log record 627 shown below. The mandatory data elements correspond to those listed 628 in Table 1. 630 Timestamp: 1275930744.100 631 Message Type: r 632 Directionality: r 633 Transport: udp 634 CSeq-Number: 1 635 CSeq-Method: REGISTER 636 R-URI: - 637 Destination-address: 198.51.100.1 638 Destination-port: 5060 639 Source-address: 198.51.100.10 640 Source-port: 5060 641 To: sip:example.com 642 To-tag: reg-1-xtr 643 From: sip:alice@example.com 644 From-tag: 76yhh 645 Call-ID: f81-d4-f6@example.com 646 Status: 100 647 Server-Txn: - 648 Client-Txn: c-tr-1 650 9.2. Direct call between Alice and Bob 652 In this example, Alice sends a session initiation request directly to 653 Bob's agent (instance 1.) Bob's agent accepts the session 654 invitation. We first present the SIP CLF logging from Alice's UAC 655 point of view. In line 1, Alice's user agent sends out the INVITE. 656 Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" 657 response (line 3). Upon the receipt of the 2xx-class response, 658 Alice's user agent sends out an ACK request (line 4). 660 Timestamp: 1275930743.699 661 Message Type: R 662 Directionality: s 663 Transport: udp 664 CSeq-Number: 32 665 CSeq-Method: INVITE 666 R-URI: sip:bob@bob1.example.net 667 Destination-address: 203.0.113.1 668 Destination-port: 5060 669 Source-address: 198.51.100.1 670 Source-port: 5060 671 To: sip:bob@example.net 672 To-tag: - 673 From: sip:alice@example.com 674 From-tag: 76yhh 675 Call-ID: f82-d4-f7@example.com 676 Status: - 677 Server-Txn: - 678 Client-Txn: c-1-xt6 680 Timestamp: 1275930745.002 681 Message Type: r 682 Directionality: r 683 Transport: udp 684 CSeq-Number: 32 685 CSeq-Method: INVITE 686 R-URI: - 687 Destination-address: 198.51.1.100 688 Destination-port: 5060 689 Source-address: 203.0.113.1 690 Source-port: 5060 691 To: sip:bob@example.net 692 To-tag: b-in6-iu 693 From: sip:alice@example.com 694 From-tag: 76yhh 695 Call-ID: f82-d4-f7@example.com 696 Status: 180 697 Server-Txn: - 698 Client-Txn: c-1-xt6 700 Timestamp: 1275930746.100 701 Message Type: r 702 Directionality: r 703 Transport: udp 704 CSeq-Number: 32 705 CSeq-Method: INVITE 706 R-URI: - 707 Destination-address: 198.51.1.100 708 Destination-port: 5060 709 Source-address: 203.0.113.1 710 Source-port: 5060 711 To: sip:bob@example.net 712 To-tag: b-in6-iu 713 From: sip:alice@example.com 714 From-tag: 76yhh 715 Call-ID: f82-d4-f7@example.com 716 Status: 200 717 Server-Txn: - 718 Client-Txn: c-1-xt6 720 Timestamp: 1275930746.120 721 Message Type: R 722 Directionality: s 723 Transport: udp 724 CSeq-Number: 32 725 CSeq-Method: ACK 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@example.net 732 To-tag: b-in6-iu 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 9.3. Single downstream branch call 742 In this example, Alice sends a session invitation request to Bob 743 through proxy P1, which inserts a Record-Route header causing 744 subsequent requests between Alice and Bob to traverse the proxy. The 745 SIP CLF log records correspond to the viewpoint of P1. The line 746 numbers below refer to Figure 1 748 Alice P1 Bob 749 +---INV--------->| | Line 1 750 | | | 751 |<---------100---+ | Line 2 752 | | | 753 | +---INV-------->| Line 3 754 | | | 755 | |<--------100---+ Line 4 756 | | | 757 | |<--------180---+ Line 5 758 | | | 759 |<---------180---+ | Line 6 760 | | | 761 | |<--------200---+ Line 7 762 | | | 763 |<---------200---+ | Line 8 764 | | | 765 +---ACK--------->| | Line 9 766 | | | 767 | |---ACK-------->| Line 10 769 Figure 1: Simple proxy-aided call flow 771 1 Timestamp: 1275930743.699 772 Message Type: R 773 Directionality: r 774 Transport: udp 775 CSeq-Number: 43 776 CSeq-Method: INVITE 777 R-URI: sip:bob@example.net 778 Destination-address: 198.51.100.10 779 Destination-port: 5060 780 Source-address: 198.51.100.1 781 Source-port: 5060 782 To: sip:bob@example.net 783 To-tag: - 784 From: sip:alice@example.com 785 From-tag: al-1 786 Call-ID: tr-87h@example.com 787 Status: - 788 Server-Txn: s-x-tr 789 Client-Txn: - 791 Note that at this point P1 has created a server transaction 792 identification code and populated the SIP CLF field Server-Txn with 793 it. P1 has not yet created a client transaction identification code, 794 thus Client-Txn contains a "-". 796 2 Timestamp: 1275930744.001 797 Message Type: r 798 Directionality: s 799 Transport: udp 800 CSeq-Number: 43 801 CSeq-Method: INVITE 802 R-URI: - 803 Destination-address: 198.51.100.1 804 Destination-port: 5060 805 Source-address: 198.51.100.10 806 Source-port: 5060 807 To: sip:bob@example.net 808 To-tag: - 809 From: sip:alice@example.com 810 From-tag: al-1 811 Call-ID: tr-87h@example.com 812 Status: 100 813 Server-Txn: s-x-tr 814 Client-Txn: - 816 In line 3 below, P1 has created a client transaction identification 817 code for the downstream branch and populated the SIP CLF field 818 Client-Txn. 820 3 Timestamp: 1275930744.998 821 Message Type: R 822 Directionality: s 823 Transport: udp 824 CSeq-Number: 43 825 CSeq-Method: INVITE 826 R-URI: sip:bob@bob1.example.net 827 Destination-address: 203.0.113.1 828 Destination-port: 5060 829 Source-address: 198.51.100.10 830 Source-port: 5060 831 To: sip:bob@example.net 832 To-tag: - 833 From: sip:alice@example.com 834 From-tag: al-1 835 Call-ID: tr-87h@example.com 836 Status: - 837 Server-Txn: s-x-tr 838 Client-Txn: c-x-tr 840 4 Timestamp: 1275930745.200 841 Message Type: r 842 Directionality: r 843 Transport: udp 844 CSeq-Number: 43 845 CSeq-Method: INVITE 846 R-URI: - 847 Destination-address: 198.51.100.10 848 Destination-port: 5060 849 Source-address: 203.0.113.1 850 Source-port: 5060 851 To: sip:bob@example.net 852 To-tag: b1-1 853 From: sip:alice@example.com 854 From-tag: al-1 855 Call-ID: tr-87h@example.com 856 Status: 100 857 Server-Txn: s-x-tr 858 Client-Txn: c-x-tr 860 5 Timestamp: 1275930745.800 861 Message Type: r 862 Directionality: r 863 Transport: udp 864 CSeq-Number: 43 865 CSeq-Method: INVITE 866 R-URI: - 867 Destination-address: 198.51.100.10 868 Destination-port: 5060 869 Source-address: 203.0.113.1 870 Source-port: 5060 871 To: sip:bob@example.net 872 To-tag: b1-1 873 From: sip:alice@example.com 874 From-tag: al-1 875 Call-ID: tr-87h@example.com 876 Status: 180 877 Server-Txn: s-x-tr 878 Client-Txn: c-x-tr 880 6 Timestamp: 1275930746.009 881 Message Type: r 882 Directionality: s 883 Transport: udp 884 CSeq-Number: 43 885 CSeq-Method: INVITE 886 R-URI: - 887 Destination-address: 198.51.100.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: b1-1 893 From: sip:alice@example.com 894 From-tag: al-1 895 Call-ID: tr-87h@example.com 896 Status: 180 897 Server-Txn: s-x-tr 898 Client-Txn: c-x-tr 900 7 Timestamp: 1275930747.120 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: 200 917 Server-Txn: s-x-tr 918 Client-Txn: c-x-tr 920 8 Timestamp: 1275930747.300 921 Message Type: r 922 Directionality: s 923 Transport: udp 924 CSeq-Number: 43 925 CSeq-Method: INVITE 926 R-URI: - 927 Destination-address: 198.51.100.1 928 Destination-port: 5060 929 Source-address: 198.51.100.10 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: 200 937 Server-Txn: s-x-tr 938 Client-Txn: c-x-tr 940 9 Timestamp: 1275930749.100 941 Message Type: R 942 Directionality: r 943 Transport: udp 944 CSeq-Number: 43 945 CSeq-Method: ACK 946 R-URI: sip:bob@example.net 947 Destination-address: 198.51.100.10 948 Destination-port: 5060 949 Source-address: 198.51.100.1 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: - 957 Server-Txn: s-x-tr 958 Client-Txn: c-x-tr 960 10 Timestamp: 1275930749.100 961 Message Type: R 962 Directionality: s 963 Transport: udp 964 CSeq-Number: 43 965 CSeq-Method: ACK 966 R-URI: sip:bob@bob1.example.net 967 Destination-address: 203.0.113.1 968 Destination-port: 5060 969 Source-address: 198.51.100.10 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: - 977 Server-Txn: s-x-tr 978 Client-Txn: c-x-tr 980 9.4. Forked call 982 In this example, Alice sends a session invitation to Bob's proxy, P2. 983 P2 forks the session invitation request to two registered endpoints 984 corresponding to Bob's address-of-record. Both endpoints respond 985 with provisional responses. Shortly thereafter, one of Bob's user 986 agent instances accepts the call, causing P2 to send a CANCEL request 987 to the second user agent. P2 does not Record-Route, therefore the 988 subsequent ACK request from Alice to Bob's user agent does not 989 traverse through P2 (and is not shown below.) 991 Figure 2 depicts the call flow. 993 Bob Bob 994 Alice P2 (Instance 1) (Instance 2) 995 +---INV--->| | | Line 1 996 | | | | 997 |<---100---+ | | Line 2 998 | | | | 999 | +---INV--->| | Line 3 1000 | | | | 1001 | +---INV----+-------->| Line 4 1002 | | | | 1003 | |<---100---+ | Line 5 1004 | | | | 1005 | |<---------+---100---+ Line 6 1006 | | | | 1007 | |<---180---+---------+ Line 7 1008 | | | | 1009 |<---180---+ | | Line 8 1010 | | | | 1011 | |<---180---+ | Line 9 1012 | | | | 1013 |<---180---+ | | Line 10 1014 | | | | 1015 | |<---200---+ | Line 11 1016 | | | | 1017 |<---200---+ | | Line 12 1018 | | | | 1019 | +---CANCEL-+-------->| Line 13 1020 | | | | 1021 | |<---------+---487---+ Line 14 1022 | | | | 1023 | +---ACK----+-------->| Line 15 1024 | | | | 1025 | |<---------+---200---+ Line 16 1027 Figure 2: Forked call flow 1029 The SIP CLF log correspond to the viewpoint of P2. The fields logged 1030 are shown below; the line numbers refer to Figure 2. 1032 1 Timestamp: 1275930743.699 1033 Message Type: R 1034 Directionality: r 1035 Transport: udp 1036 CSeq-Number: 43 1037 CSeq-Method: INVITE 1038 R-URI: sip:bob@example.net 1039 Destination-address: 203.0.113.200 1040 Destination-port: 5060 1041 Source-address: 198.51.100.1 1042 Source-port: 5060 1043 To: sip:bob@example.net 1044 To-tag: - 1045 From: sip:alice@example.com 1046 From-tag: a1-1 1047 Call-ID: tr-88h@example.com 1048 Status: - 1049 Server-Txn: s-1-tr 1050 Client-Txn: - 1052 2 Timestamp: 1275930744.001 1053 Message Type: r 1054 Directionality: s 1055 Transport: udp 1056 CSeq-Number: 43 1057 CSeq-Method: INVITE 1058 R-URI: - 1059 Destination-address: 198.51.100.1 1060 Destination-port: 5060 1061 Source-address: 203.0.113.200 1062 Source-port: 5060 1063 To: sip:bob@example.net 1064 To-tag: - 1065 From: sip:alice@example.com 1066 From-tag: a1-1 1067 Call-ID: tr-88h@example.com 1068 Status: 100 1069 Server-Txn: s-1-tr 1070 Client-Txn: - 1072 3 Timestamp: 1275930744.998 1073 Message Type: R 1074 Directionality: s 1075 Transport: udp 1076 CSeq-Number: 43 1077 CSeq-Method: INVITE 1078 R-URI: sip:bob@bob1.example.net 1079 Destination-address: 203.0.113.1 1080 Destination-port: 5060 1081 Source-address: 203.0.113.200 1082 Source-port: 5060 1083 To: sip:bob@example.net 1084 To-tag: - 1085 From: sip:alice@example.com 1086 From-tag: a1-1 1087 Call-ID: tr-88h@example.com 1088 Status: - 1089 Server-Txn: s-1-tr 1090 Client-Txn: c-1-tr 1092 4 Timestamp: 1275930745.500 1093 Message Type: R 1094 Directionality: s 1095 Transport: udp 1096 CSeq-Number: 43 1097 CSeq-Method: INVITE 1098 R-URI: sip:bob@bob2.example.net 1099 Destination-address: [2001:db8::9] 1100 Destination-port: 5060 1101 Source-address: 203.0.113.200 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: c-2-tr 1112 5 Timestamp: 1275930745.800 1113 Message Type: r 1114 Directionality: r 1115 Transport: udp 1116 CSeq-Number: 43 1117 CSeq-Method: INVITE 1118 R-URI: - 1119 Destination-address: 203.0.113.200 1120 Destination-port: 5060 1121 Source-address: 203.0.113.1 1122 Source-port: 5060 1123 To: sip:bob@example.net 1124 To-tag: b1=-1 1125 From: sip:alice@example.com 1126 From-tag: a1-1 1127 Call-ID: tr-88h@example.com 100 1128 Status: 100 1129 Server-Txn: s-1-tr 1130 Client-Txn: c-1-tr 1132 6 Timestamp: 1275930746.100 1133 Message Type: r 1134 Directionality: r 1135 Transport: udp 1136 CSeq-Number: 43 1137 CSeq-Method: INVITE 1138 R-URI: - 1139 Destination-address: 203.0.113.200 1140 Destination-port: udp 1141 Source-address: [2001:db8::9] 1142 Source-port: 5060 1143 To: sip:bob@example.net 1144 To-tag: b2-2 1145 From: sip:alice@example.com 1146 From-tag: a1-1 1147 Call-ID: tr-88h@example.com 1148 Status: 100 1149 Server-Txn: s-1-tr 1150 Client-Txn: c-2-tr 1152 7 Timestamp: 1275930746.700 1153 Message Type: r 1154 Directionality: r 1155 Transport: udp 1156 CSeq-Number: 43 1157 CSeq-Method: INVITE 1158 R-URI: - 1159 Destination-address: 203.0.113.200 1160 Destination-port: udp 1161 Source-address: [2001:db8::9] 1162 Source-port: 5060 1163 To: sip:bob@example.net 1164 To-tag: b2-2 1165 From: sip:alice@example.com 1166 From-tag: a1-1 1167 Call-ID: tr-88h@example.com 1168 Status: 180 1169 Server-Txn: s-1-tr 1170 Client-Txn: c-2-tr 1172 8 Timestamp: 1275930746.990 1173 Message Type: r 1174 Directionality: s 1175 Transport: udp 1176 CSeq-Number: 43 1177 CSeq-Method: INVITE 1178 R-URI: - 1179 Destination-address: 198.51.100.1 1180 Destination-port: 5060 1181 Source-address: 203.0.113.200 1182 Source-port: 5060 1183 To: sip:bob@example.net 1184 To-tag: b2-2 1185 From: sip:alice@example.com 1186 From-tag: a1-1 1187 Call-ID: tr-88h@example.com 1188 Status: 180 1189 Server-Txn: s-1-tr 1190 Client-Txn: c-2-tr 1192 9 Timestamp: 1275930747.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: 5060 1201 Source-address: 203.0.113.1 1202 Source-port: 5060 1203 To: sip:bob@example.net 1204 To-tag: b1-1 1205 From: sip:alice@example.com 1206 From-tag: a1-1 1207 Call-ID: tr-88h@example.com 100 1208 Status: 180 1209 Server-Txn: s-1-tr 1210 Client-Txn: c-1-tr 1212 10 Timestamp: 1275930747.300 1213 Message Type: r 1214 Directionality: s 1215 Transport: udp 1216 CSeq-Number: 43 1217 CSeq-Method: INVITE 1218 R-URI: - 1219 Destination-address: 198.51.100.1 1220 Destination-port: 5060 1221 Source-address: 203.0.113.200 1222 Source-port: 5060 1223 To: sip:bob@example.net 1224 To-tag: b1-1 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 11 Timestamp: 1275930747.800 1233 Message Type: r 1234 Directionality: r 1235 Transport: udp 1236 CSeq-Number: 43 1237 CSeq-Method: INVITE 1238 R-URI: - 1239 Destination-address: 203.0.113.200 1240 Destination-port: 5060 1241 Source-address: 203.0.113.1 1242 Source-port: 5060 1243 To: sip:bob@example.net 1244 To-tag: b1-1 1245 From: sip:alice@example.com 1246 From-tag: a1-1 1247 Call-ID: tr-88h@example.com 100 1248 Status: 200 1249 Server-Txn: s-1-tr 1250 Client-Txn: c-1-tr 1252 12 Timestamp: 1275930748.000 1253 Message Type: r 1254 Directionality: s 1255 Transport: udp 1256 CSeq-Number: 43 1257 CSeq-Method: INVITE 1258 R-URI: - 1259 Destination-address: 198.51.100.1 1260 Destination-port: 5060 1261 Source-address: 203.0.113.200 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 1268 Status: 200 1269 Server-Txn: s-1-tr 1270 Client-Txn: c-1-tr 1272 13 Timestamp: 1275930748.201 1273 Message Type: R 1274 Directionality: s 1275 Transport: udp 1276 CSeq-Number: 43 1277 CSeq-Method: CANCEL 1278 R-URI: sip:bob@bob2.example.net 1279 Destination-address: [2001:db8::9] 1280 Destination-port: 5060 1281 Source-address: 203.0.113.200 1282 Source-port: 5060 1283 To: sip:bob@example.net 1284 To-tag: b2-2 1285 From: sip:alice@example.com 1286 From-tag: a1-1 1287 Call-ID: tr-88h@example.com 1288 Status: - 1289 Server-Txn: s-1-tr 1290 Client-Txn: c-2-tr 1292 14 Timestamp: 1275930748.991 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: udp 1301 Source-address: [2001:db8::9] 1302 Source-port: 5060 1303 To: sip:bob@example.net 1304 To-tag: b2-2 1305 From: sip:alice@example.com 1306 From-tag: a1-1 1307 Call-ID: tr-88h@example.com 1308 Status: 487 1309 Server-Txn: s-1-tr 1310 Client-Txn: c-2-tr 1312 15 Timestamp: 1275930749.455 1313 Message Type: R 1314 Directionality: s 1315 Transport: udp 1316 CSeq-Number: 43 1317 CSeq-Method: ACK 1318 R-URI: sip:bob@bob2.example.net 1319 Destination-address: [2001:db8::9] 1320 Destination-port: 5060 1321 Source-address: 203.0.113.200 1322 Source-port: 5060 1323 To: sip:bob@example.net 1324 To-tag: b2-2 1325 From: sip:alice@example.com 1326 From-tag: a1-1 1327 Call-ID: tr-88h@example.com 1328 Status: - 1329 Server-Txn: s-1-tr 1330 Client-Txn: c-2-tr 1332 16 Timestamp: 1275930750.001 1333 Message Type: r 1334 Directionality: r 1335 Transport: udp 1336 CSeq-Number: 43 1337 CSeq-Method: CANCEL 1338 R-URI: - 1339 Destination-address: 203.0.113.200 1340 Destination-port: udp 1341 Source-address: [2001:db8::9] 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: 200 1349 Server-Txn: s-1-tr 1350 Client-Txn: c-2-tr 1352 The above SIP CLF log makes it easy to search for a specific 1353 transaction or a state of the session. Searching for the string 1354 "c-1-tr" on the log records will readily yield the information that 1355 an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 1356 followed by a 180 and then a 200. The absence of the ACK request 1357 signifies that the ACK was exchanged end-to-end. 1359 Searching on "c-2-tr" yields a more complex scenario of sending an 1360 INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, 1361 the log makes it apparent that the request to 1362 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 1363 response was generated, and that the pending INVITE returned a 487. 1364 The ACK to the final non-2xx response and a 200 to the CANCEL request 1365 complete the exchange on that branch. 1367 10. Security Considerations 1369 A log file by its nature reveals both the state of the entity 1370 producing it and the nature of the information being logged. To the 1371 extent that this state should not be publicly accessible and that the 1372 information is to be considered private, appropriate file and 1373 directory permissions attached to the log file should be used. The 1374 following threats may be considered for the log file while it is 1375 stored: 1377 o An attacker may gain access to view the log file, or may 1378 surreptitiously make a copy of the log file for later viewing; 1379 o An attacker may mount a replay attack by modifying existing 1380 records in the log file or inserting new records; 1381 o An attacker may delete parts of --- or indeed, the whole --- file. 1383 It is outside the scope of this document to specify how to protect 1384 the log file while it is stored on disk. However, operators may 1385 consider using common administrative features such as disk encryption 1386 and securing log files [schneier-1]. Operators may also consider 1387 hardening the machine on which the log files are stored by 1388 restricting physical access to the host as well as restricting access 1389 to the files themselves. 1391 In the worst case, public access to the SIP log file provides the 1392 same information that an adversary can gain using network sniffing 1393 tools (assuming that the SIP traffic is in clear text.) If all SIP 1394 traffic on a network segment is encrypted, then as noted above, 1395 special attention must be directed to the file and directory 1396 permissions associated with the log file to preserve privacy such 1397 that only a privileged user can access the contents of the log file. 1399 Transporting SIP CLF files across the network pose special challenges 1400 as well. The following threats may be considered for transferring 1401 log files or while transferring individual log records: 1403 o An attacker may view the records; 1404 o An attacker may modify the records in transit or insert previously 1405 captured records into the stream; 1406 o An attacker may remove records in transit, or may stage a man- in- 1407 the-middle attack to deliver a partially or entirely falsified log 1408 file. 1410 It is also outside the scope of this document to specify protection 1411 methods for log files or log records that are being transferred 1412 between hosts. However, operators may consider using common security 1413 protocols described in [RFC3552] to transfer log files or individual 1414 records. Alternatively, the log file may be transferred through bulk 1415 methods that also guarantees integrity, or at least detects and 1416 alerts to modification attempts. 1418 The SIP CLF represents the minimum fields that lend themselves to 1419 trend analysis and serve as information that may be deemed useful. 1420 Other formats can be defined that include more headers (and the body) 1421 from Section 8.1. However, where to draw a judicial line regarding 1422 the inclusion of non-mandatory headers can be challenging. Clearly, 1423 the more information a SIP entity logs, the longer time the logging 1424 process will take, the more disk space the log entry will consume, 1425 and the more potentially sensitive information could be breached. 1426 Therefore, adequate tradeoffs should be taken in account when logging 1427 more fields than the ones recommended in Section 8.1. 1429 Implementers need to pay particular attention to buffer handling when 1430 reading or writing log files. SIP CLF entries can be unbounded in 1431 length. It would be reasonable for a full dump of a SIP message to 1432 be thousands of octets long. This is of particular importance to CLF 1433 log parsers, as a SIP CLF log writers may add one or more extension 1434 fields to the message to be logged. 1436 11. Operational guidance 1438 SIP CLF log files will take up substantive amount of disk space 1439 depending on traffic volume at a processing entity and the amount of 1440 information being logged. As such, any enterprise using SIP CLF 1441 should establish operational procedures for file rollovers as 1442 appropriate to the needs of the organization. 1444 Listing such operational guidelines in this document is out of scope 1445 for this work. 1447 12. IANA Considerations 1449 This document does not require any considerations from IANA. 1451 13. Acknowledgments 1453 Members of the sipping, dispatch, ipfix and syslog working groups 1454 provided invaluable input to the formulation of the draft. These 1455 include Benoit Claise, Spencer Dawkins, John Elwell, David 1456 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1457 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Simon Perreault, Adam 1458 Roach, Dan Romascanu, Robert Sparks, Brian Trammell, Dale Worley, 1459 Theo Zourzouvillys and others that we have undoubtedly, but 1460 inadvertently, missed. 1462 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1463 Salgueiro helped tremendously in discussions related to arriving at 1464 the beginnings of a data model. 1466 14. References 1467 14.1. Normative References 1469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1470 Requirement Levels", BCP 14, RFC 2119, March 1997. 1472 14.2. Informative References 1474 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1475 A., Peterson, J., Sparks, R., Handley, M., and E. 1476 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1477 June 2002. 1479 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1480 Text on Security Considerations", BCP 72, RFC 3552, 1481 July 2003. 1483 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1484 Authenticated Identity Management in the Session 1485 Initiation Protocol (SIP)", RFC 4474, August 2006. 1487 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 1488 and H. Schulzrinne, "Session Initiation Protocol (SIP) 1489 Torture Test Messages", RFC 4475, May 2006. 1491 [rieck2008] 1492 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1493 Muller, "A Self-learning System for Detection of Anomalous 1494 SIP Messages", Principles, Systems and Applications of IP 1495 Telecommunications Services and Security for Next 1496 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1497 2008. 1499 [schneier-1] 1500 Schneier, B. and J. Kelsey, "Secure audit logs to support 1501 computer forensics", ACM Transactions on Information and 1502 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1504 Authors' Addresses 1506 Vijay K. Gurbani (editor) 1507 Bell Laboratories, Alcatel-Lucent 1508 1960 Lucent Lane 1509 Naperville, IL 60566 1510 USA 1512 Email: vkg@bell-labs.com 1513 Eric W. Burger (editor) 1514 Georgetown University 1515 USA 1517 Email: eburger@standardstrack.com 1518 URI: http://www.standardstrack.com 1520 Tricha Anjali 1521 Illinois Institute of Technology 1522 316 Siegel Hall 1523 Chicago, IL 60616 1524 USA 1526 Email: tricha@ece.iit.edu 1528 Humberto Abdelnur 1529 INRIA 1530 INRIA - Nancy Grant Est 1531 Campus Scientifique 1532 54506, Vandoeuvre-les-Nancy Cedex 1533 France 1535 Email: Humberto.Abdelnur@loria.fr 1537 Olivier Festor 1538 INRIA 1539 INRIA - Nancy Grant Est 1540 Campus Scientifique 1541 54506, Vandoeuvre-les-Nancy Cedex 1542 France 1544 Email: Olivier.Festor@loria.fr