idnits 2.17.1 draft-ietf-sipclf-problem-statement-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2011) is 4546 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-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: May 17, 2012 Georgetown University 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 November 14, 2011 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-08 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 user agents, proxies, 30 registrars, 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 May 17, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 13 80 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 15 81 9.3. Single downstream branch call . . . . . . . . . . . . . . 16 82 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 84 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 31 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 88 14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 89 14.2. Informative References . . . . . . . . . . . . . . . . . . 32 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. Some log records are, in essence, a summary 113 of 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. A typical deployment of SIP 155 in an enterprise will consist of SIP entities from multiple vendors. 156 Currently, if these entities are capable of producing a log file of 157 the transactions being handled by them, the log files are produced in 158 a proprietary format. The result of multiplicity of the log file 159 formats is the inability of the support staff to easily trace a call 160 from one entity to another, or even to craft common tools that will 161 perform trend analysis, debugging and troubleshooting problems 162 uniformly across the SIP entities of multiple vendors. 164 SIP does not currently have a CLF format and this document serves to 165 provide the rationale to establish a SIP CLF and identifies the 166 required minimal information that must appear in any SIP CLF record. 168 4. What SIP CLF is and what it is not 170 The SIP CLF is a standardized manner of producing a log file. This 171 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 172 The SIP CLF is simply an easily digestible log of currently occurring 173 events and past transactions. It contains enough information to 174 allow humans and automata to derive relationships between discrete 175 transactions handled at a SIP entity or to search for a certain 176 dialog or a related set of transactions. 178 The SIP CLF is amenable to quick parsing (i.e., well-delimited 179 fields) and it is platform and operating system neutral. 181 The SIP CLF is amenable to easy parsing and lends itself well to 182 creating other innovative tools. 184 The SIP CLF is not a billing tool. It is not expected that 185 enterprises will bill customers based on SIP CLF. The SIP CLF 186 records events at the signaling layer only and does not attempt to 187 correlate the veracity of these events with the media layer. Thus, 188 it cannot be used to trigger customer billing. 190 The SIP CLF is not a quality of service (QoS) measurement tool. If 191 QoS is defined as measuring the mean opinion score (MOS) of the 192 received media, then SIP CLF does not aid in this task since it does 193 not summarize events at the media layer. 195 5. Alternative approaches to SIP CLF 197 It is perhaps tempting to consider other approaches --- which though 198 not standardized, are in wide enough use in networks today --- to 199 determine whether or not a SIP CLF would benefit a SIP network 200 consisting of multi-vendor products. The two existing approaches 201 that approximate what SIP CLF does are Call Detail Records (CDRs) and 202 Wireshark packet sniffing. 204 5.1. SIP CLF and CDRs 206 CDRs are used in operator networks widely and with the adoption of 207 SIP, standardization bodies such as 3GPP have subsequently defined 208 SIP-related CDRs as well. Today, CDRs are used to implement the 209 functionality approximated by SIP CLF, however, there are important 210 differences. 212 One, SIP CLF operates natively at the transaction layer and maintains 213 enough information in the information elements being logged that 214 dialog-related data can be subsequently derived from the transaction 215 logs. Thus, esoteric SIP fields and parameters like the To header, 216 including tags; the From header, including tags, the CSeq number, 217 etc. are logged in SIP CLF. By contrast, a CDR is used mostly for 218 charging and thus saves information to facilitate that very aspect. 219 A CDR will most certainly log the public user identification of a 220 party requesting a service (which may not correspond to the From 221 header) and the public user identification of the party called party 222 (which may not correspond to the To header.) Furthermore, the 223 sequence numbers maintained by the CDR may not correspond to the SIP 224 CSeq header. Thus it will be hard to piece together the state of a 225 dialog through a sequence of CDR records. 227 Two, a CDR record will, in all probability, be generated at a SIP 228 entity performing some form of proxy-like functionality of a B2BUA 229 providing some service. By contrast, SIP CLF is light- weight enough 230 that it can be generated by a canonical SIP user agent server and 231 user agent client as well, including those that execute on resource 232 constrained devices (mobile phones). 234 Finally, SIP is also being deployed outside of operator- managed VoIP 235 networks. Universities, research laboratories, and small-to-medium 236 size companies are deploying SIP-based VoIP solutions on networks 237 owned and managed by them. Much of the latter constituencies will 238 not have an interest in generating CDRs, but they will like to have a 239 concise representation of the messages being handled by the SIP 240 entities in a common format. 242 5.2. SIP CLF and Wireshark packet capture 244 Wireshark is a popular raw packet capture tool. It contains filters 245 that can understand SIP at the protocol level and break down a 246 captured message into its individual header components. While 247 Wireshark is appropriate to capture and view discrete SIP messages, 248 it does not suffice to serve in the same capacity as SIP CLF for two 249 reasons. 251 First, all SIP entities that need to save SIP CLF records would 252 require a Wireshark library for different operating systems and 253 configurations to link into. Second, and more importantly, if the 254 SIP messages are exchanged over a TLS-oriented transport, Wireshark 255 will be unable to decrypt them and render them as individual SIP 256 headers. 258 6. Motivation and use cases 260 As SIP becomes pervasive in multiple business domains and ubiquitous 261 in academic and research environments, it is beneficial to establish 262 a CLF for the following reasons: 264 Common reference for interpreting events: In a laboratory 265 environment or an enterprise service offering there will typically 266 be SIP entities from multiple vendors participating in routing 267 requests. Absent a CLF format, each entity will produce output 268 records in a native format making it hard to establish commonality 269 for tools that operate on the log file. 271 Writing common tools: A CLF format allows independent tool providers 272 to craft tools and applications that interpret the CLF data to 273 produce insightful trend analysis and detailed traffic reports. 274 The format should be such that it retains the ability to be read 275 by humans and processed using traditional Unix text processing 276 tools. 278 Session correlation across diverse processing elements: In 279 operational SIP networks, a request will typically be processed by 280 more than one SIP server. A SIP CLF will allow the network 281 operator to trace the progression of the request (or a set of 282 requests) as they traverse through the different servers to 283 establish a concise diagnostic trail of a SIP session. 285 Note that tracing the request through a set of servers is 286 considerably less challenging if all the servers belong to the 287 same administrative domain. 289 Message correlation across transactions: A SIP CLF can enable a 290 quick lookup of all messages that comprise a transaction (e.g., 291 "Find all messages corresponding to server transaction X, 292 including all forked branches.") 294 Message correlation across dialogs: A SIP CLF can correlate 295 transactions that comprise a dialog (e.g., "Find all messages for 296 dialog created by Call-ID C, From tag F and To tag T.") 298 Trend analysis: A SIP CLF allows an administrator to collect data 299 and spot patterns or trends in the information (e.g., "What is the 300 domain where the most sessions are routed to between 9:00 AM and 301 12:00 PM?") 303 Train anomaly detection systems: A SIP CLF will allow for the 304 training of anomaly detection systems that once trained can 305 monitor the CLF file to trigger an alarm on the subsequent 306 deviations from accepted patterns in the data set. Currently, 307 anomaly detection systems monitor the network and parse raw 308 packets that comprise a SIP message -- a process that is 309 unsuitable for anomaly detection systems [rieck2008]. With all 310 the necessary event data at their disposal, network operations 311 managers and information technology operation managers are in a 312 much better position to correlate, aggregate, and prioritize log 313 data to maintain situational awareness. 315 Testing: A SIP CLF allows for automatic testing of SIP equipment by 316 writing tools that can parse a SIP CLF file to ensure behavior of 317 a device under test. 319 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 320 SIP entity (e.g., "How long did it take to generate a final 321 response for the INVITE associated with Call-ID X?") 323 Offline analysis: A SIP CLF allows for offline analysis of the data 324 gathered. Once a SIP CLF file has been generated, it can be 325 transported (subject to the security considerations in Section 10) 326 to a host with appropriate computing resources to perform 327 subsequent analysis. 329 Real-time monitoring: A SIP CLF allows administrators to visually 330 notice the events occurring at a SIP entity in real-time providing 331 accurate situational awareness. 333 7. Challenges in establishing a SIP CLF 335 Establishing a CLF for SIP is a challenging task. The behavior of a 336 SIP entity is more complex when compared to the equivalent HTTP 337 entity. 339 Base protocol services such as parallel or serial forking elicit 340 multiple final responses. Ensuing delays between sending a request 341 and receiving a final response all add complexity when considering 342 what fields should comprise a CLF and in what manner. Furthermore, 343 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 344 and these transactions may arrive at a varying inter-arrival rate at 345 a proxy. For example, the BYE transaction usually arrives much after 346 the corresponding INVITE transaction was received, serviced and 347 expunged from the transaction list. Nonetheless, it is advantageous 348 to relate these transactions such that automata or a human monitoring 349 the log file can construct a set consisting of related transactions. 351 ACK requests in SIP need careful consideration as well. In SIP, an 352 ACK is a special method that is associated with an INVITE only. It 353 does not require a response, and furthermore, if it is acknowledging 354 a non-2xx response, then the ACK is considered part of the original 355 INVITE transaction. If it is acknowledging a 2xx-class response, 356 then the ACK is a separate transaction consisting of a request only 357 (i.e., there is not a response for an ACK request.) CANCEL is 358 another method that is tied to an INVITE transaction, but unlike ACK, 359 the CANCEL request elicits a final response. 361 While most requests elicit a response immediately, the INVITE request 362 in SIP can pend at a proxy as it forks branches downstream or at a 363 user agent server while it alerts the user. RFC 3261 [RFC3261] 364 instructs the server transaction to send a 1xx-class provisional 365 response if a final response is delayed for more than 200 ms. A SIP 366 CLF log file needs to include such provisional responses because they 367 help train automata associated with anomaly detection systems and 368 provide some positive feedback for a human observer monitoring the 369 log file. 371 Finally, beyond supporting native SIP actors such as proxies, 372 registrars, redirect servers, and user agent servers (UAS), it is 373 beneficial to derive a CLF format that supports back-to-back user 374 agent (B2BUA) behavior, which may vary considerably depending on the 375 specific nature of the B2BUA. 377 8. Data model 379 The minimal SIP CLF fields are defined below. Some of these fields 380 contain URIs. If the URI contains an escaped character (""%" HEX 381 HEX" mechanism), the escaped character MUST be logged as received. 382 The maximum size (in number of bytes) for a SIP CLF field is 4096 383 bytes. This limit is the same regardless of whether the SIP CLF 384 field is a meta-field (see "Timestamp" and "Directionality" defined 385 below) or a normal SIP header. If the body of the SIP message is to 386 be logged, it MUST conform to this limit as well. 388 Logging bodies of a SIP message is left optional (and is not shown in 389 the examples of Section 9). If the body is to be logged, the 390 specific syntax and semantics used to log bodies MUST be defined by 391 the specific representation format used to generate the SIP CLF 392 record. 394 The data model supports extensibility by providing the capability to 395 log "optional fields". Optional fields are those SIP header fields 396 (or field components) that are not mandatory (see Section 8.1 for the 397 mandatory field list). Optional fields may contain SIP headers or 398 other elements present in a SIP message (for example, the Reason- 399 Phrase element from the Status-Line production rule in RFC 3261 400 [RFC3261]). Optional fields may also contain additional information 401 that a particular vendor desires to log. The specific syntax and 402 semantics to be accorded to optional fields MUST be defined by the 403 specific representation format used to generate the SIP CLF record. 405 Finally, [I-D.ietf-sipclf-format] is an example of a representation 406 format draft that provides an ASCII-based encoding scheme. 408 8.1. SIP CLF mandatory fields 410 The following SIP CLF fields are defined as minimal information that 411 MUST appear in any SIP CLF record: 413 Timestamp - Date and time of the request or response represented as 414 the number of seconds and milliseconds since the Unix epoch. 416 Message type - An indicator on whether the SIP message is a request 417 or a response. The allowable values for this field are 'R' (for 418 Request) and 'r' (for response). 420 Directionality - An indicator on whether the SIP message is received 421 by the SIP entity or sent by the SIP entity. The allowable values 422 for this field are 's' (for message sent) and 'r' (for message 423 received). 425 Transport - The transport over which a SIP message is sent or 426 received. The allowable values for the transport are governed by 427 the "transport" production rule in Section 25.1 of RFC3261 428 [RFC3261]. 430 Source-address - The IPv4 or IPv6 address of the sender of the SIP 431 message. 433 Source-port - The source port number of the sender of the SIP 434 message. 436 Destination-address - The IPv4 or IPv6 address of the recipient of 437 the SIP message. 439 Destination-port - The port number of the recipient of the SIP 440 message. 442 From - The From URI. For the sake of brevity, URI parameters SHOULD 443 NOT be logged. 445 From-tag - The tag parameter of the From header. 447 To - The To URI. For the sake of brevity, URI parameters SHOULD NOT 448 be logged. 450 To-tag - The tag parameter of the To header. Note that the tag 451 parameter will be absent in the initial request that forms a 452 dialog. 454 Callid - The Call-ID. 456 CSeq-Method - The method from the CSeq header. 458 CSeq-Number - The number from the CSeq header. 460 R-URI - The Request-URI, including any URI parameters. 462 Status - The SIP response status code. 464 SIP Proxies may fork, creating several client transactions that 465 correlate to a single server transaction. Responses arriving on 466 these client transactions, or new requests (CANCEL, ACK) sent on the 467 client transaction need log file entries that correlate with a server 468 transaction. Similarly, a B2BUA may create one or more client 469 transactions in response to an incoming request. These transactions 470 will require correlation as well. The last two data model elements 471 provide this correlation. 473 Server-Txn - Server transaction identification code - the 474 transaction identifier associated with the server transaction. 475 Implementations can reuse the server transaction identifier (the 476 topmost branch-id of the incoming request, with or without the 477 magic cookie), or they could generate a unique identification 478 string for a server transaction (this identifier needs to be 479 locally unique to the server only.) This identifier is used to 480 correlate ACKs and CANCELs to an INVITE transaction; it is also 481 used to aid in forking as explained later in this section. (See 482 Section 9 for usage.) 484 Client-Txn - Client transaction identification code - this field is 485 used to associate client transactions with a server transaction 486 for forking proxies or B2BUAs. Upon forking, implementations can 487 reuse the value they inserted into the topmost Via header's branch 488 parameter, or they can generate a unique identification string for 489 the client transaction. (See Section 9 for usage.) 491 This data model applies to all SIP entities --- a UAC, UAS, Proxy, a 492 B2BUA, registrar and redirect server. The SIP CLF fields prescribed 493 for a proxy are equally applicable to the B2BUA. Similarly, the SIP 494 CLF fields prescribed for a UAS are equally applicable to registrars 495 and redirect servers. 497 The next section specifies the individual SIP CLF data model elements 498 that form a log record for specific instance of a SIP entity. It is 499 understood that a SIP CLF record is extensible using extension 500 mechanisms appropriate to the specific representation used to 501 generate the SIP CLF record. This document, however, does not 502 prescribe a specific representation format and it limits the 503 discussion to the mandatory data elements described above. 505 8.2. Mandatory fields and SIP entities 507 Each SIP CLF record MUST consist of all the mandatory data model 508 elements outlined in Section 8.1. This document does not specify a 509 representation of a logging format; it is expected that other 510 documents will do so. Each SIP CLF record MUST contain the mandatory 511 elements shown below: 513 Timestamp, Message type, Directionality, CSeq-Method, 514 CSeq-Number, Transport, R-URI, Destination-address, 515 Destination-port, Source-address, Source-port, To, 516 To-tag, From, From-tag, Call-ID, Status, Server-Txn, 517 Client-Txn 519 In the following cases, an element will not have an appropriate value 520 to provide for one of these fields, even though the field itself is 521 mandatory and must appear in the SIP CLF record. For these cases, 522 the representation document MUST define how to represent such "not 523 applicable" values. For example, the R-URI field is not applicable 524 when logging a response, the Status field is not applicable when 525 logging a request, the To-tag is not known when a request is first 526 sent out, etc. 528 The Client-Txn field is always applicable to a UAC. The Server- Txn 529 field does not apply to a UAC unless the element is also acting as a 530 UAS, and the message associated to this log record corresponds to a 531 message handled by that UAS. For instance, a proxy forwarding a 532 request will populate both the Client-Txn and Server-Txn fields in 533 the record corresponding to the forwarded request. 535 The Server-Txn field is always applicable to a UAS. The Client-Txn 536 field does not apply to a UAS unless the element is also acting as a 537 UAC, and the message associated to this log record corresponds to a 538 message handled by that UAC. For instance, a proxy forwarding a 539 response will populate both the Server-Txn and Client-Txn fields in 540 the record corresponding to the forwarded response. However, a proxy 541 would only populate the Client-Txn field when creating a log record 542 corresponding to a request. 544 9. Examples 546 The examples use only the mandatory data elements defined in 547 Section 8.1. Extension elements are not considered. When a given 548 mandatory field is not applicable to a SIP entity, we use the 549 horizontal dash ("-") to represent it. 551 There are five principals in the examples below. They are Alice, the 552 initiator of requests. Alice's user agent uses IPv4 address 553 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 554 on their way to Bob, the recipient of the requests. P1 also acts as 555 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 556 5060. Bob has two instances of his user agent running on different 557 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 558 5060 and the second instance uses an IPv6 address of 2001:db8::9, 559 port 5060. P2 is a proxy responsible for Bob's domain. Table 1 560 summarizes these addresses. 562 +-------------------+--------------------+-------------------+ 563 | Principal | IP:port | Host/Domain name | 564 +-------------------+--------------------+-------------------+ 565 | Alice | 198.51.100.1:5060 | alice.example.com | 566 | P1 | 198.51.100.10:5060 | p1.example.com | 567 | P2 | 203.0.113.200:5060 | p2.example.net | 568 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 569 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 570 +-------------------+--------------------+-------------------+ 572 Principal to IP address asignment 574 Table 1 576 Illustrative examples of SIP CLF follow. 578 9.1. UAC registration 580 Alice sends a registration registrar P1 and receives a 2xx-class 581 response. The register requests causes Alice's UAC to produce a log 582 record shown below. 584 Timestamp: 1275930743.699 585 Message Type: R 586 Directionality: s 587 Transport: udp 588 CSeq-Number: 1 589 CSeq-Method: REGISTER 590 R-URI: sip:example.com 591 Destination-address: 198.51.100.10 592 Destination-port: 5060 593 Source-address: 198.51.100.1 594 Source-port: 5060 595 To: sip:example.com 596 To-tag: - 597 From: sip:alice@example.com 598 From-tag: 76yhh 599 Call-ID: f81-d4-f6@example.com 600 Status: - 601 Server-Txn: - 602 Client-Txn: c-tr-1 604 After some time, Alice's UAC will receive a response from the 605 registrar. The response causes Alice's agent to produce a log record 606 shown below. 608 Timestamp: 1275930744.100 609 Message Type: r 610 Directionality: r 611 Transport: udp 612 CSeq-Number: 1 613 CSeq-Method: REGISTER 614 R-URI: - 615 Destination-address: 198.51.100.1 616 Destination-port: 5060 617 Source-address: 198.51.100.10 618 Source-port: 5060 619 To: sip:example.com 620 To-tag: reg-1-xtr 621 From: sip:alice@example.com 622 From-tag: 76yhh 623 Call-ID: f81-d4-f6@example.com 624 Status: 100 625 Server-Txn: - 626 Client-Txn: c-tr-1 628 9.2. Direct call between Alice and Bob 630 In this example, Alice sends a session initiation request directly to 631 Bob's agent (instance 1.) Bob's agent accepts the session 632 invitation. We first present the SIP CLF logging from Alice's UAC 633 point of view. In line 1, Alice's user agent sends out the INVITE. 634 Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" 635 response (line 3). Upon the receipt of the 2xx-class response, 636 Alice's user agent sends out an ACK request (line 4). 638 Timestamp: 1275930743.699 639 Message Type: R 640 Directionality: s 641 Transport: udp 642 CSeq-Number: 32 643 CSeq-Method: INVITE 644 R-URI: sip:bob@bob1.example.net 645 Destination-address: 203.0.113.1 646 Destination-port: 5060 647 Source-address: 198.51.100.1 648 Source-port: 5060 649 To: sip:bob@bob1.example.net 650 To-tag: - 651 From: sip:alice@example.com 652 From-tag: 76yhh 653 Call-ID: f82-d4-f7@example.com 654 Status: - 655 Server-Txn: - 656 Client-Txn: c-1-xt6 658 Timestamp: 1275930745.002 659 Message Type: r 660 Directionality: r 661 Transport: udp 662 CSeq-Number: 32 663 CSeq-Method: INVITE 664 R-URI: - 665 Destination-address: 198.51.100.1 666 Destination-port: 5060 667 Source-address: 203.0.113.1 668 Source-port: 5060 669 To: sip:bob@example.net 670 To-tag: b-in6-iu 671 From: sip:alice@example.com 672 From-tag: 76yhh 673 Call-ID: f82-d4-f7@example.com 674 Status: 180 675 Server-Txn: - 676 Client-Txn: c-1-xt6 678 Timestamp: 1275930746.100 679 Message Type: r 680 Directionality: r 681 Transport: udp 682 CSeq-Number: 32 683 CSeq-Method: INVITE 684 R-URI: - 685 Destination-address: 198.51.100.1 686 Destination-port: 5060 687 Source-address: 203.0.113.1 688 Source-port: 5060 689 To: sip:bob@example.net 690 To-tag: b-in6-iu 691 From: sip:alice@example.com 692 From-tag: 76yhh 693 Call-ID: f82-d4-f7@example.com 694 Status: 200 695 Server-Txn: - 696 Client-Txn: c-1-xt6 698 Timestamp: 1275930746.120 699 Message Type: R 700 Directionality: s 701 Transport: udp 702 CSeq-Number: 32 703 CSeq-Method: ACK 704 R-URI: sip:bob@bob1.example.net 705 Destination-address: 203.0.113.1 706 Destination-port: 5060 707 Source-address: 198.51.100.1 708 Source-port: 5060 709 To: sip:bob@example.net 710 To-tag: b-in6-iu 711 From: sip:alice@example.com 712 From-tag: 76yhh 713 Call-ID: f82-d4-f7@example.com 714 Status: - 715 Server-Txn: - 716 Client-Txn: c-1-xt6 718 9.3. Single downstream branch call 720 In this example, Alice sends a session invitation request to Bob 721 through proxy P1, which inserts a Record-Route header causing 722 subsequent requests between Alice and Bob to traverse the proxy. The 723 SIP CLF log records correspond to the viewpoint of P1. The line 724 numbers below refer to Figure 1 726 Alice P1 Bob 727 +---INV--------->| | Line 1 728 | | | 729 |<---------100---+ | Line 2 730 | | | 731 | +---INV-------->| Line 3 732 | | | 733 | |<--------100---+ Line 4 734 | | | 735 | |<--------180---+ Line 5 736 | | | 737 |<---------180---+ | Line 6 738 | | | 739 | |<--------200---+ Line 7 740 | | | 741 |<---------200---+ | Line 8 742 | | | 743 +---ACK--------->| | Line 9 744 | | | 745 | |---ACK-------->| Line 10 747 Figure 1: Simple proxy-aided call flow 749 1 Timestamp: 1275930743.699 750 Message Type: R 751 Directionality: r 752 Transport: udp 753 CSeq-Number: 43 754 CSeq-Method: INVITE 755 R-URI: sip:bob@example.net 756 Destination-address: 198.51.100.10 757 Destination-port: 5060 758 Source-address: 198.51.100.1 759 Source-port: 5060 760 To: sip:bob@example.net 761 To-tag: - 762 From: sip:alice@example.com 763 From-tag: al-1 764 Call-ID: tr-87h@example.com 765 Status: - 766 Server-Txn: s-x-tr 767 Client-Txn: - 769 Note that at this point P1 has created a server transaction 770 identification code and populated the SIP CLF field Server-Txn with 771 it. P1 has not yet created a client transaction identification code, 772 thus Client-Txn contains a "-". 774 2 Timestamp: 1275930744.001 775 Message Type: r 776 Directionality: s 777 Transport: udp 778 CSeq-Number: 43 779 CSeq-Method: INVITE 780 R-URI: - 781 Destination-address: 198.51.100.1 782 Destination-port: 5060 783 Source-address: 198.51.100.10 784 Source-port: 5060 785 To: sip:bob@example.net 786 To-tag: - 787 From: sip:alice@example.com 788 From-tag: al-1 789 Call-ID: tr-87h@example.com 790 Status: 100 791 Server-Txn: s-x-tr 792 Client-Txn: - 794 In line 3 below, P1 has created a client transaction identification 795 code for the downstream branch and populated the SIP CLF field 796 Client-Txn. 798 3 Timestamp: 1275930744.998 799 Message Type: R 800 Directionality: s 801 Transport: udp 802 CSeq-Number: 43 803 CSeq-Method: INVITE 804 R-URI: sip:bob@bob1.example.net 805 Destination-address: 203.0.113.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: - 815 Server-Txn: s-x-tr 816 Client-Txn: c-x-tr 818 4 Timestamp: 1275930745.200 819 Message Type: r 820 Directionality: r 821 Transport: udp 822 CSeq-Number: 43 823 CSeq-Method: INVITE 824 R-URI: - 825 Destination-address: 198.51.100.10 826 Destination-port: 5060 827 Source-address: 203.0.113.1 828 Source-port: 5060 829 To: sip:bob@example.net 830 To-tag: b1-1 831 From: sip:alice@example.com 832 From-tag: al-1 833 Call-ID: tr-87h@example.com 834 Status: 100 835 Server-Txn: s-x-tr 836 Client-Txn: c-x-tr 838 5 Timestamp: 1275930745.800 839 Message Type: r 840 Directionality: r 841 Transport: udp 842 CSeq-Number: 43 843 CSeq-Method: INVITE 844 R-URI: - 845 Destination-address: 198.51.100.10 846 Destination-port: 5060 847 Source-address: 203.0.113.1 848 Source-port: 5060 849 To: sip:bob@example.net 850 To-tag: b1-1 851 From: sip:alice@example.com 852 From-tag: al-1 853 Call-ID: tr-87h@example.com 854 Status: 180 855 Server-Txn: s-x-tr 856 Client-Txn: c-x-tr 858 6 Timestamp: 1275930746.009 859 Message Type: r 860 Directionality: s 861 Transport: udp 862 CSeq-Number: 43 863 CSeq-Method: INVITE 864 R-URI: - 865 Destination-address: 198.51.100.1 866 Destination-port: 5060 867 Source-address: 198.51.100.10 868 Source-port: 5060 869 To: sip:bob@example.net 870 To-tag: b1-1 871 From: sip:alice@example.com 872 From-tag: al-1 873 Call-ID: tr-87h@example.com 874 Status: 180 875 Server-Txn: s-x-tr 876 Client-Txn: c-x-tr 878 7 Timestamp: 1275930747.120 879 Message Type: r 880 Directionality: r 881 Transport: udp 882 CSeq-Number: 43 883 CSeq-Method: INVITE 884 R-URI: - 885 Destination-address: 198.51.100.10 886 Destination-port: 5060 887 Source-address: 203.0.113.1 888 Source-port: 5060 889 To: sip:bob@example.net 890 To-tag: b1-1 891 From: sip:alice@example.com 892 From-tag: al-1 893 Call-ID: tr-87h@example.com 894 Status: 200 895 Server-Txn: s-x-tr 896 Client-Txn: c-x-tr 898 8 Timestamp: 1275930747.300 899 Message Type: r 900 Directionality: s 901 Transport: udp 902 CSeq-Number: 43 903 CSeq-Method: INVITE 904 R-URI: - 905 Destination-address: 198.51.100.1 906 Destination-port: 5060 907 Source-address: 198.51.100.10 908 Source-port: 5060 909 To: sip:bob@example.net 910 To-tag: b1-1 911 From: sip:alice@example.com 912 From-tag: al-1 913 Call-ID: tr-87h@example.com 914 Status: 200 915 Server-Txn: s-x-tr 916 Client-Txn: c-x-tr 918 9 Timestamp: 1275930749.100 919 Message Type: R 920 Directionality: r 921 Transport: udp 922 CSeq-Number: 43 923 CSeq-Method: ACK 924 R-URI: sip:bob@example.net 925 Destination-address: 198.51.100.10 926 Destination-port: 5060 927 Source-address: 198.51.100.1 928 Source-port: 5060 929 To: sip:bob@example.net 930 To-tag: b1-1 931 From: sip:alice@example.com 932 From-tag: al-1 933 Call-ID: tr-87h@example.com 934 Status: - 935 Server-Txn: s-x-tr 936 Client-Txn: c-x-tr 938 10 Timestamp: 1275930749.100 939 Message Type: R 940 Directionality: s 941 Transport: udp 942 CSeq-Number: 43 943 CSeq-Method: ACK 944 R-URI: sip:bob@bob1.example.net 945 Destination-address: 203.0.113.1 946 Destination-port: 5060 947 Source-address: 198.51.100.10 948 Source-port: 5060 949 To: sip:bob@example.net 950 To-tag: b1-1 951 From: sip:alice@example.com 952 From-tag: al-1 953 Call-ID: tr-87h@example.com 954 Status: - 955 Server-Txn: s-x-tr 956 Client-Txn: c-x-tr 958 9.4. Forked call 960 In this example, Alice sends a session invitation to Bob's proxy, P2. 961 P2 forks the session invitation request to two registered endpoints 962 corresponding to Bob's address-of-record. Both endpoints respond 963 with provisional responses. Shortly thereafter, one of Bob's user 964 agent instances accepts the call, causing P2 to send a CANCEL request 965 to the second user agent. P2 does not Record-Route, therefore the 966 subsequent ACK request from Alice to Bob's user agent does not 967 traverse through P2 (and is not shown below.) 969 Figure 2 depicts the call flow. 971 Bob Bob 972 Alice P2 (Instance 1) (Instance 2) 973 +---INV--->| | | Line 1 974 | | | | 975 |<---100---+ | | Line 2 976 | | | | 977 | +---INV--->| | Line 3 978 | | | | 979 | +---INV----+-------->| Line 4 980 | | | | 981 | |<---100---+ | Line 5 982 | | | | 983 | |<---------+---100---+ Line 6 984 | | | | 985 | |<---180---+---------+ Line 7 986 | | | | 987 |<---180---+ | | Line 8 988 | | | | 989 | |<---180---+ | Line 9 990 | | | | 991 |<---180---+ | | Line 10 992 | | | | 993 | |<---200---+ | Line 11 994 | | | | 995 |<---200---+ | | Line 12 996 | | | | 997 | +---CANCEL-+-------->| Line 13 998 | | | | 999 | |<---------+---487---+ Line 14 1000 | | | | 1001 | +---ACK----+-------->| Line 15 1002 | | | | 1003 | |<---------+---200---+ Line 16 1004 Figure 2: Forked call flow 1006 The SIP CLF log correspond to the viewpoint of P2. The fields logged 1007 are shown below; the line numbers refer to Figure 2. 1009 1 Timestamp: 1275930743.699 1010 Message Type: R 1011 Directionality: r 1012 Transport: udp 1013 CSeq-Number: 43 1014 CSeq-Method: INVITE 1015 R-URI: sip:bob@example.net 1016 Destination-address: 203.0.113.200 1017 Destination-port: 5060 1018 Source-address: 198.51.100.1 1019 Source-port: 5060 1020 To: sip:bob@example.net 1021 To-tag: - 1022 From: sip:alice@example.com 1023 From-tag: a1-1 1024 Call-ID: tr-88h@example.com 1025 Status: - 1026 Server-Txn: s-1-tr 1027 Client-Txn: - 1029 2 Timestamp: 1275930744.001 1030 Message Type: r 1031 Directionality: s 1032 Transport: udp 1033 CSeq-Number: 43 1034 CSeq-Method: INVITE 1035 R-URI: - 1036 Destination-address: 198.51.100.1 1037 Destination-port: 5060 1038 Source-address: 203.0.113.200 1039 Source-port: 5060 1040 To: sip:bob@example.net 1041 To-tag: - 1042 From: sip:alice@example.com 1043 From-tag: a1-1 1044 Call-ID: tr-88h@example.com 1045 Status: 100 1046 Server-Txn: s-1-tr 1047 Client-Txn: - 1049 3 Timestamp: 1275930744.998 1050 Message Type: R 1051 Directionality: s 1052 Transport: udp 1053 CSeq-Number: 43 1054 CSeq-Method: INVITE 1055 R-URI: sip:bob@bob1.example.net 1056 Destination-address: 203.0.113.1 1057 Destination-port: 5060 1058 Source-address: 203.0.113.200 1059 Source-port: 5060 1060 To: sip:bob@example.net 1061 To-tag: - 1062 From: sip:alice@example.com 1063 From-tag: a1-1 1064 Call-ID: tr-88h@example.com 1065 Status: - 1066 Server-Txn: s-1-tr 1067 Client-Txn: c-1-tr 1069 4 Timestamp: 1275930745.500 1070 Message Type: R 1071 Directionality: s 1072 Transport: udp 1073 CSeq-Number: 43 1074 CSeq-Method: INVITE 1075 R-URI: sip:bob@bob2.example.net 1076 Destination-address: [2001:db8::9] 1077 Destination-port: 5060 1078 Source-address: 203.0.113.200 1079 Source-port: 5060 1080 To: sip:bob@example.net 1081 To-tag: - 1082 From: sip:alice@example.com 1083 From-tag: a1-1 1084 Call-ID: tr-88h@example.com 1085 Status: - 1086 Server-Txn: s-1-tr 1087 Client-Txn: c-2-tr 1089 5 Timestamp: 1275930745.800 1090 Message Type: r 1091 Directionality: r 1092 Transport: udp 1093 CSeq-Number: 43 1094 CSeq-Method: INVITE 1095 R-URI: - 1096 Destination-address: 203.0.113.200 1097 Destination-port: 5060 1098 Source-address: 203.0.113.1 1099 Source-port: 5060 1100 To: sip:bob@example.net 1101 To-tag: b1=-1 1102 From: sip:alice@example.com 1103 From-tag: a1-1 1104 Call-ID: tr-88h@example.com 100 1105 Status: 100 1106 Server-Txn: s-1-tr 1107 Client-Txn: c-1-tr 1109 6 Timestamp: 1275930746.100 1110 Message Type: r 1111 Directionality: r 1112 Transport: udp 1113 CSeq-Number: 43 1114 CSeq-Method: INVITE 1115 R-URI: - 1116 Destination-address: 203.0.113.200 1117 Destination-port: udp 1118 Source-address: [2001:db8::9] 1119 Source-port: 5060 1120 To: sip:bob@example.net 1121 To-tag: b2-2 1122 From: sip:alice@example.com 1123 From-tag: a1-1 1124 Call-ID: tr-88h@example.com 1125 Status: 100 1126 Server-Txn: s-1-tr 1127 Client-Txn: c-2-tr 1129 7 Timestamp: 1275930746.700 1130 Message Type: r 1131 Directionality: r 1132 Transport: udp 1133 CSeq-Number: 43 1134 CSeq-Method: INVITE 1135 R-URI: - 1136 Destination-address: 203.0.113.200 1137 Destination-port: udp 1138 Source-address: [2001:db8::9] 1139 Source-port: 5060 1140 To: sip:bob@example.net 1141 To-tag: b2-2 1142 From: sip:alice@example.com 1143 From-tag: a1-1 1144 Call-ID: tr-88h@example.com 1145 Status: 180 1146 Server-Txn: s-1-tr 1147 Client-Txn: c-2-tr 1149 8 Timestamp: 1275930746.990 1150 Message Type: r 1151 Directionality: s 1152 Transport: udp 1153 CSeq-Number: 43 1154 CSeq-Method: INVITE 1155 R-URI: - 1156 Destination-address: 198.51.100.1 1157 Destination-port: 5060 1158 Source-address: 203.0.113.200 1159 Source-port: 5060 1160 To: sip:bob@example.net 1161 To-tag: b2-2 1162 From: sip:alice@example.com 1163 From-tag: a1-1 1164 Call-ID: tr-88h@example.com 1165 Status: 180 1166 Server-Txn: s-1-tr 1167 Client-Txn: c-2-tr 1169 9 Timestamp: 1275930747.100 1170 Message Type: r 1171 Directionality: r 1172 Transport: udp 1173 CSeq-Number: 43 1174 CSeq-Method: INVITE 1175 R-URI: - 1176 Destination-address: 203.0.113.200 1177 Destination-port: 5060 1178 Source-address: 203.0.113.1 1179 Source-port: 5060 1180 To: sip:bob@example.net 1181 To-tag: b1-1 1182 From: sip:alice@example.com 1183 From-tag: a1-1 1184 Call-ID: tr-88h@example.com 100 1185 Status: 180 1186 Server-Txn: s-1-tr 1187 Client-Txn: c-1-tr 1189 10 Timestamp: 1275930747.300 1190 Message Type: r 1191 Directionality: s 1192 Transport: udp 1193 CSeq-Number: 43 1194 CSeq-Method: INVITE 1195 R-URI: - 1196 Destination-address: 198.51.100.1 1197 Destination-port: 5060 1198 Source-address: 203.0.113.200 1199 Source-port: 5060 1200 To: sip:bob@example.net 1201 To-tag: b1-1 1202 From: sip:alice@example.com 1203 From-tag: a1-1 1204 Call-ID: tr-88h@example.com 1205 Status: 180 1206 Server-Txn: s-1-tr 1207 Client-Txn: c-2-tr 1209 11 Timestamp: 1275930747.800 1210 Message Type: r 1211 Directionality: r 1212 Transport: udp 1213 CSeq-Number: 43 1214 CSeq-Method: INVITE 1215 R-URI: - 1216 Destination-address: 203.0.113.200 1217 Destination-port: 5060 1218 Source-address: 203.0.113.1 1219 Source-port: 5060 1220 To: sip:bob@example.net 1221 To-tag: b1-1 1222 From: sip:alice@example.com 1223 From-tag: a1-1 1224 Call-ID: tr-88h@example.com 100 1225 Status: 200 1226 Server-Txn: s-1-tr 1227 Client-Txn: c-1-tr 1229 12 Timestamp: 1275930748.000 1230 Message Type: r 1231 Directionality: s 1232 Transport: udp 1233 CSeq-Number: 43 1234 CSeq-Method: INVITE 1235 R-URI: - 1236 Destination-address: 198.51.100.1 1237 Destination-port: 5060 1238 Source-address: 203.0.113.200 1239 Source-port: 5060 1240 To: sip:bob@example.net 1241 To-tag: b1-1 1242 From: sip:alice@example.com 1243 From-tag: a1-1 1244 Call-ID: tr-88h@example.com 1245 Status: 200 1246 Server-Txn: s-1-tr 1247 Client-Txn: c-1-tr 1249 13 Timestamp: 1275930748.201 1250 Message Type: R 1251 Directionality: s 1252 Transport: udp 1253 CSeq-Number: 43 1254 CSeq-Method: CANCEL 1255 R-URI: sip:bob@bob2.example.net 1256 Destination-address: [2001:db8::9] 1257 Destination-port: 5060 1258 Source-address: 203.0.113.200 1259 Source-port: 5060 1260 To: sip:bob@example.net 1261 To-tag: b2-2 1262 From: sip:alice@example.com 1263 From-tag: a1-1 1264 Call-ID: tr-88h@example.com 1265 Status: - 1266 Server-Txn: s-1-tr 1267 Client-Txn: c-2-tr 1269 14 Timestamp: 1275930748.991 1270 Message Type: r 1271 Directionality: r 1272 Transport: udp 1273 CSeq-Number: 43 1274 CSeq-Method: INVITE 1275 R-URI: - 1276 Destination-address: 203.0.113.200 1277 Destination-port: udp 1278 Source-address: [2001:db8::9] 1279 Source-port: 5060 1280 To: sip:bob@example.net 1281 To-tag: b2-2 1282 From: sip:alice@example.com 1283 From-tag: a1-1 1284 Call-ID: tr-88h@example.com 1285 Status: 487 1286 Server-Txn: s-1-tr 1287 Client-Txn: c-2-tr 1289 15 Timestamp: 1275930749.455 1290 Message Type: R 1291 Directionality: s 1292 Transport: udp 1293 CSeq-Number: 43 1294 CSeq-Method: ACK 1295 R-URI: sip:bob@bob2.example.net 1296 Destination-address: [2001:db8::9] 1297 Destination-port: 5060 1298 Source-address: 203.0.113.200 1299 Source-port: 5060 1300 To: sip:bob@example.net 1301 To-tag: b2-2 1302 From: sip:alice@example.com 1303 From-tag: a1-1 1304 Call-ID: tr-88h@example.com 1305 Status: - 1306 Server-Txn: s-1-tr 1307 Client-Txn: c-2-tr 1309 16 Timestamp: 1275930750.001 1310 Message Type: r 1311 Directionality: r 1312 Transport: udp 1313 CSeq-Number: 43 1314 CSeq-Method: CANCEL 1315 R-URI: - 1316 Destination-address: 203.0.113.200 1317 Destination-port: udp 1318 Source-address: [2001:db8::9] 1319 Source-port: 5060 1320 To: sip:bob@example.net 1321 To-tag: b2-2 1322 From: sip:alice@example.com 1323 From-tag: a1-1 1324 Call-ID: tr-88h@example.com 1325 Status: 200 1326 Server-Txn: s-1-tr 1327 Client-Txn: c-2-tr 1329 The above SIP CLF log makes it easy to search for a specific 1330 transaction or a state of the session. Searching for the string 1331 "c-1-tr" on the log records will readily yield the information that 1332 an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 1333 followed by a 180 and then a 200. Because the ACK request in this 1334 case would be exchanged end-to-end, this element does not see (and 1335 therefore will not log) the ACK. 1337 Searching on "c-2-tr" yields a more complex scenario of sending an 1338 INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, 1339 the log makes it apparent that the request to 1340 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 1341 response was generated, and that the pending INVITE returned a 487. 1342 The ACK to the final non-2xx response and a 200 to the CANCEL request 1343 complete the exchange on that branch. 1345 10. Security Considerations 1347 A log file by its nature reveals both the state of the entity 1348 producing it and the nature of the information being logged. To the 1349 extent that this state should not be publicly accessible and that the 1350 information is to be considered private, appropriate file and 1351 directory permissions attached to the log file should be used. The 1352 following threats may be considered for the log file while it is 1353 stored: 1355 o An attacker may gain access to view the log file, or may 1356 surreptitiously make a copy of the log file for later viewing. 1357 o An attacker who is unable to eavesdrop real-time SIP traffic on 1358 the network but nonetheless can access the log file, is able to 1359 easily mount reply attack or other attacks that result from 1360 channel eavesdropping. Encrypting SIP traffic does not help here 1361 because the SIP entity generating the log file would have 1362 decrypted the message for processing and subsequent logging. 1363 o An attacker may delete parts of --- or indeed, the whole --- file. 1365 It is outside the scope of this document to specify how to protect 1366 the log file while it is stored on disk. However, operators may 1367 consider using common administrative features such as disk encryption 1368 and securing log files [schneier-1]. Operators may also consider 1369 hardening the machine on which the log files are stored by 1370 restricting physical access to the host as well as restricting access 1371 to the files themselves. 1373 In the worst case, public access to the SIP log file provides the 1374 same information that an adversary can gain using network sniffing 1375 tools (assuming that the SIP traffic is in clear text.) If all SIP 1376 traffic on a network segment is encrypted, then as noted above, 1377 special attention must be directed to the file and directory 1378 permissions associated with the log file to preserve privacy such 1379 that only a privileged user can access the contents of the log file. 1381 Transporting SIP CLF files across the network pose special challenges 1382 as well. The following threats may be considered for transferring 1383 log files or while transferring individual log records: 1385 o An attacker may view the records; 1386 o An attacker may modify the records in transit or insert previously 1387 captured records into the stream; 1388 o An attacker may remove records in transit, or may stage a man- in- 1389 the-middle attack to deliver a partially or entirely falsified log 1390 file. 1392 It is also outside the scope of this document to specify protection 1393 methods for log files or log records that are being transferred 1394 between hosts. However, operators may consider using common security 1395 protocols described in [RFC3552] to transfer log files or individual 1396 records. Alternatively, the log file may be transferred through bulk 1397 methods that also guarantees integrity, or at least detects and 1398 alerts to modification attempts. 1400 The SIP CLF represents the minimum fields that lend themselves to 1401 trend analysis and serve as information that may be deemed useful. 1402 Other formats can be defined that include more headers (and the body) 1403 from Section 8.1. However, where to draw a judicial line regarding 1404 the inclusion of non-mandatory headers can be challenging. Clearly, 1405 the more information a SIP entity logs, the longer time the logging 1406 process will take, the more disk space the log entry will consume, 1407 and the more potentially sensitive information could be breached. 1408 Therefore, adequate tradeoffs should be taken in account when logging 1409 more fields than the ones recommended in Section 8.1. 1411 Implementers need to pay particular attention to buffer handling when 1412 reading or writing log files. SIP CLF entries can be unbounded in 1413 length. It would be reasonable for a full dump of a SIP message to 1414 be thousands of octets long. This is of particular importance to CLF 1415 log parsers, as a SIP CLF log writers may add one or more extension 1416 fields to the message to be logged. 1418 11. Operational guidance 1420 SIP CLF log files will take up substantive amount of disk space 1421 depending on traffic volume at a processing entity and the amount of 1422 information being logged. As such, any enterprise using SIP CLF 1423 should establish operational procedures for file rollovers as 1424 appropriate to the needs of the organization. 1426 Listing such operational guidelines in this document is out of scope 1427 for this work. 1429 12. IANA Considerations 1431 This document does not require any considerations from IANA. 1433 13. Acknowledgments 1435 Members of the sipping, dispatch, ipfix and syslog working groups 1436 provided invaluable input to the formulation of the draft. These 1437 include Benoit Claise, Spencer Dawkins, John Elwell, David 1438 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1439 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon 1440 Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, 1441 Dale Worley, Theo Zourzouvillys and others that we have undoubtedly, 1442 but inadvertently, missed. 1444 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1445 Salgueiro helped tremendously in discussions related to arriving at 1446 the beginnings of a data model. 1448 14. References 1450 14.1. Normative References 1452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1453 Requirement Levels", BCP 14, RFC 2119, March 1997. 1455 14.2. Informative References 1457 [I-D.ietf-sipclf-format] 1458 Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1459 Session Initiation Protocol (SIP) Common Log Format 1460 (CLF)", draft-ietf-sipclf-format-03 (work in progress), 1461 October 2011. 1463 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1464 A., Peterson, J., Sparks, R., Handley, M., and E. 1465 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1466 June 2002. 1468 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1469 Text on Security Considerations", BCP 72, RFC 3552, 1470 July 2003. 1472 [rieck2008] 1473 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1474 Muller, "A Self-learning System for Detection of Anomalous 1475 SIP Messages", Principles, Systems and Applications of IP 1476 Telecommunications Services and Security for Next 1477 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1478 2008. 1480 [schneier-1] 1481 Schneier, B. and J. Kelsey, "Secure audit logs to support 1482 computer forensics", ACM Transactions on Information and 1483 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1485 Authors' Addresses 1487 Vijay K. Gurbani (editor) 1488 Bell Laboratories, Alcatel-Lucent 1489 1960 Lucent Lane 1490 Naperville, IL 60566 1491 USA 1493 Email: vkg@bell-labs.com 1495 Eric W. Burger (editor) 1496 Georgetown University 1497 USA 1499 Email: eburger@standardstrack.com 1500 URI: http://www.standardstrack.com 1502 Tricha Anjali 1503 Illinois Institute of Technology 1504 316 Siegel Hall 1505 Chicago, IL 60616 1506 USA 1508 Email: tricha@ece.iit.edu 1510 Humberto Abdelnur 1511 INRIA 1512 INRIA - Nancy Grant Est 1513 Campus Scientifique 1514 54506, Vandoeuvre-les-Nancy Cedex 1515 France 1517 Email: Humberto.Abdelnur@loria.fr 1518 Olivier Festor 1519 INRIA 1520 INRIA - Nancy Grant Est 1521 Campus Scientifique 1522 54506, Vandoeuvre-les-Nancy Cedex 1523 France 1525 Email: Olivier.Festor@loria.fr