idnits 2.17.1 draft-ietf-sipclf-problem-statement-03.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 date (June 29, 2010) is 5048 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCLF V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Informational E. Burger, Ed. 5 Expires: December 31, 2010 This space for sale 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 June 29, 2010 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-03 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 December 31, 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 8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 9 83 8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 11 84 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9.1. UAC registeration . . . . . . . . . . . . . . . . . . . . 13 86 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 14 87 9.3. Single downstream branch call . . . . . . . . . . . . . . 15 88 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 18 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 24 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 93 14. Bit-exact archive for SIP CLF records . . . . . . . . . . . . 24 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 15.1. Normative References . . . . . . . . . . . . . . . . . . . 27 96 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 RFC 3261 [RFC3261] defines additional terms used in this document 106 that are specific to the SIP domain such as "proxy"; "registrar"; 107 "redirect server"; "user agent server" or "UAS"; "user agent client" 108 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 109 "transaction"; "server transaction". 111 This document uses the term "SIP Server" that is defined to include 112 the following SIP entities: user agent server, registrar, redirect 113 server, a SIP proxy in the role of user agent server, and a B2BUA in 114 the role of a user agent server. 116 2. Introduction 118 Servers executing on Internet hosts produce log records as part of 119 their normal operations. A log record is, in essence, a summary of 120 an application layer protocol data unit (PDU), that captures in 121 precise terms an event that was processed by the server. These log 122 records serve many purposes, including analysis and troubleshooting. 124 Well-known web servers such as Apache and Squid support event logging 125 using a Common Log Format (CLF), the common structure for logging 126 requests and responses serviced by the web server. It can be argued 127 that a good part of the success of Apache has been its CLF because it 128 allowed third parties to produce tools that analyzed the data and 129 generated traffic reports and trends. The Apache CLF has been so 130 successful that not only did it become the de-facto standard in 131 producing logging data for web servers, but also many commercial web 132 servers can be configured to produce logs in this format. An example 133 of Apache CLF is depicted next: 135 %h %l %u %t \"%r\" %s %b 136 remotehost rfc931 authuser [date] request status bytes 138 remotehost: Remote hostname (or IP number if DNS hostname is not 139 available, or if DNSLookup is Off. 141 rfc931: The remote logname of the user. 143 authuser: The username by which the user has authenticated himself. 145 [date]: Date and time of the request. 147 request: The request line exactly as it came from the client. 149 status: The HTTP status code returned to the client. 151 bytes: The content-length of the document transferred. 153 The inspiration for the SIP CLF is the Apache CLF. However, the 154 state machinery for a HTTP transaction is much simpler than that of 155 the SIP transaction (as evidenced in Section 7). The SIP CLF needs 156 to do considerably more. 158 3. Problem statement 160 The Session Initiation Protocol [RFC3261](SIP) is an Internet 161 multimedia session signaling protocol that is increasingly used for 162 other services besides session establishment. A typical deployment 163 of SIP in an enterprise will consist of SIP entities from multiple 164 vendors. Currently, if these entities are capable of producing a log 165 file of the transactions being handled by them, the log files are 166 produced in a proprietary format. The result of multiplicity of the 167 log file formats is the inability of the support staff to easily 168 trace a call from one entity to another, or even to craft common 169 tools that will perform trend analysis, debugging and troubleshooting 170 problems uniformly across the SIP entities of multiple vendors. 172 SIP does not currently have a CLF format and this document serves to 173 provide the rationale to establish a SIP CLF and identifies the 174 required minimal information that must appear in any SIP CLF record. 176 4. What SIP CLF is and what it is not 178 The SIP CLF is a standardized manner of producing a log file. This 179 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 180 The SIP CLF is simply an easily digestible log of currently occurring 181 events and past transactions. It contains enough information to 182 allow humans and automata to derive relationships between discrete 183 transactions handled at a SIP entity or to search for a certain 184 dialog or a related set of transactions. 186 Note: The exact form of the "concise command" is left unspecified 187 until the working group agrees to one or more formats for encoding 188 the fields. 190 The SIP CLF is amenable to quick parsing (i.e., well-delimited 191 fields) and it is platform and operating system neutral. 193 The SIP CLF is amenable to easy parsing and lends itself well to 194 creating other innovative tools. 196 The SIP CLF is not a billing tool. It is not expected that 197 enterprises will bill customers based on SIP CLF. The SIP CLF 198 records events at the signaling layer only and does not attempt to 199 correlate the veracity of these events with the media layer. Thus, 200 it cannot be used to trigger customer billing. 202 The SIP CLF is not a quality of service (QoS) measurement tool. If 203 QoS is defined as measuring the mean opinion score (MOS) of the 204 received media, then SIP CLF does not aid in this task since it does 205 not summarize events at the media layer. 207 5. Alternative approaches to SIP CLF 209 It is perhaps tempting to consider other approaches --- which though 210 not standardized, are in wide enough use in networks today --- to 211 determine whether or not a SIP CLF would benefit a SIP network 212 consisting of multi-vendor products. The two existing approaches 213 that approximate what SIP CLF does are Call Detail Records (CDRs) and 214 Wireshark packet sniffing. 216 5.1. SIP CLF and CDRs 218 CDRs are used in operator networks widely and with the adoption of 219 SIP, standardization bodies such as 3GPP have subsequently defined 220 SIP-related CDRs as well. Today, CDRs are used to implement the 221 functionality approximated by SIP CLF, however, there are important 222 differences. 224 One, SIP CLF operates natively at the transaction layer and maintains 225 enough information in the information elements being logged that 226 dialog-related data can be subsequently derived from the transaction 227 logs. Thus, esoteric SIP fields and parameters like the To header, 228 including tags; the From header, including tags, the CSeq number, 229 etc. are logged in SIP CLF. By contrast, a CDR is used mostly for 230 charging and thus saves information to facilitate that very aspect. 231 A CDR will most certainly log the public user identification of a 232 party requesting a service (which may not correspond to the From 233 header) and the public user identification of the party called party 234 (which may not correspond to the To header.) Furthermore, the 235 sequence numbers maintained by the CDR may not correspond to the SIP 236 CSeq header. Thus it will be hard to piece together the state of a 237 dialog through a sequence of CDR records. 239 Two, a CDR record will, in all probability, be generated at a SIP 240 entity performing some form of proxy-like functionality of a B2BUA 241 providing some service. By contrast, SIP CLF is light- weight enough 242 that it can be generated by a canonical SIP user agent server and 243 user agent client as well, including those that execute on resource 244 constrained devices (mobile phones). 246 Finally, SIP is also being deployed outside of operator- managed VoIP 247 networks. Universities, research laboratories, and small-to-medium 248 size companies are deploying SIP-based VoIP solutions on networks 249 owned and managed by them. Much of the latter constituencies will 250 not have an interest in generating CDRs, but they will like to have a 251 concise representation of the messages being handled by the SIP 252 entities in a common format. 254 5.2. SIP CLF and Wireshark packet capture 256 Wireshark is a popular raw packet capture tool. It contains filters 257 that can understand SIP at the protocol level and break down a 258 captured message into its individual header components. While 259 Wireshark is appropriate to capture and view discrete SIP messages, 260 it does not suffice to serve in the same capacity as SIP CLF for two 261 reasons. 263 First, all SIP entities that need to save SIP CLF records would 264 require a Wireshark library for different operating systems and 265 configurations to link into. Second, and more importantly, if the 266 SIP messages are exchanged over a TLS-oriented transport, Wireshark 267 will be unable to decrypt them and render them as individual SIP 268 headers. 270 6. Motivation and use cases 272 As SIP becomes pervasive in multiple business domains and ubiquitous 273 in academic and research environments, it is beneficial to establish 274 a CLF for the following reasons: 276 Common reference for interpreting events: In a laboratory 277 environment or an enterprise service offering there will typically 278 be SIP entities from multiple vendors participating in routing 279 requests. Absent a CLF format, each entity will produce output 280 records in a native format making it hard to establish commonality 281 for tools that operate on the log file. 283 Writing common tools: A CLF format allows independent tool providers 284 to craft tools and applications that interpret the CLF data to 285 produce insightful trend analysis and detailed traffic reports. 286 The format should be such that it retains the ability to be read 287 by humans and processed using traditional Unix text processing 288 tools. 290 Session correlation across diverse processing elements: In 291 operational SIP networks, a request will typically be processed by 292 more than one SIP server. A SIP CLF will allow the network 293 operator to trace the progression of the request (or a set of 294 requests) as they traverse through the different servers to 295 establish a concise diagnostic trail of a SIP session. 297 Note that tracing the request through a set of servers is 298 considerably less challenging if all the servers belong to the 299 same administrative domain. 301 Message correlation across transactions: A SIP CLF can enable a 302 quick lookup of all messages that comprise a transaction (e.g., 303 "Find all messages corresponding to server transaction X, 304 including all forked branches.") 306 Message correlation across dialogs: A SIP CLF can correlate 307 transactions that comprise a dialog (e.g., "Find all messages for 308 dialog created by Call-ID C, From tag F and To tag T.") 310 Trend analysis: A SIP CLF allows an administrator to collect data 311 and spot patterns or trends in the information (e.g., "What is the 312 domain where the most sessions are routed to between 9:00 AM and 313 12:00 PM?") 315 Train anomaly detection systems: A SIP CLF will allow for the 316 training of anomaly detection systems that once trained can 317 monitor the CLF file to trigger an alarm on the subsequent 318 deviations from accepted patterns in the data set. Currently, 319 anomaly detection systems monitor the network and parse raw 320 packets that comprise a SIP message -- a process that is 321 unsuitable for anomaly detection systems [rieck2008]. With all 322 the necessary event data at their disposal, network operations 323 managers and information technology operation managers are in a 324 much better position to correlate, aggregate, and prioritize log 325 data to maintain situational awareness. 327 Testing: A SIP CLF allows for automatic testing of SIP equipment by 328 writing tools that can parse a SIP CLF file to ensure behavior of 329 a device under test. 331 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 332 SIP entity (e.g., "How long did it take to generate a final 333 response for the INVITE associated with Call-ID X?") 335 Offline analysis: A SIP CLF allows for offline analysis of the data 336 gathered. Once a SIP CLF file has been generated, it can be 337 transported (subject to the security considerations in Section 10) 338 to a host with appropriate computing resources to perform 339 subsequent analysis. 341 Real-time monitoring: A SIP CLF allows administrators to visually 342 notice the events occurring at a SIP entity in real-time providing 343 accurate situational awareness. 345 7. Challenges in establishing a SIP CLF 347 Establishing a CLF for SIP is a challenging task. The behavior of a 348 SIP entity is more complex when compared to the equivalent HTTP 349 entity. 351 Base protocol services such as parallel or serial forking elicit 352 multiple final responses. Ensuing delays between sending a request 353 and receiving a final response all add complexity when considering 354 what fields should comprise a CLF and in what manner. Furthermore, 355 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 356 and these transactions may arrive at a varying inter-arrival rate at 357 a proxy. For example, the BYE transaction usually arrives much after 358 the corresponding INVITE transaction was received, serviced and 359 expunged from the transaction list. Nonetheless, it is advantageous 360 to relate these transactions such that automata or a human monitoring 361 the log file can construct a set consisting of related transactions. 363 ACK requests in SIP need careful consideration as well. In SIP, an 364 ACK is a special method that is associated with an INVITE only. It 365 does not require a response, and furthermore, if it is acknowledging 366 a non-2xx response, then the ACK is considered part of the original 367 INVITE transaction. If it is acknowledging a 2xx-class response, 368 then the ACK is a separate transaction consisting of a request only 369 (i.e., there is not a response for an ACK request.) CANCEL is 370 another method that is tied to an INVITE transaction, but unlike ACK, 371 the CANCEL request elicits a final response. 373 While most requests elicit a response immediately, the INVITE request 374 in SIP can pend at a proxy as it forks branches downstream or at a 375 user agent server while it alerts the user. RFC 3261 [RFC3261] 376 instructs the server transaction to send a 1xx-class provisional 377 response if a final response is delayed for more than 200 ms. A SIP 378 CLF log file needs to include such provisional responses because they 379 help train automata associated with anomaly detection systems and 380 provide some positive feedback for a human observer monitoring the 381 log file. 383 Finally, beyond supporting native SIP actors such as proxies, 384 registrars, redirect servers, and user agent servers (UAS), it is 385 beneficial to derive a CLF format that supports back-to-back user 386 agent (B2BUA) behavior, which may vary considerably depending on the 387 specific nature of the B2BUA. 389 8. Data model 391 8.1. SIP CLF mandatory fields 393 The following SIP CLF fields are defined as minimal information that 394 MUST appear in any SIP CLF record: 396 Timestamp - Date and time of the request or response represented as 397 the number of seconds and milliseconds since the Unix epoch. 399 Size of the SIP CLF record - The total number of bytes that comprise 400 the SIP CLF record. 402 Message type - An indicator on whether the SIP message is a request 403 or a response. The allowable values for this field are 'R' (for 404 Request) and 'r' (for response). 406 Directionality - An indicator on whether the SIP message is received 407 by the SIP entity or sent by the SIP entity. The allowable values 408 for this field are 's' (for message sent) and 'r' (for message 409 received). 411 Source:port:xport - The DNS name or IP address of the upstream 412 client, including the port number and the transport over which the 413 SIP message was received. The port number must be separated from 414 the DNS name or IP address by a single ':'. The transport must be 415 separated from the port by a single ':'. The allowable values for 416 the transport are governed by the "transport" production rule in 417 Section 25.1 of RFC3261 [RFC3261]. 419 Destination:port:xport - The DNS name or IP address of the 420 downstream server, including the port number. The port number 421 must be separated from the DNS name or IP address by a single ':'. 422 The transport must be separated from the port by a single ':'. 423 The allowable values for the transport are governed by the 424 "transport" production rule in Section 25.1 of RFC3261 [RFC3261]. 426 From - The From URI, including the tag. Whilst one may question the 427 value of the From URI in light of RFC4744 [RFC4474], the From URI, 428 nonetheless, imparts some information. For one, the From tag is 429 important and, in the case of a REGISTER request, the From URI can 430 provide information on whether this was a third-party registration 431 or a first-party one. 433 To - The To URI, including tag. 435 Callid - The Call-ID. 437 CSeq - The CSeq header. 439 R-URI - The Request-URI, including any URI parameters. 441 Status - The SIP response status code. 443 SIP Proxies may fork, creating several client transactions that 444 correlate to a single server transaction. Responses arriving on 445 these client transactions, or new requests (CANCEL, ACK) sent on the 446 client transaction need log file entries that correlate with a server 447 transaction. Similarly, a B2BUA may create one or more client 448 transactions in response to an incoming request. These transactions 449 will require correlation as well. The last two data model elements 450 provide this correlation. 452 Server-Txn - Server transaction identification code - the 453 transaction identifier associated with the server transaction. 454 Implementations can reuse the server transaction identifier (the 455 topmost branch-id of the incoming request, with or without the 456 magic cookie), or they could generate a unique identification 457 string for a server transaction (this identifier needs to be 458 locally unique to the server only.) This identifier is used to 459 correlate ACKs and CANCELs to an INVITE transaction; it is also 460 used to aid in forking as explained later in this section. (See 461 Section 9 for usage.) 463 Client-Txn - Client transaction identification code - this field is 464 used to associate client transactions with a server transaction 465 for forking proxies or B2BUAs. Upon forking, implementations can 466 reuse the value they inserted into the topmost Via header's branch 467 parameter, or they can generate a unique identification string for 468 the client transaction. (See Section 9 for usage.) 470 Finally, the SIP CLF should be extensible such that future SIP 471 methods, headers and bodies can be represented as well. Besides the 472 mandatory fields listed above, any other SIP header that needs to be 473 logged will appear as an ordered pair of header field name and value. 475 This data model applies to all SIP entities --- a UAC, UAS, Proxy, a 476 B2BUA, registrar and redirect server. Note that a B2BUA is a 477 degenerate case of a proxy and as such the SIP CLF field layout 478 format prescribed for a proxy is equally applicable to the B2BUA. 479 Similarly, registrars and redirect servers are a degenerate case of a 480 UAS, and as such the SIP CLF field layout prescribed for a UAS is 481 equally applicable to registrars and redirect servers. 483 The next section specifies the individual SIP CLF data model elements 484 that form a log record for specific instance of a SIP entity. We 485 limit our specification to using the minimum data model elements. It 486 is understood that a SIP CLF record is extensible using extension 487 mechanisms appropriate to the specific representation used to 488 generate the SIP CLF record. This document, however, does not 489 prescribe a specific representation format and it limits the 490 discussion to the mandatory data elements described above. 492 8.2. Mandatory fields and SIP entities 494 Each SIP CLF record MUST consist of all the mandatory data model 495 elements outlined in Section 8.1. This document does not specify a 496 representation of a logging format; it is expected that other 497 documents will do so. Each SIP CLF record MUST contain the mandatory 498 elements in the order shown below: 500 Record size, Timestamp, Message type, Directionality, CSeq, 501 R-URI, Destination:port:xport, Source:port:xport, To, From, 502 Call-ID, Status, Server-Txn, Client-Txn 504 Table 1 summarizes how the mandatory fields are logged by a UAC, UAS, 505 or UAC-half, UAS-half of a SIP proxy and B2BUA. In the table below: 507 R: implies that the field is logged when a request is handled by that 508 SIP entity. 510 r: implies that the field is logged when a response is handled by 511 that SIP entity. 513 -: implies that the field is not applicable to that SIP entity. 515 +------------------------+-----+-----+----------+----------+ 516 | | UAC | UAS | UAS-half | UAC-half | 517 +------------------------+-----+-----+----------+----------+ 518 | Timestamp | R,r | R,r | R,r | R,r | 519 | SIP CLF record size | R,r | R,r | R,r | R,r | 520 | Message type | R,r | R,r | R,r | R,r | 521 | Directionality | R,r | R,r | R,r | R,r | 522 | CSeq | R,r | R,r | R,r | R,r | 523 | R-URI | R | R | R | R | 524 | Destination:port:xport | R,r | R,r | R,r | R,r | 525 | Source:port:xport | R,r | R,r | R,r | R,r | 526 | To | R,r | R,r | R,r | R,r | 527 | From | R,r | R,r | R,r | R,r | 528 | Call-ID | R,r | R,r | R,r | R,r | 529 | Status | r | r | r | r | 530 | Server-Txn | - | R,r | R,r | R,r | 531 | Client-Txn | R,r | - | r | R,r | 532 +------------------------+-----+-----+----------+----------+ 534 SIP CLF fields logged per entity 536 Table 1 538 9. Examples 540 The examples use only the mandatory data elements defined in 541 Section 8.1. Extension elements are not considered. The examples 542 below use the template defined in Section 8.2 when logging a SIP CLF 543 record. When a given mandatory field is not applicable to a SIP 544 entity as determined by Table 1, we use the horizontal dash ("-") to 545 represent it. The CSeq header field is represented by Method-Number 546 (e.g., INVITE-32). Each field is separated from its neighbors using 547 a single white space. 549 It is important to note that the syntax for the examples in this 550 section is for illustration purposes only, and is not a specific 551 representation of a logging format. It is expected that one or more 552 documents will outline specific formats for logging. 554 There are five principals in the examples below. They are Alice, the 555 initiator of requests. Alice's user agent uses IPv4 address 556 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 557 on their way to Bob, the recipient of the requests. P1 also acts as 558 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 559 5060. Bob has two instances of his user agent running on different 560 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 561 5060 and the second instance uses an IPv6 address of 2001:db8::9, 562 port 5060. P2 is a proxy responsible for Bob's domain. Table 2 563 summarizes these addresses. 565 +-------------------+--------------------+-------------------+ 566 | Principal | IP:port | Host/Domain name | 567 +-------------------+--------------------+-------------------+ 568 | Alice | 198.51.100.1:5060 | alice.example.com | 569 | P1 | 198.51.100.10:5060 | p1.example.com | 570 | P2 | 203.0.113.200:5060 | p2.example.net | 571 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 572 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 573 +-------------------+--------------------+-------------------+ 575 Principal to IP address asignment 577 Table 2 579 Illustrative examples of SIP CLF follow. These examples use the 580 tag defined in [RFC4475] to logically denote a single 581 line. 583 9.1. UAC registeration 585 Alice sends a registration registrar P1 and receives a 2xx-class 586 response. The register requests causes Alice's UAC to produce a log 587 record shown below. The mandatory data model elements correspond to 588 those listed in Table 1. 590 591 1275930743.699 R s REGISTER-1 sip:example.com 592 198.51.100.10:5060:udp 198.51.100.1:5060:udp 593 sip:example.com sip:alice@example.com;tag=76yhh 594 f81-d4-f6@example.com - - c-tr-1 595 597 After some time, Alice's UAC will receive a response from the 598 registrar. The response causes Alice's agent to produce a log record 599 shown below. The mandatory data elements correspond to those listed 600 in Table 1. 602 603 173 1275930744.100 r r REGISTER-1 - 198.51.100.1:5060:udp 604 198.51.100.10:5060:udp sip:example.com;tag=reg-1xtr 605 sip:alice@example.com;tag=76yhh f81-d4-f6@example.com 606 200 - c-tr-1 607 609 9.2. Direct call between Alice and Bob 611 In this example, Alice sends a session initiation request directly to 612 Bob's agent (instance 1.) Bob's agent accepts the session 613 invitation. We first present the SIP CLF logging from Alice's UAC 614 point of view. In line 1, Alice's user agent sends out the INVITE. 615 Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" 616 response (line 3). Upon the receipt of the 2xx-class response, 617 Alice's user agent sends out an ACK request (line 4). 619 620 183 1275930743.699 R s INVITE-32 sip:bob@bob1.example.net 621 203.0.113.1:5060:udp 198.51.100.1:5060:udp 622 sip:bob@example.net sip:alice@example.com;tag=76yhh 623 f82-d4-f7@example.com - - c-1-xt6 624 626 627 175 1275930745.002 r r INVITE-32 - 198.51.100.1:5060:udp 628 203.0.113.1:5060:udp sip:bob@example.net;tag=b-in6-iu 629 sip:alice@example.com;tag=76yhh f82-d4-f7@example.com 630 180 - c-1-xt6 631 633 634 175 1275930746.100 r r INVITE-32 - 198.51.100.1:5060:udp 635 203.0.113.1:5060:udp sip:bob@example.net;tag=b-in6-iu 636 sip:alice@example.com;tag=76yhh f82-d4-f7@example.com 637 200 - c-1-xt6 638 640 641 193 1275930746.120 R s ACK-32 sip:bob@bob1.example.net 642 203.0.113.1:5060:udp 198.51.100.1:5060:udp 643 sip:bob@example.net;tag=b-in6-iu 644 sip:alice@example.com;tag=76yhh f82-d4-f7@example.com 645 - - c-1-xt6 646 648 9.3. Single downstream branch call 650 In this example, Alice sends a session invitation request to Bob 651 through proxy P1, which inserts a Record-Route header causing 652 subsequent requests between Alice and Bob to traverse the proxy. The 653 SIP CLF log records correspond to the viewpoint of P1. The log 654 records are presented one per logical line and the line numbers refer 655 to Figure 1 657 Alice P1 Bob 658 +---INV--------->| | Line 1 659 | | | 660 |<---------100---+ | Line 2 661 | | | 662 | +---INV-------->| Line 3 663 | | | 664 | |<--------100---+ Line 4 665 | | | 666 | |<--------180---+ Line 5 667 | | | 668 |<---------180---+ | Line 6 669 | | | 670 | |<--------200---+ Line 7 671 | | | 672 |<---------200---+ | Line 8 673 | | | 674 +---ACK--------->| | Line 9 675 | | | 676 | |---ACK-------->| Line 10 678 Figure 1: Simple proxy-aided call flow 680 681 1 175 1275930743.699 R r INVITE-43 sip:bob@example.net 682 198.51.100.10:5060:udp 198.51.100.1:5060:udp 683 sip:bob@example.net sip:alice@example.com;tag=al-1 684 tr-87h@example.com - s-x-tr - 685 687 Note that at this point P1 has created a server transaction 688 identification code and populated the SIP CLF field Server-Txn with 689 it. P1 has not yet created a client transaction identification code, 690 thus Client-Txn contains a "-". 692 693 2 159 1275930744.001 r s INVITE-43 - 198.51.100.1:5060:udp 694 198.51.100.10:5060:udp sip:bob@example.net 695 sip:alice@example.com;tag=al-1 tr-87h@example.com 696 100 s-x-tr - 697 699 700 3 184 1275930744.998 R s INVITE-43 sip:bob@bob1.example.net 701 203.0.113.1:5060:udp 198.51.100.10:5060:udp 702 sip:bob@example.net sip:alice@example.com;tag=al-1 703 tr-87h@example.com - s-x-tr c-x-tr 704 706 In line 3 above, P1 has created a client transaction identification 707 code for the downstream branch and populated the SIP CLF field 708 Client-Txn. 710 711 4 172 1275930745.200 r r INVITE-43 - 198.51.100.10:5060:udp 712 203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1 713 sip:alice@example.com;tag=al-1 tr-87h@example.com 714 100 s-x-tr c-x-tr 715 717 718 5 172 1275930745.800 r r INVITE-43 - 198.51.100.10:5060:udp 719 203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1 720 sip:alice@example.com;tag=al-1 tr-87h@example.com 721 180 s-x-tr c-x-tr 722 724 725 6 173 1275930746.009 r s INVITE-43 - 198.51.100.1:5060:udp 726 198.51.100.10:5060:udp sip:bob@example.net;tag=b1-1 727 sip:alice@example.com;tag=al-1 tr-87h@example.com 180 728 s-x-tr c-x-tr 729 731 732 7 172 1275930747.120 r r INVITE-43 - 198.51.100.10:5060:udp 733 203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1 734 sip:alice@example.com;tag=al-1 tr-87h@example.com 200 735 s-x-tr c-x-tr 736 738 739 8 173 1275930747.300 r s INVITE-43 - 198.51.100.1:5060:udp 740 198.51.100.10:5060:udp sip:bob@example.net;tag=b1-1 741 sip:alice@example.com;tag=al-1 tr-87h@example.com 200 742 s-x-tr c-x-tr 743 745 746 9 186 1275930749.100 R r ACK-43 sip:bob@example.net 747 198.51.100.10:5060:udp 198.51.100.1:5060:udp 748 sip:bob@example.net;tag=b1-1 sip:alice@example.com;tag=al-1 749 tr-87h@example.com - s-x-tr c-x-tr 750 752 753 10 185 1275930749.100 R s ACK-43 sip:bob@example.net 754 203.0.113.1:5060:udp 198.51.100.10:5060:udp 755 sip:bob@example.net;tag=b1-1 sip:alice@example.com;tag=al-1 756 tr-87h@example.com - s-x-tr c-x-tr 757 759 9.4. Forked call 761 In this example, Alice sends a session invitation to Bob's proxy, P2. 762 P2 forks the session invitation request to two registered endpoints 763 corresponding to Bob's address-of-record. Both endpoints respond 764 with provisional responses. Shortly thereafter, one of Bob's user 765 agent instances accepts the call, causing P2 to send a CANCEL request 766 to the second user agent. P2 does not Record-Route, therefore the 767 subsequent ACK request from Alice to Bob's user agent does not 768 traverse through P2 (and is not shown below.) 770 Figure 2 depicts the call flow. The SIP CLF log records correspond 771 to the viewpoint of P2. The log records are presented one per 772 logical line and the line numbers refer to Figure 2. 774 Bob Bob 775 Alice P2 (Instance 1) (Instance 2) 776 +---INV--->| | | Line 1 777 | | | | 778 |<---100---+ | | Line 2 779 | | | | 780 | +---INV--->| | Line 3 781 | | | | 782 | +---INV----+-------->| Line 4 783 | | | | 784 | |<---100---+ | Line 5 785 | | | | 786 | |<---------+---100---+ Line 6 787 | | | | 788 | |<---180---+---------+ Line 7 789 | | | | 790 |<---180---+ | | Line 8 791 | | | | 792 | |<---180---+ | Line 9 793 | | | | 794 |<---180---+ | | Line 10 795 | | | | 796 | |<---200---+ | Line 11 797 | | | | 798 |<---200---+ | | Line 12 799 | | | | 800 | +---CANCEL-+-------->| Line 13 801 | | | | 802 | |<---------+---487---+ Line 14 803 | | | | 804 | +---ACK----+-------->| Line 15 805 | | | | 806 | |<---------+---200---+ Line 16 808 Figure 2: Forked call flow 810 811 1 175 1275930743.699 R r INVITE-43 sip:bob@example.net 812 203.0.113.200:5060:udp 198.51.100.1:5060:udp 813 sip:bob@example.net sip:alice@example.com;tag=a1-1 814 tr-88h@example.com - s-1-tr - 815 817 818 2 159 1275930744.001 r s INVITE-43 - 198.51.100.1:5060:udp 819 203.0.113.200:5060:udp sip:bob@example.net 820 sip:alice@example.com;tag=a1-1 821 tr-88h@example.com 100 s-1-tr - 822 824 825 3 1275930744.998 R s INVITE-43 sip:bob@bob1.example.net 826 203.0.113.1:5060:udp 203.0.113.200:5060:udp 827 sip:bob@example.net sip:alice@example.com;tag=a1-1 828 tr-88h@example.com - s-1-tr c-1-tr 829 831 832 4 186 1275930745.500 R s INVITE-43 sip:bob@bob2.example.net 833 [2001:db8::9]:5060:udp 203.0.113.200:5060:udp 834 sip:bob@example.net sip:alice@example.com;tag=a1-1 835 tr-88h@example.com - s-1-tr c-2-tr 836 838 839 5 172 1275930745.800 r r INVITE-43 - 203.0.113.200:5060:udp 840 203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1 841 sip:alice@example.com;tag=a1-1 842 tr-88h@example.com 100 s-1-tr c-1-tr 843 845 846 6 174 1275930746.100 r r INVITE-43 - 203.0.113.200:5060:udp 847 [2001:db8::9]:5060:udp sip:bob@example.net;tag=b2-2 848 sip:alice@example.com;tag=a1-1 849 tr-88h@example.com 100 s-1-tr c-2-tr 850 852 853 7 174 1275930746.700 r r INVITE-43 - 203.0.113.200:5060:udp 854 [2001:db8::9]:5060:udp sip:bob@example.net;tag=b2-2 855 sip:alice@example.com;tag=a1-1 856 tr-88h@example.com 180 s-1-tr c-2-tr 857 859 860 8 170 1275930746.990 r s INVITE-43 - 198.51.100.1:5060:udp 861 203.0.113.200:5060:udp sip:bob@example.net;b2-2 862 sip:alice@example.com;tag=a1-1 863 tr-88h@example.com 180 s-1-tr c-2-tr 864 866 867 9 170 1275930747.100 r r INVITE-43 203.0.113.200:5060:udp 868 203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1 869 sip:alice@example.com;tag=a1-1 870 tr-88h@example.com 180 s-1-tr c-1-tr 871 873 874 10 173 1275930747.300 r s INVITE-43 - 198.51.100.1:5060:udp 875 203.0.113.200:5060:udp sip:bob@example.net;tag=b1-1 876 sip:alice@example.com;tag=a1-1 877 tr-88h@example.com 180 s-1-tr c-1-tr 878 880 881 11 172 1275930747.800 r r INVITE-43 - 203.0.113.200:5060:udp 882 203.0.113.1:5060:udp sip:bob@example.net;tag=b1-1 883 sip:alice@example.com;tag=a1-1 884 tr-88h@example.com 200 s-1-tr c-1-tr 885 887 888 12 173 1275930748.000 r s INVITE-43 - 198.51.100.1:5060:udp 889 203.0.113.200:5060:udp sip:bob@example.net;tag=b1-1 890 sip:alice@example.com;tag=a1-1 891 tr-88h@example.com 200 s-1-tr c-1-tr 892 894 895 13 191 1275930748.201 R s CANCEL-43 sip:bob@bob2.example.net 896 [2001:db8::9]:5060:udp 203.0.113.200:5060:udp 897 sip:bob@example.net;b2-2 sip:alice@example.com;tag=a1-1 898 tr-88h@example.com - s-1-tr c-2-tr 899 901 902 14 170 1275930748.991 r r INVITE-43 - 203.0.113.200:5060:udp 903 [2001:db8::9]:5060:udp sip:bob@example.net;b2-2 904 sip:alice@example.com;tag=a1-1 tr-88h@example.com 905 487 s-1-tr c-2-tr 906 908 909 15 188 1275930749.455 R s ACK-43 sip:bob@bob2.example.net 910 [2001:db8::9]:5060:udp 203.0.113.200:5060:udp 911 sip:bob@example.net;b2-2 sip:alice@example.com;tag=a1-1 912 tr-88h@example.com - s-1-tr c-2-tr 913 915 917 16 170 1275930750.001 r r CANCEL-43 - 203.0.113.200:5060:udp 918 [2001:db8::9]:5060:udp sip:bob@example.net;b2-2 919 sip:alice@example.com;tag=a1-1 920 tr-88h@example.com 200 s-1-tr c-2-tr 921 923 The above SIP CLF log makes it easy to search for a specific 924 transaction or a state of the session. Section 14 contains a bit- 925 exact archive of all the SIP CLF logs in this document. On a Linux/ 926 Unix system, a command of "grep c-1-tr" on the logs in the archive 927 will readily yield the information that an INVITE was sent to 928 sip:bob@bob1.example.com, it elicited a 100 followed by a 180 and 929 then a 200. The absence of the ACK request signifies that the ACK 930 was exchanged end-to-end. 932 A command of "grep c-2-tr" yields a more complex scenario of sending 933 an INVITE to sip:bob@bob2.example.net, receiving 100 and 180. 934 However, the log makes it apparent that the request to 935 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 936 response was generated, and that the pending INVITE returned a 487. 937 The ACK to the final non-2xx response and a 200 to the CANCEL request 938 complete the exchange on that branch. 940 10. Security Considerations 942 A log file by its nature reveals both the state of the entity 943 producing it and the nature of the information being logged. To the 944 extent that this state should not be publicly accessible and that the 945 information is to be considered private, appropriate file and 946 directory permissions attached to the log file should be used. The 947 following threats may be considered for the log file while it is 948 stored: 950 o An attacker may gain access to view the log file, or may 951 surreptitiously make a copy of the log file for later viewing; 952 o An attacker may mount a replay attack by modifying existing 953 records in the log file or inserting new records; 954 o An attacker may delete parts of --- or indeed, the whole --- file. 956 It is outside the scope of this document to specify how to protect 957 the log file while it is stored on disk. However, operators may 958 consider using common administrative features such as disk encryption 959 and securing log files [schneier-1]. Operators may also consider 960 hardening the machine on which the log files are stored by 961 restricting physical access to the host as well as restricting access 962 to the files themselves. 964 In the worst case, public access to the SIP log file provides the 965 same information that an adversary can gain using network sniffing 966 tools (assuming that the SIP traffic is in clear text.) If all SIP 967 traffic on a network segment is encrypted, then as noted above, 968 special attention must be directed to the file and directory 969 permissions associated with the log file to preserve privacy such 970 that only a privileged user can access the contents of the log file. 972 Transporting SIP CLF files across the network pose special challenges 973 as well. The following threats may be considered for transferring 974 log files or while transferring individual log records: 976 o An attacker may view the records; 977 o An attacker may modify the records in transit or insert previously 978 captured records into the stream; 979 o An attacker may remove records in transit, or may stage a man- in- 980 the-middle attack to deliver a partially or entirely falsified log 981 file. 983 It is also outside the scope of this document to specify protection 984 methods for log files or log records that are being transferred 985 between hosts. However, operators may consider using common security 986 protocols described in [RFC3552] to transfer log files or individual 987 records. Alternatively, the log file may be transferred through bulk 988 methods that also guarantees integrity, or at least detects and 989 alerts to modification attempts. 991 The SIP CLF represents the minimum fields that lend themselves to 992 trend analysis and serve as information that may be deemed useful. 993 Other formats can be defined that include more headers (and the body) 994 from Section 8.1. However, where to draw a judicial line regarding 995 the inclusion of non-mandatory headers can be challenging. Clearly, 996 the more information a SIP entity logs, the longer time the logging 997 process will take, the more disk space the log entry will consume, 998 and the more potentially sensitive information could be breached. 999 Therefore, adequate tradeoffs should be taken in account when logging 1000 more fields than the ones recommended in Section 8.1. 1002 Implementers need to pay particular attention to buffer handling when 1003 reading or writing log files. SIP CLF entries can be unbounded in 1004 length. It would be reasonable for a full dump of a SIP message to 1005 be thousands of octets long. This is of particular importance to CLF 1006 log parsers, as a SIP CLF log writers may add one or more extension 1007 fields to the message to be logged. 1009 11. Operational guidance 1011 SIP CLF log files will take up substantive amount of disk space 1012 depending on traffic volume at a processing entity and the amount of 1013 information being logged. As such, any enterprise using SIP CLF 1014 should establish operational procedures for file rollovers as 1015 appropriate to the needs of the organization. 1017 Listing such operational guidelines in this document is out of scope 1018 for this work. 1020 NOTE: Preliminary volume analysis was presented to the working group 1021 mailing list during the Anaheim IETF (please see 1022 http://www.ietf.org/mail-archive/web/sip-clf/current/msg00123.html 1023 for the analysis.) An open question is whether the working group 1024 thinks that this analysis should be put in this document. 1026 12. IANA Considerations 1028 This document does not require any considerations from IANA. 1030 13. Acknowledgments 1032 Members of the sipping, dispatch, ipfix and syslog working groups 1033 provided invaluable input to the formulation of the draft. These 1034 include Benoit Claise, Spencer Dawkins, John Elwell, David 1035 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1036 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Simon Perreault, Adam 1037 Roach, Dan Romascanu, Robert Sparks, Brian Trammell, Dale Worley, 1038 Theo Zourzouvillys and others that we have undoubtedly, but 1039 inadvertently, missed. 1041 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1042 Salgueiro helped tremendously in discussions related to arriving at 1043 the beginnings of a data model. 1045 14. Bit-exact archive for SIP CLF records 1047 The following text block is a base64 encoded archive of all the SIP 1048 CLF records present in this document. To recover the unencoded file, 1049 the text of this document may be passed as input to the following 1050 perl script (the output should be redirected to a file). 1052 #!/usr/bin/perl 1053 use strict; 1054 my $bdata = ""; 1055 use MIME::Base64; 1056 while(<>) 1057 { 1058 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) 1059 { 1060 if ( m/^\s*[^\s]+\s*$/) 1061 { 1062 $bdata = $bdata . $_; 1063 } 1064 } 1065 } 1066 print decode_base64($bdata); 1068 -- BEGIN MESSAGE ARCHIVE -- 1069 MTcyIDEyNzU5MzA3NDMuNjk5IFIgcyBSRUdJU1RFUi0xIHNpcDpleGFtcGxlLmNvbSAx 1070 OTguNTEuMTAwLjEwOjUwNjA6dWRwIDE5OC41MS4xMDAuMTo1MDYwOnVkcCBzaXA6ZXhh 1071 bXBsZS5jb20gc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz03NnloaCBmODEtZDQtZjZA 1072 ZXhhbXBsZS5jb20gLSAtIGMtdHItMQoxNzMgMTI3NTkzMDc0NC4xMDAgciByIFJFR0lT 1073 VEVSLTEgLSAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgMTk4LjUxLjEwMC4xMDo1MDYwOnVk 1074 cCBzaXA6ZXhhbXBsZS5jb207dGFnPXJlZy0xeHRyIHNpcDphbGljZUBleGFtcGxlLmNv 1075 bTt0YWc9NzZ5aGggZjgxLWQ0LWY2QGV4YW1wbGUuY29tIDIwMCAtIGMtdHItMQoxODMg 1076 MTI3NTkzMDc0My42OTkgUiBzIElOVklURS0zMiBzaXA6Ym9iQGJvYjEuZXhhbXBsZS5u 1077 ZXQgMjAzLjAuMTEzLjE6NTA2MDp1ZHAgMTk4LjUxLjEwMC4xOjUwNjA6dWRwIHNpcDpi 1078 b2JAZXhhbXBsZS5uZXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz03NnloaCBmODIt 1079 ZDQtZjdAZXhhbXBsZS5jb20gLSAtIGMtMS14dDYKMTc1IDEyNzU5MzA3NDUuMDAyIHIg 1080 ciBJTlZJVEUtMzIgLSAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgMjAzLjAuMTEzLjE6NTA2 1081 MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9Yi1pbjYtaXUgc2lwOmFsaWNlQGV4 1082 YW1wbGUuY29tO3RhZz03NnloaCBmODItZDQtZjdAZXhhbXBsZS5jb20gMTgwIC0gYy0x 1083 LXh0NgoxNzUgMTI3NTkzMDc0Ni4xMDAgciByIElOVklURS0zMiAtIDE5OC41MS4xMDAu 1084 MTo1MDYwOnVkcCAyMDMuMC4xMTMuMTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0 1085 O3RhZz1iLWluNi1pdSBzaXA6YWxpY2VAZXhhbXBsZS5jb207dGFnPTc2eWhoIGY4Mi1k 1086 NC1mN0BleGFtcGxlLmNvbSAyMDAgLSBjLTEteHQ2CjE5MyAxMjc1OTMwNzQ2LjEyMCBS 1087 IHMgQUNLLTMyIHNpcDpib2JAYm9iMS5leGFtcGxlLm5ldCAyMDMuMC4xMTMuMTo1MDYw 1088 OnVkcCAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9 1089 Yi1pbjYtaXUgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz03NnloaCBmODItZDQtZjdA 1090 ZXhhbXBsZS5jb20gLSAtIGMtMS14dDYKMTc1IDEyNzU5MzA3NDMuNjk5IFIgciBJTlZJ 1091 VEUtNDMgc2lwOmJvYkBleGFtcGxlLm5ldCAxOTguNTEuMTAwLjEwOjUwNjA6dWRwIDE5 1092 OC41MS4xMDAuMTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0IHNpcDphbGljZUBl 1093 eGFtcGxlLmNvbTt0YWc9YWwtMSB0ci04N2hAZXhhbXBsZS5jb20gLSBzLXgtdHIgLQox 1094 NTkgMTI3NTkzMDc0NC4wMDEgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAuMTo1MDYw 1095 OnVkcCAxOTguNTEuMTAwLjEwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQgc2lw 1096 OmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hbC0xIHRyLTg3aEBleGFtcGxlLmNvbSAxMDAg 1097 cy14LXRyIC0KMTg0IDEyNzU5MzA3NDQuOTk4IFIgcyBJTlZJVEUtNDMgc2lwOmJvYkBi 1098 b2IxLmV4YW1wbGUubmV0IDIwMy4wLjExMy4xOjUwNjA6dWRwIDE5OC41MS4xMDAuMTA6 1099 NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldCBzaXA6YWxpY2VAZXhhbXBsZS5jb207 1100 dGFnPWFsLTEgdHItODdoQGV4YW1wbGUuY29tIC0gcy14LXRyIGMteC10cgoxNzIgMTI3 1101 NTkzMDc0NS4yMDAgciByIElOVklURS00MyAtIDE5OC41MS4xMDAuMTA6NTA2MDp1ZHAg 1102 MjAzLjAuMTEzLjE6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9YjEtMSBz 1103 aXA6YWxpY2VAZXhhbXBsZS5jb207dGFnPWFsLTEgdHItODdoQGV4YW1wbGUuY29tIDEw 1104 MCBzLXgtdHIgYy14LXRyCjE3MiAxMjc1OTMwNzQ1LjgwMCByIHIgSU5WSVRFLTQzIC0g 1105 MTk4LjUxLjEwMC4xMDo1MDYwOnVkcCAyMDMuMC4xMTMuMTo1MDYwOnVkcCBzaXA6Ym9i 1106 QGV4YW1wbGUubmV0O3RhZz1iMS0xIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YWwt 1107 MSB0ci04N2hAZXhhbXBsZS5jb20gMTgwIHMteC10ciBjLXgtdHIKMTczIDEyNzU5MzA3 1108 NDYuMDA5IHIgcyBJTlZJVEUtNDMgLSAxOTguNTEuMTAwLjE6NTA2MDp1ZHAgMTk4LjUx 1109 LjEwMC4xMDo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0O3RhZz1iMS0xIHNpcDph 1110 bGljZUBleGFtcGxlLmNvbTt0YWc9YWwtMSB0ci04N2hAZXhhbXBsZS5jb20gMTgwIHMt 1111 eC10ciBjLXgtdHIKMTcyIDEyNzU5MzA3NDcuMTIwIHIgciBJTlZJVEUtNDMgLSAxOTgu 1112 NTEuMTAwLjEwOjUwNjA6dWRwIDIwMy4wLjExMy4xOjUwNjA6dWRwIHNpcDpib2JAZXhh 1113 bXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hbC0xIHRy 1114 LTg3aEBleGFtcGxlLmNvbSAyMDAgcy14LXRyIGMteC10cgoxNzMgMTI3NTkzMDc0Ny4z 1115 MDAgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAuMTo1MDYwOnVkcCAxOTguNTEuMTAw 1116 LjEwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNl 1117 QGV4YW1wbGUuY29tO3RhZz1hbC0xIHRyLTg3aEBleGFtcGxlLmNvbSAyMDAgcy14LXRy 1118 IGMteC10cgoxODYgMTI3NTkzMDc0OS4xMDAgUiByIEFDSy00MyBzaXA6Ym9iQGV4YW1w 1119 bGUubmV0IDE5OC41MS4xMDAuMTA6NTA2MDp1ZHAgMTk4LjUxLjEwMC4xOjUwNjA6dWRw 1120 IHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29t 1121 O3RhZz1hbC0xIHRyLTg3aEBleGFtcGxlLmNvbSAtIHMteC10ciBjLXgtdHIKMTg1IDEy 1122 NzU5MzA3NDkuMTAwIFIgcyBBQ0stNDMgc2lwOmJvYkBleGFtcGxlLm5ldCAyMDMuMC4x 1123 MTMuMTo1MDYwOnVkcCAxOTguNTEuMTAwLjEwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBs 1124 ZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hbC0xIHRyLTg3 1125 aEBleGFtcGxlLmNvbSAtIHMteC10ciBjLXgtdHIKMTc1IDEyNzU5MzA3NDMuNjk5IFIg 1126 ciBJTlZJVEUtNDMgc2lwOmJvYkBleGFtcGxlLm5ldCAyMDMuMC4xMTMuMjAwOjUwNjA6 1127 dWRwIDE5OC41MS4xMDAuMTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0IHNpcDph 1128 bGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04OGhAZXhhbXBsZS5jb20gLSBzLTEt 1129 dHIgLQoxNTkgMTI3NTkzMDc0NC4wMDEgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAu 1130 MTo1MDYwOnVkcCAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5u 1131 ZXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBleGFtcGxlLmNv 1132 bSAxMDAgcy0xLXRyIC0KMTg0IDEyNzU5MzA3NDQuOTk4IFIgcyBJTlZJVEUtNDMgc2lw 1133 OmJvYkBib2IxLmV4YW1wbGUubmV0IDIwMy4wLjExMy4xOjUwNjA6dWRwIDIwMy4wLjEx 1134 My4yMDA6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldCBzaXA6YWxpY2VAZXhhbXBs 1135 ZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29tIC0gcy0xLXRyIGMtMS10cgox 1136 ODYgMTI3NTkzMDc0NS41MDAgUiBzIElOVklURS00MyBzaXA6Ym9iQGJvYjIuZXhhbXBs 1137 ZS5uZXQgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCAyMDMuMC4xMTMuMjAwOjUwNjA6dWRw 1138 IHNpcDpib2JAZXhhbXBsZS5uZXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0x 1139 IHRyLTg4aEBleGFtcGxlLmNvbSAtIHMtMS10ciBjLTItdHIKMTcyIDEyNzU5MzA3NDUu 1140 ODAwIHIgciBJTlZJVEUtNDMgLSAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIDIwMy4wLjEx 1141 My4xOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNl 1142 QGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBleGFtcGxlLmNvbSAxMDAgcy0xLXRy 1143 IGMtMS10cgoxNzQgMTI3NTkzMDc0Ni4xMDAgciByIElOVklURS00MyAtIDIwMy4wLjEx 1144 My4yMDA6NTA2MDp1ZHAgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1w 1145 bGUubmV0O3RhZz1iMi0yIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04 1146 OGhAZXhhbXBsZS5jb20gMTAwIHMtMS10ciBjLTItdHIKMTc0IDEyNzU5MzA3NDYuNzAw 1147 IHIgciBJTlZJVEUtNDMgLSAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIFsyMDAxOmRiODo6 1148 OV06NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxlLm5ldDt0YWc9YjItMiBzaXA6YWxpY2VA 1149 ZXhhbXBsZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29tIDE4MCBzLTEtdHIg 1150 Yy0yLXRyCjE3MCAxMjc1OTMwNzQ2Ljk5MCByIHMgSU5WSVRFLTQzIC0gMTk4LjUxLjEw 1151 MC4xOjUwNjA6dWRwIDIwMy4wLjExMy4yMDA6NTA2MDp1ZHAgc2lwOmJvYkBleGFtcGxl 1152 Lm5ldDtiMi0yIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04OGhAZXhh 1153 bXBsZS5jb20gMTgwIHMtMS10ciBjLTItdHIKMTcwIDEyNzU5MzA3NDcuMTAwIHIgciBJ 1154 TlZJVEUtNDMgMjAzLjAuMTEzLjIwMDo1MDYwOnVkcCAyMDMuMC4xMTMuMTo1MDYwOnVk 1155 cCBzaXA6Ym9iQGV4YW1wbGUubmV0O3RhZz1iMS0xIHNpcDphbGljZUBleGFtcGxlLmNv 1156 bTt0YWc9YTEtMSB0ci04OGhAZXhhbXBsZS5jb20gMTgwIHMtMS10ciBjLTEtdHIKMTcz 1157 IDEyNzU5MzA3NDcuMzAwIHIgcyBJTlZJVEUtNDMgLSAxOTguNTEuMTAwLjE6NTA2MDp1 1158 ZHAgMjAzLjAuMTEzLjIwMDo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1wbGUubmV0O3RhZz1i 1159 MS0xIHNpcDphbGljZUBleGFtcGxlLmNvbTt0YWc9YTEtMSB0ci04OGhAZXhhbXBsZS5j 1160 b20gMTgwIHMtMS10ciBjLTEtdHIKMTcyIDEyNzU5MzA3NDcuODAwIHIgciBJTlZJVEUt 1161 NDMgLSAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIDIwMy4wLjExMy4xOjUwNjA6dWRwIHNp 1162 cDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3Rh 1163 Zz1hMS0xIHRyLTg4aEBleGFtcGxlLmNvbSAyMDAgcy0xLXRyIGMtMS10cgoxNzMgMTI3 1164 NTkzMDc0OC4wMDAgciBzIElOVklURS00MyAtIDE5OC41MS4xMDAuMTo1MDYwOnVkcCAy 1165 MDMuMC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7dGFnPWIxLTEg 1166 c2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBleGFtcGxlLmNvbSAy 1167 MDAgcy0xLXRyIGMtMS10cgoxOTEgMTI3NTkzMDc0OC4yMDEgUiBzIENBTkNFTC00MyBz 1168 aXA6Ym9iQGJvYjIuZXhhbXBsZS5uZXQgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCAyMDMu 1169 MC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7YjItMiBzaXA6YWxp 1170 Y2VAZXhhbXBsZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29tIC0gcy0xLXRy 1171 IGMtMi10cgoxNzAgMTI3NTkzMDc0OC45OTEgciByIElOVklURS00MyAtIDIwMy4wLjEx 1172 My4yMDA6NTA2MDp1ZHAgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCBzaXA6Ym9iQGV4YW1w 1173 bGUubmV0O2IyLTIgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0xIHRyLTg4aEBl 1174 eGFtcGxlLmNvbSA0ODcgcy0xLXRyIGMtMi10cgoxODggMTI3NTkzMDc0OS40NTUgUiBz 1175 IEFDSy00MyBzaXA6Ym9iQGJvYjIuZXhhbXBsZS5uZXQgWzIwMDE6ZGI4Ojo5XTo1MDYw 1176 OnVkcCAyMDMuMC4xMTMuMjAwOjUwNjA6dWRwIHNpcDpib2JAZXhhbXBsZS5uZXQ7YjIt 1177 MiBzaXA6YWxpY2VAZXhhbXBsZS5jb207dGFnPWExLTEgdHItODhoQGV4YW1wbGUuY29t 1178 IC0gcy0xLXRyIGMtMi10cgoxNzAgMTI3NTkzMDc1MC4wMDEgciByIENBTkNFTC00MyAt 1179 IDIwMy4wLjExMy4yMDA6NTA2MDp1ZHAgWzIwMDE6ZGI4Ojo5XTo1MDYwOnVkcCBzaXA6 1180 Ym9iQGV4YW1wbGUubmV0O2IyLTIgc2lwOmFsaWNlQGV4YW1wbGUuY29tO3RhZz1hMS0x 1181 IHRyLTg4aEBleGFtcGxlLmNvbSAyMDAgcy0xLXRyIGMtMi10cgo= 1182 -- END MESSAGE ARCHIVE -- 1184 15. References 1186 15.1. Normative References 1188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1189 Requirement Levels", BCP 14, RFC 2119, March 1997. 1191 15.2. Informative References 1193 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1194 A., Peterson, J., Sparks, R., Handley, M., and E. 1195 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1196 June 2002. 1198 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1199 Text on Security Considerations", BCP 72, RFC 3552, 1200 July 2003. 1202 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1203 Authenticated Identity Management in the Session 1204 Initiation Protocol (SIP)", RFC 4474, August 2006. 1206 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 1207 and H. Schulzrinne, "Session Initiation Protocol (SIP) 1208 Torture Test Messages", RFC 4475, May 2006. 1210 [rieck2008] 1211 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1212 Muller, "A Self-learning System for Detection of Anomalous 1213 SIP Messages", Principles, Systems and Applications of IP 1214 Telecommunications Services and Security for Next 1215 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1216 2008. 1218 [schneier-1] 1219 Schneier, B. and J. Kelsey, "Secure audit logs to support 1220 computer forensics", ACM Transactions on Information and 1221 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1223 Authors' Addresses 1225 Vijay K. Gurbani (editor) 1226 Bell Laboratories, Alcatel-Lucent 1227 1960 Lucent Lane 1228 Naperville, IL 60566 1229 USA 1231 Email: vkg@bell-labs.com 1232 Eric W. Burger (editor) 1233 This space for sale 1234 USA 1236 Email: eburger@standardstrack.com 1237 URI: http://www.standardstrack.com 1239 Tricha Anjali 1240 Illinois Institute of Technology 1241 316 Siegel Hall 1242 Chicago, IL 60616 1243 USA 1245 Email: tricha@ece.iit.edu 1247 Humberto Abdelnur 1248 INRIA 1249 INRIA - Nancy Grant Est 1250 Campus Scientifique 1251 54506, Vandoeuvre-les-Nancy Cedex 1252 France 1254 Email: Humberto.Abdelnur@loria.fr 1256 Olivier Festor 1257 INRIA 1258 INRIA - Nancy Grant Est 1259 Campus Scientifique 1260 54506, Vandoeuvre-les-Nancy Cedex 1261 France 1263 Email: Olivier.Festor@loria.fr