idnits 2.17.1 draft-ietf-sipclf-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 556, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 560, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 562, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 570, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '4') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 5101 (ref. '6') (Obsoleted by RFC 7011) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Informational E. Burger, Ed. 5 Expires: September 9, 2010 Neustar, Inc. 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 March 8, 2010 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-01 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 to IETF 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), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 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 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on September 9, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 Table of Contents 72 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 75 4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 4 76 5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 5 77 5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 5 78 5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 6 79 6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 6 80 7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 8 81 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 11 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 89 14.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 [1]. 98 RFC 3261 [2] defines additional terms used in this document that are 99 specific to the SIP domain such as "proxy"; "registrar"; "redirect 100 server"; "user agent server" or "UAS"; "user agent client" or "UAC"; 101 "back-to-back user agent" or "B2BUA"; "dialog"; "transaction"; 102 "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 3. Problem statement 148 The Session Initiation Protocol [2](SIP) is an Internet multimedia 149 session signaling protocol that is increasingly used for other 150 services besides session establishment. A typical delpoyment of SIP 151 in an enterprise will consist of SIP entities from multiple vendors. 152 Currently, if these entities are capable of producing a log file of 153 the transactions being handled by them, the log files are produced in 154 a proprietary format. The result of multiplicity of the log file 155 formats is the inability of the support staff to easily trace a call 156 from one entity to another, or even to craft common tools that will 157 perform trend analysis, debugging and troubleshooting problems 158 uniformly across the SIP entities of multiple vendors. 160 SIP does not currently have a CLF format and this document serves to 161 provide the rationale to establish a SIP CLF and identifies the 162 required minimal information that must appear in any SIP CLF record. 164 4. What SIP CLF is and what it is not 166 The SIP CLF is a standardized manner of producing a text file. This 167 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 168 The SIP CLF is simply an easily digestible log of currently occurring 169 events and past transactions. It contains enough information to 170 allow humans and automata to derive relationships between discrete 171 transactions handled at a SIP entity. For example, a SIP 172 administrator should be able to issue a concise command to discover 173 relationships between transactions or to search a certain dialog or 174 transaction. 176 Note: The exact form of the "concise command" is left unspecified 177 until the working group agrees to one or more formats for encoding 178 the fields. 180 The SIP CLF is amenable to quick parsing (i.e., well-delimited 181 fields) and it is platform and operating system neutral. 183 The SIP CLF is amenable to easy parsing and lends itself well to 184 creating other innovative tools. 186 The SIP CLF is not a billing tool. It is not expected that 187 enterprises will bill customers based on SIP CLF. The SIP CLF 188 records events at the signaling layer only and does not attempt to 189 correlate the veracity of these events with the media layer. Thus, 190 it cannot be used to trigger customer billing. 192 The SIP CLF is not a quality of service (QoS) measurement tool. If 193 QoS is defined as measuring the mean opinion score (MOS) of the 194 received media, then SIP CLF does not aid in this task since it does 195 not summarize events at the media layer. 197 5. Alternative approaches to SIP CLF 199 It is perhaps tempting to consider other approaches --- which though 200 not standardized, are in wide enough use in networks today --- to 201 determine whether or not a SIP CLF would benefit a SIP network 202 consisting of mutil-vendor products. The two existing approaches 203 that approximate what SIP CLF does are Call Detail Records (CDRs) and 204 Wireshark packet sniffing. 206 5.1. SIP CLF and CDRs 208 CDRs are used in operator networks widely and with the adoption of 209 SIP, standardization bodies such as 3GPP have subsequently defined 210 SIP-related CDRs as well. Today, CDRs are used to implement the 211 functionality approximated by SIP CLF, however, there are important 212 differences. 214 One, SIP CLF operates natively at the transaction layer and maintains 215 enough information in the information elements being logged that 216 dialog-related data can be subsequently derived from the transaction 217 logs. Thus, esoteric SIP fields and parameters like the To header, 218 including tags; the From header, including tags, the CSeq number, 219 etc. are logged in SIP CLF. By contrast, a CDR is used mostly for 220 charging and thus saves information to facilitate that very aspect. 221 A CDR will most certainly log the public user identification of a 222 party requesting a service (which may not correspond to the From 223 header) and the public user identification of the party called party 224 (which may not correspond to the To header.) Furthermore, the 225 sequence numbers maintained by the CDR may not correspond to the SIP 226 CSeq header. Thus it will be hard to piece together the state of a 227 dialog through a sequence of CDR records. 229 Two, a CDR record will, in all probability, be generated at a SIP 230 entity performing some form of proxy-like functionality of a B2BUA 231 providing some service. By contrast, SIP CLF is light- weight enough 232 that it can be generated by a canonical SIP user agent server and 233 user agent client as well, including those that execute on resource 234 constrained devices (mobile phones). 236 Finally, SIP is also being deployed outside of operator- managed VoIP 237 networks. Universities, research laboratories, and small-to-medium 238 size companies are deploying SIP-based VoIP solutions on networks 239 owned and managed by them. Much of the latter constituencies will 240 not have an interest in generating CDRs, but they will like to have a 241 concise representation of the messages being handled by the SIP 242 entities in a common format. 244 5.2. SIP CLF and Wireshark packet capture 246 Wireshark is a popular raw packet capture tool. It contains filters 247 that can understand SIP at the protocol level and break down a 248 captured message into its individual header components. While 249 Wireshark is appropriate to capture and view discrete SIP messages, 250 it does not suffice to serve in the same capacity as SIP CLF for two 251 reasons. 253 First, while the Wireshark format saves bulk of the information 254 needed to create transaction and dialog state, the Wireshark format 255 is a binary format that does not lend itself very well to being 256 manipulated by text-based tools. Second and more importantly, if the 257 SIP messages are exchanged over a TLS-oriented transport, Wireshark 258 will be unable to decrypt them and render them as individual SIP 259 headers. 261 6. Motivation and use cases 263 As SIP becomes pervasive in multiple business domains and ubiquitous 264 in academic and research environments, it is beneficial to establish 265 a CLF for the following reasons: 267 Common reference for interpreting events: In a laboratory 268 environment or an enterprise service offering there will typically 269 be SIP servers from multiple vendors participating in routing 270 requests. Absent a CLF format, each server will produce output 271 records in a native format making it hard to establish commonality 272 for tools that operate on the log file. 274 Writing common tools: A CLF format allows independent tool providers 275 to craft tools and applications that interpret the CLF data to 276 produce insightful trend analysis and detailed traffic reports. 277 The format should be such that it retains the ability to be read 278 by humans and processed using traditional Unix text processing 279 tools. 281 Session correlation across diverse processing elements: In 282 operational SIP networks, a request will typically be processed by 283 more than one SIP server. A SIP CLF will allow the network 284 operator to trace the progression of the request (or a set of 285 requests) as they traverse through the different servers to 286 establish a concise diagnostic trail of a SIP session. 288 Note that tracing the request through a set of servers is 289 considerably less challenging if all the servers belong to the 290 same administrative domain. 292 Message correlation across transactions: A SIP CLF can enable a 293 quick lookup of all messages that comprise a transaction (e.g., 294 "Find all messages corresponding to server transaction X, 295 including all forked branches.") 297 Message correlation across dialogs: A SIP CLF can correlate 298 transactions that comprise a dialog (e.g., "Find all messages for 299 dialog created by Call-ID C, From tag F and To tag T.") 301 Trend analysis: A SIP CLF allows an administrator to collect data 302 and spot patterns or trends in the information (e.g., "What is the 303 domain where the most sessions are routed to between 9:00 AM and 304 12:00 PM?") 306 Train anomaly detection systems: A SIP CLF will allow for the 307 training of anomaly detection systems that once trained can 308 monitor the CLF file to trigger an alarm on the subsequent 309 deviations from accepted patterns in the data set. Currently, 310 anomaly detection systems monitor the network and parse raw 311 packets that comprise a SIP message -- a process that is 312 unsuitable for anomaly detection systems [3]. With all the 313 necessary event data at their disposal, network operations 314 managers and information technology operation managers are in a 315 much better position to correlate, aggregate, and prioritize log 316 data to maintain situational awareness. 318 Testing: A SIP CLF allows for automatic testing of SIP equipment by 319 writing tools that can parse a SIP CLF file to ensure behavior of 320 a device under test. 322 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 323 SIP server (e.g., "How long did it take to generate a final 324 response for the INVITE associated with Call-ID X?") 326 Offline analysis: A SIP CLF allows for offline analysis of the data 327 gathered. Once a SIP CLF file has been generated, it can be 328 transported (subject to the security considerations in Section 10) 329 to a host with appropriate computing resources to perform 330 subsequent analysis. 332 Real-time monitoring: A SIP CLF allows administrators to visually 333 notice the events occurring at a SIP server in real-time providing 334 accurate situational awareness. 336 7. Challenges in establishing a SIP CLF 338 Establishing a CLF for SIP is a challenging task. The behavior of a 339 SIP entity is more complex when compared to the equivalent HTTP 340 entity. 342 Base protocol services such as parallel or serial forking elicit 343 multiple final responses. Ensuing delays between sending a request 344 and receiving a final response all add complexity when considering 345 what fields should comprise a CLF and in what manner. Furthermore, 346 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 347 and these transactions may arrive at a varying inter-arrival rate at 348 a proxy. For example, the BYE transaction usually arrives much after 349 the corresponding INVITE transaction was received, serviced and 350 expunged from the transaction list. Nonetheless, it is advantageous 351 to relate these transactions such that automata or a human monitoring 352 the log file can construct a set consisting of related transactions. 354 ACK requests in SIP need careful consideration as well. In SIP, an 355 ACK is a special method that is associated with an INVITE only. It 356 does not require a response, and furthermore, if it is acknowledging 357 a non-2xx response, then the ACK is considered part of the original 358 INVITE transaction. If it is acknowledging a 2xx-class response, 359 then the ACK is a separate transaction consisting of a request only 360 (i.e., there is not a response for an ACK request.) CANCEL is 361 another method that is tied to an INVITE transaction, but unlike ACK, 362 the CANCEL request elicits a final response. 364 While most requests elicit a response immediately, the INVITE request 365 in SIP can pend at a proxy as it forks branches downstream or at a 366 user agent server while it alerts the user. RFC 3261 [2] instructs 367 the server transaction to send a 1xx-class provisional response if a 368 final response is delayed for more than 200 ms. A SIP CLF log file 369 needs to include such provisional responses because they help train 370 automata associated with anomaly detection systems and provide some 371 positive feedback for a human observer monitoring the log file. 373 Finally, beyond supporting native SIP actors such as proxies, 374 registrars, redirect servers, and user agent servers (UAS), it is 375 beneficial to derive a CLF format that supports back-to-back user 376 agent (B2BUA) behavior, which may vary considerably depending on the 377 specific nature of the B2BUA. 379 8. Data model 381 The inspiration for the SIP CLF is the Apache CLF. However, the 382 state machinery for a HTTP transaction is much simpler than that of 383 the SIP transaction (as evidenced in Section 7). The SIP CLF needs 384 to do considerably more. 386 Accordingly, the following SIP CLF fields are defined as mininal 387 information that must appear in any SIP CLF record: 389 date: Date and time of the request or response represented as the 390 number of seconds and milliseconds since the Unix epoch. 392 source-address: The DNS name or IP address of the upstream client, 393 including the port number. 395 authuser: The user name by which the user has been authenticated. 396 If the user name is unknown or when a request is challenged, the 397 value in this field must be "-" 399 method: The upper-case name of the SIP method. 401 request-uri: The Request-URI, including any URI parameters. 403 from: The From URI, including the tag. Whilst one may question the 404 value of the From URI in light of RFC4744 [4], the From URI, 405 nonetheless, imparts some information. For one, the From tag is 406 important and, in the case of a REGISTER request, the From URI can 407 provide information on whether this was a third-party registration 408 or a first-party one. 410 to: The To URI, including tag. 412 callid: The Call-ID. 414 status: The SIP response status code returned upstream. 416 server-txn: Server transaction identification code - the transaction 417 identifier associated with the server transaction. 418 Implementations can reuse the server transaction identifier (the 419 topmost branch-id of the incoming request, with or without the 420 magic cookie), or they could generate a unique identification 421 string for a server transaction (this identifier needs to be 422 locally unique to the server only.) This identifier is used to 423 correlate ACKs and CANCELs to an INVITE transaction; it is also 424 used to aid in forking as explained later in this section. 426 client-txn: Client transaction identification code - this field is 427 used to associate client transactions with a server transaction 428 for forking proxies or B2BUAs. Upon forking, implementations can 429 reuse the value they inserted into the topmost Via header's branch 430 parameter, or they can generate a unique identification string for 431 the client transaction. A more detailed explanation of why it is 432 needed is provided next. 434 SIP Proxies may fork, creating several client transactions that 435 correlate to a single server transaction. Responses arriving on 436 these client transactions, or new requests (CANCEL, ACK) sent on the 437 client transaction need log file entries that correlate with a server 438 transaction. Similarly, a B2BUA may create one or more client 439 transactions in response to an incoming request. These transactions 440 will require correlation as well. 442 Section 9 demonstrates the use of "server-txn" and "client-txn" using 443 a text representation of the SIP CLF format (note that the text 444 representation format is for illustration purposes only.) 446 Finally, the SIP CLF should be extensible such that future SIP 447 methods, headers and bodies can be represented as well. Besides the 448 mandatory fields listed above, all other SIP headers will appear as 449 an ordered pairs of header field names and values. 451 9. Examples 453 To fill in. 455 10. Security Considerations 457 A log file by its nature reveals the both the state of the entity 458 producing it and the nature of the information being logged. To the 459 extent that this state should not be publicly accessible and that the 460 information is to be considered private, appropriate file and 461 directory permissions attached to the log file should be used. In 462 the worst case, public access to the SIP log file provides the same 463 information that an adversary can gain using network sniffing tools 464 (assuming that the SIP traffic is in clear text.) If all SIP traffic 465 on a network segment is encrypted, then special attention must be 466 directed to the file and directory permissions associated with the 467 log file to preserve privacy such that only a privileged user can 468 access the contents of the log file. 470 Transporting SIP CLF files across the network pose special challenges 471 as well. While transporting SIP CLF files is out of scope in the 472 current working group charter, it seems worth drawing attention to 473 the fact that if the file is transported using unencrypted FTP or 474 email, intermediaries and adversaries may have access to the raw SIP 475 CLF records. Accordingly, if the SIP CLF file is to be moved from 476 the generating host, secure FTP or secure email must be used instead. 478 The SIP CLF represents the minimum fields that lend themselves to 479 trend analysis and serve as information that may be deemed useful. 480 Other formats can be defined that include more headers (and the body) 481 from Section 8. However, where to draw a judicial line regarding the 482 inclusion of non-mandatory headers can be challenging. Clearly, the 483 more information a SIP server logs, the longer time the logging 484 process will take, the more disk space the log entry will consume, 485 and the more potentially sensitive information could be breached. 486 Therefore, adequate tradeoffs should be taken in account when logging 487 more fields than the ones recommended in Section 8. 489 Implementers need to pay particular attention to buffer handling when 490 reading or writing log files. SIP CLF entries can be unbounded in 491 length. It would be reasonable for a full dump of a SIP message to 492 be thousands of octets long. This is of particular importance to CLF 493 log parsers, as a SIP CLF log writers may add one or more extension 494 fields to the message to be logged. 496 11. Operational guidance 498 SIP CLF log files will take up substantive amount of disk space 499 depending on traffic volume at a processing entity and the amount of 500 information being logged. As such, any enterprise using SIP CLF 501 should establish operational procedures for file rollovers as 502 appropriate to the needs of the organization. 504 Listing such operational guidelines in this document is out of scope 505 for this work. 507 12. IANA Considerations 509 This document does not require any considerations from IANA. 511 13. Acknowledgments 513 Members of the sipping, dispatch, ipfix and syslog working groups 514 provided invaluable input to the formulation of the draft. These 515 include Benoit Claise, Spencer Dawkins, David Harrington, Christer 516 Holmberg, Hadriel Kaplan, Atsushi Kobayashi, Jiri Kuthan, Scott 517 Lawrence, Simon Perreault, Adam Roach, Dan Romascanu, Robert Sparks, 518 Brian Trammell, Dale Worley, Theo Zourzouvillys and others that we 519 have undoubtedly, but inadvertently, missed. 521 Adam Roach proposed and documented the binary TLV-format and Hadriel 522 Kaplan proposed and documented the PCAP-based format as alternative 523 SIP CLF representations. 525 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 526 Salgueiro helped tremendously in discussions related to arriving at 527 the beginnings of a data model. 529 14. References 531 14.1. Normative References 533 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 534 Levels", BCP 14, RFC 2119, March 1997. 536 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 537 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 538 Session Initiation Protocol", RFC 3261, June 2002. 540 14.2. Informative References 542 [3] Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 543 Muller, "A Self-learning System for Detection of Anomalous SIP 544 Messages", Principles, Systems and Applications of IP 545 Telecommunications Services and Security for Next Generation 546 Networks (IPTComm), LNCS 5310, pp. 90-106, 2008. 548 [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated 549 Identity Management in the Session Initiation Protocol (SIP)", 550 RFC 4474, August 2006. 552 [5] Debar, H., Curry, D., and B. Feinstein, "The Intrusion 553 Detection Message Exchange Format (IDMEF)", RFC 4765, 554 March 2007. 556 [6] Claise, B., "Specification of the IP Flow Information Export 557 (IPFIX) Protocol for the Exchange of IP Traffic Flow 558 Information", RFC 5101, January 2008. 560 [7] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 562 [8] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. 563 Festor, "The Common Log File (CLF) format for the Session 564 Initiation Protocol (SIP)", draft-gurbani-sipping-clf-01 (work 565 in progress), March 2009. 567 [9] Roach, A., "Binary Syntax for SIP Common Log Format", 568 draft-roach-sipping-clf-syntax-01 (work in progress), May 2009. 570 [10] Kaplan, H., "PCAP-compatible Binary Syntax for SIP Common Log 571 File Format", draft-kaplan-sipping-clf-pcap-00 (work in 572 progress), June 2009. 574 Authors' Addresses 576 Vijay K. Gurbani (editor) 577 Bell Laboratories, Alcatel-Lucent 578 1960 Lucent Lane 579 Naperville, IL 60566 580 USA 582 Email: vkg@bell-labs.com 584 Eric W. Burger (editor) 585 Neustar, Inc. 586 USA 588 Email: eburger@standardstrack.com 589 URI: http://www.standardstrack.com 590 Tricha Anjali 591 Illinois Institute of Technology 592 316 Siegel Hall 593 Chicago, IL 60616 594 USA 596 Email: tricha@ece.iit.edu 598 Humberto Abdelnur 599 INRIA 600 INRIA - Nancy Grant Est 601 Campus Scientifique 602 54506, Vandoeuvre-les-Nancy Cedex 603 France 605 Email: Humberto.Abdelnur@loria.fr 607 Olivier Festor 608 INRIA 609 INRIA - Nancy Grant Est 610 Campus Scientifique 611 54506, Vandoeuvre-les-Nancy Cedex 612 France 614 Email: Olivier.Festor@loria.fr