idnits 2.17.1 draft-ietf-sipclf-problem-statement-00.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 (February 8, 2010) is 5184 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 571, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 575, 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. '9') (Obsoleted by RFC 7011) Summary: 1 error (**), 0 flaws (~~), 5 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: August 12, 2010 Neustar, Inc. 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 February 8, 2010 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-00 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 August 12, 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. SIP CLF fields . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 10. Operational guidance . . . . . . . . . . . . . . . . . . . . . 12 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 88 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [1]. 97 RFC 3261 [2] defines additional terms used in this document that are 98 specific to the SIP domain such as "proxy"; "registrar"; "redirect 99 server"; "user agent server" or "UAS"; "user agent client" or "UAC"; 100 "back-to-back user agent" or "B2BUA"; "dialog"; "transaction"; 101 "server transaction". 103 This document uses the term "SIP Server" that is defined to include 104 the following SIP entities: user agent server, registrar, redirect 105 server, a SIP proxy in the role of user agent server, and a B2BUA in 106 the role of a user agent server. 108 2. Introduction 110 Servers executing on Internet hosts produce log records as part of 111 their normal operations. A log record is, in essence, a summary of 112 an application layer protocol data unit (PDU), that captures in 113 precise terms an event that was processed by the server. These log 114 records serve many purposes, including analysis and troubleshooting. 116 Well-known web servers such as Apache and Squid support event logging 117 using a Common Log Format (CLF), the common structure for logging 118 requests and responses serviced by the web server. It can be argued 119 that a good part of the success of Apache has been its CLF because it 120 allowed third parties to produce tools that analyzed the data and 121 generated traffic reports and trends. The Apache CLF has been so 122 successful that not only did it become the de-facto standard in 123 producing logging data for web servers, but also many commercial web 124 servers can be configured to produce logs in this format. An example 125 of Apache CLF is depicted next: 127 %h %l %u %t \"%r\" %s %b 128 remotehost rfc931 authuser [date] request status bytes 130 remotehost: Remote hostname (or IP number if DNS hostname is not 131 available, or if DNSLookup is Off. 133 rfc931: The remote logname of the user. 135 authuser: The username by which the user has authenticated himself. 137 [date]: Date and time of the request. 139 request: The request line exactly as it came from the client. 141 status: The HTTP status code returned to the client. 143 bytes: The content-length of the document transferred. 145 3. Problem statement 147 The Session Initiation Protocol [2](SIP) is an Internet multimedia 148 session signaling protocol that is increasingly used for other 149 services besides session establishment. A typical delpoyment of SIP 150 in an enterprise will consist of SIP entities from multiple vendors. 151 Currently, if these entities are capable of producing a log file of 152 the transactions being handled by them, the log files are produced in 153 a proprietary format. The result of multiplicity of the log file 154 formats is the inability of the support staff to easily trace a call 155 from one entity to another, or even to craft common tools that will 156 perform trend analysis, debugging and troubleshooting problems 157 uniformly across the SIP entities of multiple vendors. 159 SIP does not currently have a CLF format and this document serves to 160 provide the rationale to establish a SIP CLF and identifies the 161 required minimal information that must appear in any SIP CLF record. 163 4. What SIP CLF is and what it is not 165 The SIP CLF is a standardized manner of producing a text file. This 166 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 167 The SIP CLF is simply an easily digestible log of currently occurring 168 events and past transactions. It contains enough information to 169 allow humans and automata to derive relationships between discrete 170 transactions handled at a SIP entity. For example, a SIP 171 administrator should be able to issue a concise command to discover 172 relationships between transactions or to search a certain dialog or 173 transaction. 175 Note: The exact form of the "concise command" is left unspecified 176 until the working group agrees to one or more formats for encoding 177 the fields. 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 mutil-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, while the Wireshark format saves bulk of the information 253 needed to create transaction and dialog state, the Wireshark format 254 is a binary format that does not lend itself very well to being 255 manipulated by text-based tools. Second and more importantly, if the 256 SIP messages are exchanged over a TLS-oriented transport, Wireshark 257 will be unable to decrypt them and render them as individual SIP 258 headers. 260 6. Motivation and use cases 262 As SIP becomes pervasive in multiple business domains and ubiquitous 263 in academic and research environments, it is beneficial to establish 264 a CLF for the following reasons: 266 Common reference for interpreting events: In a laboratory 267 environment or an enterprise service offering there will typically 268 be SIP servers from multiple vendors participating in routing 269 requests. Absent a CLF format, each server will produce output 270 records in a native format making it hard to establish commonality 271 for tools that operate on the log file. 273 Writing common tools: A CLF format allows independent tool providers 274 to craft tools and applications that interpret the CLF data to 275 produce insightful trend analysis and detailed traffic reports. 276 The format should be such that it retains the ability to be read 277 by humans and processed using traditional Unix text processing 278 tools. 280 Session correlation across diverse processing elements: In 281 operational SIP networks, a request will typically be processed by 282 more than one SIP server. A SIP CLF will allow the network 283 operator to trace the progression of the request (or a set of 284 requests) as they traverse through the different servers to 285 establish a concise diagnostic trail of a SIP session. 287 Note that tracing the request through a set of servers is 288 considerably less challenging if all the servers belong to the 289 same administrative domain. 291 Message correlation across transactions: A SIP CLF can enable a 292 quick lookup of all messages that comprise a transaction (e.g., 293 "Find all messages corresponding to server transaction X, 294 including all forked branches.") 296 Message correlation across dialogs: A SIP CLF can correlate 297 transactions that comprise a dialog (e.g., "Find all messages for 298 dialog created by Call-ID C, From tag F and To tag T.") 300 Trend analysis: A SIP CLF allows an administrator to collect data 301 and spot patterns or trends in the information (e.g., "What is the 302 domain where the most sessions are routed to between 9:00 AM and 303 12:00 PM?") 305 Train anomaly detection systems: A SIP CLF will allow for the 306 training of anomaly detection systems that once trained can 307 monitor the CLF file to trigger an alarm on the subsequent 308 deviations from accepted patterns in the data set. Currently, 309 anomaly detection systems monitor the network and parse raw 310 packets that comprise a SIP message -- a process that is 311 unsuitable for anomaly detection systems [3]. With all the 312 necessary event data at their disposal, network operations 313 managers and information technology operation managers are in a 314 much better position to correlate, aggregate, and prioritize log 315 data to maintain situational awareness. 317 Testing: A SIP CLF allows for automatic testing of SIP equipment by 318 writing tools that can parse a SIP CLF file to ensure behavior of 319 a device under test. 321 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 322 SIP server (e.g., "How long did it take to generate a final 323 response for the INVITE associated with Call-ID X?") 325 Offline analysis: A SIP CLF allows for offline analysis of the data 326 gathered. Once a SIP CLF file has been generated, it can be 327 transported (subject to the security considerations in Section 9) 328 to a host with appropriate computing resources to perform 329 subsequent analysis. 331 Real-time monitoring: A SIP CLF allows administrators to visually 332 notice the events occurring at a SIP server in real-time providing 333 accurate situational awareness. 335 7. Challenges in establishing a SIP CLF 337 Establishing a CLF for SIP is a challenging task. The behavior of a 338 SIP entity is more complex when compared to the equivalent HTTP 339 entity. 341 Base protocol services such as parallel or serial forking elicit 342 multiple final responses. Ensuing delays between sending a request 343 and receiving a final response all add complexity when considering 344 what fields should comprise a CLF and in what manner. Furthermore, 345 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 346 and these transactions may arrive at a varying inter-arrival rate at 347 a proxy. For example, the BYE transaction usually arrives much after 348 the corresponding INVITE transaction was received, serviced and 349 expunged from the transaction list. Nonetheless, it is advantageous 350 to relate these transactions such that automata or a human monitoring 351 the log file can construct a set consisting of related transactions. 353 ACK requests in SIP need careful consideration as well. In SIP, an 354 ACK is a special method that is associated with an INVITE only. It 355 does not require a response, and furthermore, if it is acknowledging 356 a non-2xx response, then the ACK is considered part of the original 357 INVITE transaction. If it is acknowledging a 2xx-class response, 358 then the ACK is a separate transaction consisting of a request only 359 (i.e., there is not a response for an ACK request.) CANCEL is 360 another method that is tied to an INVITE transaction, but unlike ACK, 361 the CANCEL request elicits a final response. 363 While most requests elicit a response immediately, the INVITE request 364 in SIP can pend at a proxy as it forks branches downstream or at a 365 user agent server while it alerts the user. RFC 3261 [2] instructs 366 the server transaction to send a 1xx-class provisional response if a 367 final response is delayed for more than 200 ms. A SIP CLF log file 368 needs to include such provisional responses because they help train 369 automata associated with anomaly detection systems and provide some 370 positive feedback for a human observer monitoring the 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. SIP CLF fields 380 The inspiration for the SIP CLF is the Apache CLF. However, the 381 state machinery for a HTTP transaction is much simpler than that of 382 the SIP transaction (as evidenced in Section 7). The SIP CLF needs 383 to do considerably more. 385 Accordingly, the following SIP CLF fields are defined as mininal 386 information that must appear in any SIP CLF record: 388 date: Date and time of the request or response represented as the 389 number of seconds and milliseconds since the Unix epoch. 391 remotehost: The DNS name or IP address of the upstream client. 393 authuser: The user name by which the user has been authenticated. 394 If the user name is unknown or when a request is challenged, the 395 value in this field must be "-" 397 method: The upper-case name of the SIP method. 399 request-uri: The Request-URI, including any URI parameters. 401 from: The From URI, including the tag. Whilst one may question the 402 value of the From URI in light of RFC4744 [4], the From URI, 403 nonetheless, imparts some information. For one, the From tag is 404 important and, in the case of a REGISTER request, the From URI can 405 provide information on whether this was a third-party registration 406 or a first-party one. 408 to: The To URI, including tag. 410 callid: The Call-ID. 412 status: The SIP response status code returned upstream. 414 contactlist: Contact URIs in the response, if any. A "-" field 415 value may be used if there aren't any Contact URIs. 417 server-txn: Server transaction identification code - the transaction 418 identifier associated with the server transaction. 419 Implementations can reuse the server transaction identifier (the 420 topmost branch-id of the incoming request, with or without the 421 magic cookie), or they could generate a unique identification 422 string for a server transaction (this identifier needs to be 423 locally unique to the server only.) This identifier is used to 424 correlate ACKs and CANCELs to an INVITE transaction; it is also 425 used to aid in forking as explained later in this section. 427 client-txn: Client transaction identification code - this field is 428 used to associate client transactions with a server transaction 429 for forking proxies or B2BUAs. Upon forking, implementations can 430 reuse the value they inserted into the topmost Via header's branch 431 parameter, or they can generate a unique identification string for 432 the client transaction. A more detailed explanation of why it is 433 needed is provided next. 435 SIP Proxies may fork, creating several client transactions that 436 correlate to a single server transaction. Responses arriving on 437 these client transactions, or new requests (CANCEL, ACK) sent on the 438 client transaction need log file entries that correlate with a server 439 transaction. Similarly, a B2BUA may create one or more client 440 transactions in response to an incoming request. These transactions 441 will require correlation as well. 443 To best demonstrate the correlation directives "server-txn" and 444 "client-txn", some examples are necessary. In order to do so, it 445 helps to use a canonical representation for the SIP CLF. The most 446 expedient way to do so is to use an ASCII representation for 447 illustration purposes only, but to be safe, the working group 448 should okay this since a specific SIP CLF format has not been 449 defined yet. To get a gist of how these correlation directives 450 help, please see Section 6 of a predecessor [5] to this draft. 452 Finally, the SIP CLF should be extensible such that future SIP 453 methods, headers and bodies can be represented as well. 455 Note: Not sure what else to say here since the specific format 456 used to encode the CLF has some bearing on extensibility. A type- 457 length-value (TLV) format or a PCAP format has advantages over an 458 ASCII format. All three formats -- the ASCII, binary TLV format, 459 and the PCAP format -- are available in Gurbani et al. [5], Roach 460 [6], and Kaplan [7], respectively. 462 9. Security Considerations 464 A log file by its nature reveals the both the state of the entity 465 producing it and the nature of the information being logged. To the 466 extent that this state should not be publicly accessible and that the 467 information is to be considered private, appropriate file and 468 directory permissions attached to the log file should be used. In 469 the worst case, public access to the SIP log file provides the same 470 information that an adversary can gain using network sniffing tools 471 (assuming that the SIP traffic is in clear text.) If all SIP traffic 472 on a network segment is encrypted, then special attention must be 473 directed to the file and directory permissions associated with the 474 log file to preserve privacy such that only a privileged user can 475 access the contents of the log file. 477 Transporting SIP CLF files across the network pose special challenges 478 as well. While transporting SIP CLF files is out of scope in the 479 current working group charter, it seems worth drawing attention to 480 the fact that if the file is transported using unencrypted FTP or 481 email, intermediaries and adversaries may have access to the raw SIP 482 CLF records. Accordingly, if the SIP CLF file is to be moved from 483 the generating host, secure FTP or secure email must be used instead. 485 The SIP CLF represents the minimum fields that lend themselves to 486 trend analysis and serve as information that may be deemed useful. 487 Other formats can be defined that include more headers (and the body) 488 from Section 8. However, where to draw a judicial line regarding the 489 inclusion of non-mandatory headers can be challenging. Clearly, the 490 more information a SIP server logs, the longer time the logging 491 process will take, the more disk space the log entry will consume, 492 and the more potentially sensitive information could be breached. 493 Therefore, adequate tradeoffs should be taken in account when logging 494 more fields than the ones recommended in Section 8. 496 Implementers need to pay particular attention to buffer handling when 497 reading or writing log files. SIP CLF entries can be unbounded in 498 length. It would be reasonable for a full dump of a SIP message to 499 be thousands of octets long. This is of particular importance to CLF 500 log parsers, as a SIP CLF log writers may add one or more extension 501 fields to the message to be logged. 503 10. Operational guidance 505 SIP CLF log files will take up substantive amount of disk space 506 depending on traffic volume at a processing entity and the amount of 507 information being logged. As such, any enterprise using SIP CLF 508 should establish operational procedures for file rollovers as 509 appropriate to the needs of the organization. 511 Listing such operational guidelines in this document is out of scope 512 for this work. 514 11. IANA Considerations 516 This document does not require any considerations from IANA. 518 12. Acknowledgments 520 Members of the sipping, dispatch, ipfix and syslog working groups 521 provided invaluable input to the formulation of the draft. These 522 include Benoit Claise, Spencer Dawkins, David Harrington, Christer 523 Holmberg, Hadriel Kaplan, Atsushi Kobayashi, Jiri Kuthan, Scott 524 Lawrence, Simon Perreault, Adam Roach, Dan Romascanu, Robert Sparks, 525 Brian Trammell, Dale Worley, Theo Zourzouvillys and others that we 526 have undoubtedly, but inadvertently, missed. 528 Adam Roach proposed and documented the binary TLV-format and Hadriel 529 Kaplan proposed and documented the PCAP-based format as alternative 530 SIP CLF representations. 532 13. References 534 13.1. Normative References 536 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 537 Levels", BCP 14, RFC 2119, March 1997. 539 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 540 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 541 Session Initiation Protocol", RFC 3261, June 2002. 543 13.2. Informative References 545 [3] Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 546 Muller, "A Self-learning System for Detection of Anomalous SIP 547 Messages", Principles, Systems and Applications of IP 548 Telecommunications Services and Security for Next Generation 549 Networks (IPTComm), LNCS 5310, pp. 90-106, 2008. 551 [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated 552 Identity Management in the Session Initiation Protocol (SIP)", 553 RFC 4474, August 2006. 555 [5] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O. 556 Festor, "The Common Log File (CLF) format for the Session 557 Initiation Protocol (SIP)", draft-gurbani-sipping-clf-01 (work 558 in progress), March 2009. 560 [6] Roach, A., "Binary Syntax for SIP Common Log Format", 561 draft-roach-sipping-clf-syntax-01 (work in progress), May 2009. 563 [7] Kaplan, H., "PCAP-compatible Binary Syntax for SIP Common Log 564 File Format", draft-kaplan-sipping-clf-pcap-00 (work in 565 progress), June 2009. 567 [8] Debar, H., Curry, D., and B. Feinstein, "The Intrusion 568 Detection Message Exchange Format (IDMEF)", RFC 4765, 569 March 2007. 571 [9] Claise, B., "Specification of the IP Flow Information Export 572 (IPFIX) Protocol for the Exchange of IP Traffic Flow 573 Information", RFC 5101, January 2008. 575 [10] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 577 Authors' Addresses 579 Vijay K. Gurbani (editor) 580 Bell Laboratories, Alcatel-Lucent 581 1960 Lucent Lane 582 Naperville, IL 60566 583 USA 585 Email: vkg@bell-labs.com 587 Eric W. Burger (editor) 588 Neustar, Inc. 589 USA 591 Email: eburger@standardstrack.com 592 URI: http://www.standardstrack.com 593 Tricha Anjali 594 Illinois Institute of Technology 595 316 Siegel Hall 596 Chicago, IL 60616 597 USA 599 Email: tricha@ece.iit.edu 601 Humberto Abdelnur 602 INRIA 603 INRIA - Nancy Grant Est 604 Campus Scientifique 605 54506, Vandoeuvre-les-Nancy Cedex 606 France 608 Email: Humberto.Abdelnur@loria.fr 610 Olivier Festor 611 INRIA 612 INRIA - Nancy Grant Est 613 Campus Scientifique 614 54506, Vandoeuvre-les-Nancy Cedex 615 France 617 Email: Olivier.Festor@loria.fr