RFC 6872
The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
RFC 6872: The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 🎀
Framework and Information Model ✨
Okay bestie, here's the vibe check first. 💖 This is an IETF Standards Track doc, published in February 2013, with ISSN 2070-1721. The editors are V. Gurbani (Ed.) at Bell Laboratories, Alcatel-Lucent, and E. Burger (Ed.) at Georgetown University. The other authors are T. Anjali (Illinois Institute of Technology), H. Abdelnur, and O. Festor (INRIA). The header doesn't list anything this one obsoletes or updates. 🦋
Abstract
Okay so picture this 🌸 Apache and Squid have a common log format that every sysadmin loves, because it makes troubleshooting way easier and lets tool writers build reports and trend charts. Those same logs can also train anomaly detectors and feed security event systems. SIP doesn't have one. Every server does its own logging thing, so it's a huge hassle to build tools that do trend analysis or security detection. This document lays out a framework (including requirements and a look at the existing approaches) and defines an information model for a SIP common log file format. The goal is that user agents, proxies, registrars, redirect servers, and back-to-back user agents can all use it the same way. 💅
Status of This Memo
This is an Internet Standards Track document. 🔥
It's a product of the Internet Engineering Task Force (IETF), so it reflects IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6872. ✨
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🦋
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Problem Statement ...............................................4
4. What SIP CLF Is and What It Is Not ..............................5
5. Alternative Approaches to SIP CLF ...............................5
5.1. SIP CLF and Call Detail Records ............................6
5.2. SIP CLF and Packet Capture Tools ...........................6
5.3. SIP CLF and Syslog .........................................7
5.4. SIP CLF and IPFIX ..........................................8
6. Motivation and Use Cases ........................................8
7. Challenges in Establishing a SIP CLF ...........................10
8. Information Model ..............................................11
8.1. SIP CLF Mandatory Fields ..................................11
8.2. Mandatory Fields and SIP Entities .........................13
9. Examples .......................................................14
9.1. UAC Registration ..........................................15
9.2. Direct Call between Alice and Bob .........................17
9.3. Single Downstream Branch Call .............................20
9.4. Forked Call ...............................................25
10. Security Considerations .......................................35
11. Operational Guidance ..........................................37
12. Acknowledgments ...............................................37
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................381. Introduction 🍓
Servers running on Internet hosts write log records as a normal part of what they do. Some of these records are basically a summary of an application-layer protocol data unit (PDU), capturing exactly what event the server handled. They're used for lots of things, including analysis and troubleshooting. 💜
Apache and Squid are the famous examples. They log events using the Common Log Format (CLF), which is the shared structure for logging the requests and responses a web server handles. Honestly, a big part of Apache's success is its CLF, because third parties could build tools that analyzed the data and made traffic reports and trends. The Apache CLF got so popular that it became the de facto standard for web server logging data, and lots of commercial web servers can be set up to output this format too. Here's an example of the Apache CLF: 🧚
%h %l %u %t \"%r\" %s %b
remotehost rfc931 authuser [date] request status bytesHere's what each field means:
remotehost: Remote hostname (or IP number if DNS hostname is not available or if DNSLookup is Off.rfc931: The remote logname of the user.authuser: The username by which the user has authenticated himself.[date]: Date and time of the request.request: The request line exactly as it came from the client.status: The HTTP status code returned to the client.bytes: The content-length of the document transferred.
The SIP CLF is inspired by the Apache CLF, but the state machinery for an HTTP transaction is way simpler than for a SIP transaction (you'll see this in Section 7). So the SIP CLF has to do a lot more. 😭
This document covers the problem statement that makes the case for a SIP CLF. It also provides an information model for the minimum set of SIP headers and fields that must be logged. It does NOT lock in one specific representation format. Other documents can define that. [RFC6873] is an example of a representation format, one that provides a UTF-8-based logging scheme. 🌸
2. Terminology 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 3261 [RFC3261] defines extra SIP-specific terms this document uses, like "proxy", "registrar", "redirect server", "user agent server" or "UAS", "user agent client" or "UAC", "back-to-back user agent" or "B2BUA", "dialog", "transaction", and "server transaction". 💅
This document uses the term "SIP server" to cover these SIP entities: user agent server, registrar, redirect server, a SIP proxy acting as a user agent server, and a B2BUA acting as a user agent server. 🫶
3. Problem Statement 💖
The Session Initiation Protocol (SIP) [RFC3261] is an Internet multimedia session signaling protocol. In a typical enterprise deployment, SIP entities come from multiple vendors, and each one writes logs in its own proprietary format. Because of all those different log formats, support staff can't easily trace a call from one entity to another, and they can't build common tools for trend analysis, debugging, and troubleshooting across entities from different vendors. It's giving chaos. 😭
The log file also has to be easy to get at with command-line tools for simple text processing. That lets people run ad hoc queries against the elements in the log file to pull out a log record. The log file also has to be in a format that allows rapid searches for a particular record or records. Since the log file is expected to hold a huge number of records, the records need a format that allows fast scanning and makes it easy to skip records that don't match a search criterion. Last thing: generating the log file must not put undue burden on the SIP implementation, for example by requiring extra libraries that might not be available on every platform and operating environment where a SIP entity generating a log record might run. 🧚
SIP doesn't currently have a common log format. This document gives the rationale for establishing a SIP CLF and identifies the required minimal information that must appear in any SIP CLF record. 🎀
4. What SIP CLF Is and What It Is Not ✨
The SIP CLF is a standardized way of producing a log file. SIP clients, SIP servers, proxies, and B2BUAs can all use this format. It's basically an easy-to-digest log of events happening right now and transactions that already happened. It has enough info for humans and automated tools to work out how separate transactions handled at a SIP entity relate to each other, or to search for a particular dialog or a related set of transactions. 🌈
The SIP CLF is easy to parse quickly (that is, it has well-delimited fields), and it's neutral to platform and operating system. 💜
Because of the structure that delimited fields impose, the SIP CLF is easy to parse, which makes it a great base for other tools like logfile parsers and trend analytic engines. 🔥
The SIP CLF is NOT a billing tool. Enterprises aren't expected to bill customers based on the SIP CLF. It records events at the signaling layer only and doesn't try to correlate those events with the media layer, so it can't be used to trigger customer billing. 🙈
The SIP CLF is also NOT a quality of service (QoS) measurement tool. If QoS means measuring the mean opinion score (MOS) of received media, the SIP CLF doesn't help with that, because it doesn't summarize events at the media layer. 💀
Finally, the SIP CLF is NOT a tool for supporting lawful intercept. 👑
To be continued in Part 2, so stay tuned bestie! 🦋
5. Alternative Approaches to SIP CLF ✨
okay so the sipclf working group looked at four alternative approaches to see if they could hit the requirements we outlined in Section 3 🎀 ngl every single one has its perks, but the downsides might mean they can't be used as a SIP CLF 💅 that said, the information model in this document can totally be used to build other representation formats if you want one 🦋 right now, [RFC6873] is a good example. it's a UTF-8-based logging scheme that meets all the requirements of Section 3 🔥
5.1. SIP CLF and Call Detail Records
Call Detail Records (CDRs) are used all over operator networks, and once SIP showed up, standards bodies like the Third Generation Partnership Project (3GPP) defined SIP-related CDRs too 💜 today CDRs do the job that SIP CLF kind of approximates, but there are some important differences 👀
first, SIP CLF works natively at the transaction layer ✨ and it keeps enough info in the logged elements that you can derive dialog-related data from the transaction logs later. so esoteric SIP fields and parameters like the To header (including tags), the From header (including tags), the Command Sequence (CSeq) number, etc. all get logged in SIP CLF 🧚 a CDR, on the other hand, is mostly for charging, so it only saves what helps with that 💸 a CDR will most certainly log the public user identification of the party requesting a service (which may not match the From header) and the public user identification of the called party (which may not match the To header) 🙈 also, the sequence numbers a CDR keeps may not line up with the SIP CSeq header. so it's going to be hard to piece together the state of a dialog from a pile of CDR records 😭
second, a CDR will, in all probability, be generated at a SIP entity doing some kind of proxy-like job, or a B2BUA providing some service 🍓 SIP CLF is way more lightweight, though. it can be generated by a canonical SIP user agent server and user agent client too, even ones running on resource-constrained devices like mobile phones 📱
finally, SIP is also showing up outside of operator-managed Voice over IP (VoIP) networks 🌈 universities, research labs, and small-to-medium-sized companies are running SIP-based VoIP on networks they own and manage themselves. a lot of those folks won't care about generating CDRs, but they'll still want a concise representation of the messages handled by SIP entities, in a common format 🫶
5.2. SIP CLF and Packet Capture Tools
Wireshark and tcpdump are popular raw packet capture tools 🦈 Wireshark even has filters that understand SIP at the protocol level and can break a captured message down into its individual header components 🤓 packet capture tools are great for capturing and viewing discrete SIP messages, but they don't cut it as a SIP CLF for these reasons:
- using packet capture tools won't get rid of the need to agree on a common set of fields for a SIP CLF record 📋 that shared understanding is what makes interoperability work, so one implementation can read a log file written by a different implementation 💖
- the packet capture output isn't easy to search with simple command-line text processing tools 😵💫
- packet capture tools need their underlying libraries to be available on every platform where a SIP server or SIP client runs 🖥️ with mobile, fixed hosts, tablets, and so on, that can become a real blocker. compare that with the SIP client or server producing a SIP CLF record natively 💅 it has already parsed the SIP message to operate on it, so it makes total sense for it to write the parsed tokens out to persistent storage in an agreed-upon format ✨
- if SIP messages are exchanged over a secure transport (TLS), packet capture tools won't be able to decrypt them and render them as individual SIP headers 🔐💀
- using these tools and their packet capture libraries may impose a dependency on a third-party library 📦
5.3. SIP CLF and Syslog
The syslog protocol [RFC5424] carries event notification messages from an originator to a collector 📨 it provides a packet format and a transport mechanism, but it doesn't describe any storage format for syslog messages 🙃 in practice, though, the collector ends up writing the arriving messages into a disk file 💾 and here's the new problem: because syslog is so general, that disk file holds log messages from many originators, not just SIP entities 😩 so when you analyze it for SIP CLF records of interest, you have to throw out all the extraneous records 🗑️ SIP CLF records are best stored in a log file that's easy to search with command-line tools 🔍
syslog has other drawbacks too 🥲 the collector might be unavailable in certain scenarios (a mobile SIP phone may be unable to find a collector to send messages to), and you'd need syslog-specific libraries on every platform where a SIP server or SIP client runs. and finally, because of how often and how big SIP log messages are, sending every SIP CLF log message to the collector isn't really desirable 🙅♀️ a smarter move is to only send certain events, the ones that matter for network situational awareness, or ones carrying a periodic statistical summary of the messages processed 📊
5.4. SIP CLF and IPFIX
The IP Flow Information Export (IPFIX) protocol [RFC5101] lets network admins group IP packets that share something in common (similar packet header fields, or one or more characteristics of the packet itself) into a flow 🌊 those flows can then be collected and sent to other elements for analysis and monitoring 📈 but IPFIX isn't a logging format, and it doesn't produce a log file you can examine with ad hoc text processing tools 🙅♀️
6. Motivation and Use Cases 🌸
okay so SIP is everywhere now, in business and in academic and research settings alike 🌍 which is exactly why it's so worth having a CLF. here's why, bestie 👑
- Common reference for interpreting events: in a lab or an enterprise service offering, you'll usually have SIP entities from multiple vendors all routing requests together 🤝 without a common log format, each entity spits out records in its own native format, and now tools that work on the log file have no shared language 😤
- Writing common tools: a common log format lets independent tool providers build tools and apps that read CLF data and produce insightful trend analysis and detailed traffic reports 📊 the format should stay readable by humans and processable with traditional Unix text processing tools too 🐧
- Session correlation across diverse processing elements: in operational SIP networks, a request is usually handled by more than one SIP server 🔀 a SIP CLF lets the network operator trace the progress of a request (or a set of requests) as it moves through the different servers, which gives a concise diagnostic trail for a SIP session 🕵️♀️
Note that tracing a request through a set of servers is way less challenging when all of those servers belong to the same administrative domain 🫶
- Message correlation across transactions: a SIP CLF makes it quick to look up all the messages that make up a transaction (e.g., "Find all messages corresponding to server transaction X, including all forked branches.") 🔎
- Message correlation across dialogs: a SIP CLF can correlate the transactions that make up a dialog (e.g., "Find all messages for dialog created by Call-ID C, From tag F and To tag T.") 💞
- Trend analysis: a SIP CLF lets an admin collect data and spot patterns or trends in the information (e.g., "What is the domain where the most sessions are routed to between 9:00 AM and 1:00 PM?") 📈✨
- Train anomaly detection systems: a SIP CLF will let you train anomaly detection systems that, once trained, can monitor the CLF file and trigger an alarm on later deviations from accepted patterns in the data set 🚨 right now, anomaly detection systems monitor the network and parse the raw packets that make up a SIP message, and that process is unsuitable for anomaly detection systems [rieck2008] 😭 with all the necessary event data at their fingertips, network operations managers and information technology operations managers are in a much better spot to correlate, aggregate, and prioritize log data to keep situational awareness on point 🧠
- Testing: a SIP CLF allows automatic testing of SIP equipment, by writing tools that parse a SIP CLF file to check the behavior of a device under test 🧪
- Troubleshooting: a SIP CLF can enable cursory troubleshooting of a SIP entity (e.g., "How long did it take to generate a final response for the INVITE associated with Call-ID X?") 🔧
- Offline analysis: a SIP CLF allows offline analysis of the gathered data 💻 once a SIP CLF file has been generated, it can be transported (subject to the security considerations in Section 10) to a host with appropriate computing resources for further analysis 🚚
- Real-time monitoring: a SIP CLF lets administrators visually notice the events happening at a SIP entity in real time, which gives them accurate situational awareness 👀💖
7. Challenges in Establishing a SIP CLF ✨
okay so making a SIP CLF is genuinely hard, bestie 😭 SIP entities are way more complicated than their HTTP equivalents, so it's not just copy-paste 💅
Base protocol stuff like parallel or serial forking gives you multiple final responses for one request 🔥 Then the delays between sending a request and getting a final response add extra complexity when you're deciding which fields belong in a CLF and how to log them 🌀 And here's the big difference from HTTP: SIP groups multiple separate transactions into a dialog 🦋 Those transactions can arrive at a proxy at totally different rates. For example, the BYE transaction usually shows up long after the matching INVITE transaction was received, handled, and removed from the transaction list 💀 Even so, it's super valuable to link these transactions together so that automata, or a human reading the log file, can build a set of related transactions 🧩
ACK requests need careful thought too 🎀 In SIP, ACK is a special method that only goes with an INVITE 🎀 It doesn't get a response. If it's acknowledging a non-2xx response, the ACK counts as part of the original INVITE transaction. If it's acknowledging a 2xx-class response, the ACK is its own separate transaction made up of just a request (there's no response to an ACK request) 🙈 CANCEL is another method tied to an INVITE transaction, but unlike ACK, a CANCEL request does get a final response 💜
Most requests get a response right away, but an INVITE can just sit there in a pending state. A proxy might be forking branches downstream, or a user agent server might be alerting the user 🔔 [RFC3261] tells the server transaction to send a 1xx-class provisional response if the final response is delayed for more than 200 ms ⏱️ A SIP CLF log file needs to include those provisional responses because they help train the automata behind anomaly detection systems, and they give a human watching the log some positive feedback too 🥹✨
Last but not least, besides native SIP actors like proxies, registrars, redirect servers, and user agent servers (UASs), it's super useful to come up with a common log format that also supports B2BUA behavior 🌈 That behavior can vary a lot depending on what kind of B2BUA you're dealing with, so it's a whole vibe 💅
8. Information Model 🧠
This document defines the mandatory fields that MUST occur in a SIP CLF record 💖 The maximum size for a SIP CLF field is 4096 bytes (counted in bytes). This limit is the same whether the SIP CLF field is a meta-field (see "Timestamp" and "Directionality" defined below) or a normal SIP header 🎀 If the body of the SIP message is going to be logged, it MUST conform to this limit too 🫶
SIP bodies can contain characters that don't form a valid UTF-8 sequence 🙃 So logging bodies takes some thinking about trade-offs for a specific logging format, to figure out whether the body can be logged as is or whether it needs some encoding 🧐 The specific syntax and semantics used to log SIP bodies MUST be defined by the specific representation format document that's used to generate the SIP CLF record 📜
The information model is extensible, because it lets you log "optional fields" ✨ Optional fields are SIP header fields (or field components) that aren't mandatory (see Section 8.1 for the mandatory field list) 🌸 They can hold SIP headers or other elements from a SIP message. For example, they can hold the Reason-Phrase element from the Status-Line production rule in RFC 3261 [RFC3261] 💅 Optional fields can also hold extra info that a particular vendor wants to log 🍓 The specific syntax and semantics for optional fields MUST be defined by the specific representation format used to generate the SIP CLF record 🔥
8.1. SIP CLF Mandatory Fields 📋
These are the SIP CLF fields that are defined as the minimal info that MUST appear in any SIP CLF record 💖
Timestamp: The date and time of the request or response, written as the number of seconds and milliseconds since the Unix epoch ⏰Message type: Tells you whether the SIP message is a request or a response. The allowable values are 'R' (for Request) and 'r' (for response) 🎀Directionality: Tells you whether the SIP message was received by the SIP entity or sent by it. The allowable values are 's' (for message sent) and 'r' (for message received) 🦋Transport: The transport the SIP message is sent or received over. The allowable values are governed by the "transport" production rule in Section 25.1 of RFC 3261 [RFC3261] 🚀Source-address: The IPv4 or IPv6 address of the sender of the SIP message 🌐Source-port: The source port number of the sender of the SIP message 🔌Destination-address: The IPv4 or IPv6 address of the recipient of the SIP message 🎯Destination-port: The port number of the recipient of the SIP message 🔌From: The From URI. For the sake of brevity, URI parameters should not be logged ✂️From tag: The tag parameter of the From header 🏷️To: The To URI. For the sake of brevity, URI parameters should not be logged ✂️To tag: The tag parameter of the To header. Note that the tag parameter will be absent in the initial request that forms a dialog 🙈Callid: The Call-ID 📞CSeq-Method: The method from the CSeq header 🧾CSeq-Number: The number from the CSeq header 🔢R-URI: The Request-URI, including any URI parameters 🗺️Status: The SIP response status code 🚦
SIP proxies may fork, which creates several client transactions that correlate to a single server transaction 🌀 Responses arriving on these client transactions, or new requests (CANCEL, ACK) sent on the client transaction, need log file entries that correlate with a server transaction 🔗 Similarly, a B2BUA may create one or more client transactions in response to an incoming request, and those transactions will need correlating too 💜 The last two information model elements take care of that correlation 🫶
Server-Txn: The server transaction identification code, meaning the transaction identifier associated with the server transaction. Implementations can reuse the server transaction identifier (the topmost branch-id of the incoming request, with or without the magic cookie), or they can generate a unique identification string for a server transaction (this identifier only needs to be locally unique to the server) 🧠 This identifier is used to correlate ACKs and CANCELs to an INVITE transaction, and it also helps with forking as explained later in this section. (See Section 9 for usage.) 🎀Client-Txn: The client transaction identification code. This field is used to associate client transactions with a server transaction for forking proxies or B2BUAs 🍓 When forking happens, implementations can reuse the value they inserted into the topmost Via header's branch parameter, or they can generate a unique identification string for the client transaction. (See Section 9 for usage.) 🌈
This information model applies to all SIP entities: a UAC, UAS, proxy, B2BUA, registrar, and redirect server 🌸 The SIP CLF fields prescribed for a proxy are equally applicable to the B2BUA. Likewise, the SIP CLF fields prescribed for a UAS are equally applicable to registrars and redirect servers 💅
The next section specifies the individual SIP CLF information model elements that form a log record for specific instances of a SIP entity 🦋 It's understood that a SIP CLF record is extensible using extension mechanisms that fit the specific representation used to generate it 🧩 This document, though, doesn't prescribe a specific representation format, and it only covers the mandatory data elements described above 🫶
8.2. Mandatory Fields and SIP Entities 🧑🤝🧑
Each SIP CLF record must contain all the mandatory information model elements outlined in Section 8.1 😤 This document doesn't specify a logging format. It's expected that other documents will do that 📚
Sometimes an element doesn't have an appropriate value for one of these fields. For example, the R-URI field doesn't apply when you're logging a response, the Status field doesn't apply when you're logging a request, and the To tag isn't known when a request is first sent out, etc. 🤷♀️ Since all the mandatory fields are required to appear in the SIP CLF record, the representation document MUST define how to indicate a field that isn't applicable in the context where the SIP CLF record was generated 🚩 Similarly, to handle parsing errors in a field, the representation document MUST define a means to indicate that a field can't be parsed 🙅♀️
The Client-Txn field is always applicable to a UAC. The Server-Txn field doesn't apply to a UAC unless the element is also acting as a UAS, and the message tied to this log record corresponds to a message handled by that UAS 🔄 For instance, a proxy forwarding a request will fill in both the Client-Txn and Server-Txn fields in the record for that forwarded request 🫶
The Server-Txn field is always applicable to a UAS. The Client-Txn field doesn't apply to a UAS unless the element is also acting as a UAC, and the message tied to this log record corresponds to a message handled by that UAC 🔁 For instance, a proxy forwarding a response will fill in both the Server-Txn and Client-Txn fields in the record for that forwarded response 💫 However, a proxy would only fill in the Client-Txn field when it's creating a log record for a request 🌟
9. Examples 🎀
The examples only use the mandatory data elements defined in Section 8.1 🧸 Extension elements aren't considered, and neither are SIP bodies 🙅♀️ When a given mandatory field doesn't apply to a SIP entity, we use the horizontal dash (-) to represent it ➖
There are five principals in the examples. First up is Alice, the initiator of requests 👩 Alice's user agent uses IPv4 address 198.51.100.1, port 5060. P1 is a proxy that Alice's requests traverse on their way to Bob, the recipient of the requests 🛣️ P1 also acts as a registrar for Alice. P1 uses IPv4 address 198.51.100.10, port 5060. Bob has two instances of his user agent running on different hosts 👯 The first instance uses IPv4 address 203.0.113.1, port 5060, and the second instance uses IPv6 address 2001:db8::9, port 5060. P2 is a proxy responsible for Bob's domain 🏰 Table 1 summarizes these addresses 🧁
+-------------------+--------------------+-------------------+
| Principal | IP:port | Host/Domain name |
+-------------------+--------------------+-------------------+
| Alice | 198.51.100.1:5060 | alice.example.com |
| P1 | 198.51.100.10:5060 | p1.example.com |
| P2 | 203.0.113.200:5060 | p2.example.net |
| Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net |
| Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net |
+-------------------+--------------------+-------------------+
Principal to IP Address Assignment
Table 1Illustrative examples of SIP CLF follow 🦋✨
9.1. UAC Registration ✨
okay so bestie, Alice sends a registration request to registrar P1 and gets back a 2xx-class response 💖. That REGISTER request makes Alice's UAC write a log record that looks like this:
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: sip:example.com
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:example.com
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: -
Server-Txn: -
Client-Txn: c-tr-1After some time, Alice's UAC gets a response from the registrar 🦋. That response makes her agent write another record:
Timestamp: 1275930744.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 1
CSeq-Method: REGISTER
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:example.com
To tag: reg-1-xtr
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f81-d4-f6@example.com
Status: 100
Server-Txn: -
Client-Txn: c-tr-19.2. Direct Call between Alice and Bob 📞
in this one, Alice sends a session initiation request straight to Bob's agent (instance 1), and Bob's agent accepts the invite 🎀. we start with the SIP CLF logging from Alice's UAC point of view. on line 1, Alice's user agent sends out the INVITE. shortly after, it gets a "180 Ringing" (line 2), followed by a "200 OK" (line 3). once she gets the 2xx-class response, Alice's user agent sends out an ACK request (line 4) 🔥
Timestamp: 1275930743.699
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@bob1.example.net
To tag: -
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930745.002
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 180
Server-Txn: -
Client-Txn: c-1-xt6 Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 32
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: 200
Server-Txn: -
Client-Txn: c-1-xt6
Timestamp: 1275930746.120
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 32
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b-in6-iu
From: sip:alice@example.com
From tag: 76yhh
Call-ID: f82-d4-f7@example.com
Status: -
Server-Txn: -
Client-Txn: c-1-xt69.3. Single Downstream Branch Call 🧚
in this example, Alice sends a session invitation to Bob through proxy P1, which adds a Record-Route header. that means later requests between Alice and Bob keep going through the proxy 💅 the SIP CLF log records show up from P1's point of view. the line numbers below point to Figure 1.
Alice P1 Bob
+---INV--------->| | Line 1
| | |
|<---------100---+ | Line 2
| | |
| +---INV-------->| Line 3
| | |
| |<--------100---+ Line 4
| | |
| |<--------180---+ Line 5
| | |
|<---------180---+ | Line 6
| | |
| |<--------200---+ Line 7
| | |
|<---------200---+ | Line 8
| | |
+---ACK--------->| | Line 9
| | |
| |---ACK-------->| Line 10
Figure 1: Simple Proxy-Aided Call Flow 1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: -okay so notice that, at this point, P1 has created a server transaction identification code and put it in the SIP CLF field Server-Txn 🫶 P1 hasn't created a client transaction identification code yet, so Client-Txn just has a "-".
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: -in line 3 below, P1 has created a client transaction identification code for the downstream branch and filled in the SIP CLF field Client-Txn 🌈
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
4 Timestamp: 1275930745.200
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 100
Server-Txn: s-x-tr
Client-Txn: c-x-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
6 Timestamp: 1275930746.009
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 180
Server-Txn: s-x-tr
Client-Txn: c-x-tr
7 Timestamp: 1275930747.120
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
8 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: 200
Server-Txn: s-x-tr
Client-Txn: c-x-tr
9 Timestamp: 1275930749.100
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@example.net
Destination-address: 198.51.100.10
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr
10 Timestamp: 1275930749.100
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 198.51.100.10
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: al-1
Call-ID: tr-87h@example.com
Status: -
Server-Txn: s-x-tr
Client-Txn: c-x-tr9.4. Forked Call 🌸
okay bestie, so in this one Alice sends a session invite to Bob's proxy, P2 👑. P2 forks that invite out to two registered endpoints for Bob's address-of-record, and both endpoints reply with provisional responses 🦋. Then one of Bob's user agent instances picks up the call, so P2 sends a CANCEL to the second user agent 💅. P2 does not Record-Route, which means the ACK from Alice to Bob's user agent never goes through P2, so it's not shown below 🙈.
Figure 2 shows the call flow 🎀
Bob Bob
Alice P2 (Instance 1) (Instance 2)
+---INV--->| | | Line 1
| | | |
|<---100---+ | | Line 2
| | | |
| +---INV--->| | Line 3
| | | |
| +---INV----+-------->| Line 4
| | | |
| |<---100---+ | Line 5
| | | |
| |<---------+---100---+ Line 6
| | | |
| |<---180---+---------+ Line 7
| | | |
|<---180---+ | | Line 8
| | | |
| |<---180---+ | Line 9
| | | |
|<---180---+ | | Line 10
| | | |
| |<---200---+ | Line 11
| | | |
|<---200---+ | | Line 12
| | | |
| +---CANCEL-+-------->| Line 13
| | | |
| |<---------+---487---+ Line 14
| | | |
| +---ACK----+-------->| Line 15
| | | |
| |<---------+---200---+ Line 16Figure 2: Forked Call Flow
The SIP CLF log is written from P2's point of view ✨ The fields logged are shown below, and the line numbers match up with Figure 2 🧚
1 Timestamp: 1275930743.699
Message Type: R
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@example.net
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 198.51.100.1
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: -
2 Timestamp: 1275930744.001
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: -
3 Timestamp: 1275930744.998
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob1.example.net
Destination-address: 203.0.113.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-1-tr
4 Timestamp: 1275930745.500
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: -
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
5 Timestamp: 1275930745.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1=-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-1-tr
6 Timestamp: 1275930746.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 100
Server-Txn: s-1-tr
Client-Txn: c-2-tr
7 Timestamp: 1275930746.700
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
8 Timestamp: 1275930746.990
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
9 Timestamp: 1275930747.100
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-1-tr
10 Timestamp: 1275930747.300
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 180
Server-Txn: s-1-tr
Client-Txn: c-2-tr
11 Timestamp: 1275930747.800
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: 5060
Source-address: 203.0.113.1
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com 100
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
12 Timestamp: 1275930748.000
Message Type: r
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 198.51.100.1
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b1-1
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-1-tr
13 Timestamp: 1275930748.201
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
14 Timestamp: 1275930748.300
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: INVITE
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 487
Server-Txn: s-1-tr
Client-Txn: c-2-tr
15 Timestamp: 1275930748.355
Message Type: R
Directionality: s
Transport: udp
CSeq-Number: 43
CSeq-Method: ACK
R-URI: sip:bob@bob2.example.net
Destination-address: [2001:db8::9]
Destination-port: 5060
Source-address: 203.0.113.200
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: -
Server-Txn: s-1-tr
Client-Txn: c-2-tr
16 Timestamp: 1275930748.698
Message Type: r
Directionality: r
Transport: udp
CSeq-Number: 43
CSeq-Method: CANCEL
R-URI: -
Destination-address: 203.0.113.200
Destination-port: udp
Source-address: [2001:db8::9]
Source-port: 5060
To: sip:bob@example.net
To tag: b2-2
From: sip:alice@example.com
From tag: a1-1
Call-ID: tr-88h@example.com
Status: 200
Server-Txn: s-1-tr
Client-Txn: c-2-trThe log above makes it super easy to search for a specific transaction or a state of the session 🔍 Searching for the string c-1-tr in the log records tells you that an INVITE was sent to sip:bob@bob1.example.com, and it got a 100, then a 180, then a 200 🎉. Since the ACK in this case gets exchanged end-to-end, this element doesn't see it, so it won't log it 🙈
Searching for c-2-tr gives a messier story 😭. An INVITE went to sip:bob@bob2.example.net and got a 100 and a 180. But the log shows that the request was CANCELed before any final response was generated, and the pending INVITE came back with a 487. The ACK to that final non-2xx response, plus a 200 to the CANCEL, wrap things up on that branch 💜
10. Security Considerations 🔐
okay bestie, security is where things get a little dramatic 💀 A log file, by its very nature, reveals both the state of the entity that made it and whatever info got logged. So if that state shouldn't be public and the info is private, appropriate file and directory permissions attached to the log file SHOULD be used 🔒. Protecting the log file while it sits on disk is outside the scope of this doc, but there are still some precautions you can take ✨. Operators SHOULD consider using common admin features like disk encryption and securing log files [schneier-1] 💅. Operators SHOULD also consider hardening the machine where the log file lives, which means restricting physical access to the host as well as restricting access to the file itself 🏰. Depending on the OS and environment, the file and directory permissions SHOULD be set to be most restrictive, so the file isn't publicly readable or writable and the directory it lives in isn't publicly accessible 🚫.
These threats may be considered for the log file while it's stored:
- An attacker may gain access to view the log file, or may surreptitiously make a copy of the log file for later viewing 👀.
- An attacker who can't eavesdrop on real-time SIP traffic on the network, but can still access the log file, can easily mount a replay attack or other attacks that come from channel eavesdropping 😱. Encrypting SIP traffic doesn't help here, because the SIP entity generating the log file would have decrypted the message for processing and then logged it 🙃.
- An attacker may delete parts of --- or indeed, the whole --- file 💀.
Public access to the SIP log file is a bigger privacy leak than an adversary eavesdropping on cleartext SIP traffic on the network 🫣. If all SIP traffic on a network segment is encrypted, then, as noted above, you have to pay special attention to the file and directory permissions for the log file, so that only a privileged user can access its contents 🗝️.
Transporting SIP CLF files across the network poses special challenges too 🚚. These threats may be considered for transferring log files, or while transferring individual log records:
- An attacker may view the records 👁️.
- An attacker may modify the records in transit or insert previously captured records into the stream 🥷.
- An attacker may remove records in transit, or may stage a man-in-the-middle attack to deliver a partially or entirely falsified log file 🎭.
Protection methods for log files or log records being transferred between hosts are also outside the scope of this doc, but there are still precautions you can take 🛡️. Operators SHOULD require mutual authentication, channel confidentiality, and channel integrity while transferring the log file 🤝. The secure shell transport layer protocol [RFC4253] or TLS [RFC5246] gets this done 🔐.
Even with all that care, sensitive info can still leak during or after the transfer 😭. SIP CLF fields like IP addresses and URIs can contain potentially sensitive information 🫣. Before transferring the log file across domains, operators SHOULD ensure that any fields containing sensitive information are appropriately anonymized or obfuscated 🙈. A spec for a format that describes which fields are obfuscated, and with what characteristics (for example, which correlations still work), is needed so that SIP CLF can be exchanged between administrative domains in a way that's both interoperable and privacy-friendly 🌸. This doc doesn't attempt that spec; it's left for further study 🔭.
The SIP CLF represents the minimum fields that lend themselves to trend analysis and serve as info that may be deemed useful 📊. Other formats can be defined that include more headers (and the body) from Section 8.1 🧩. But where to draw the judicial line on including non-mandatory headers can be tricky ⚖️. Clearly, the more info a SIP entity logs, the longer the logging process takes, the more disk space each log entry eats, and the more potentially sensitive info could get breached 📈. So you need adequate trade-offs when logging more fields than the ones recommended in Section 8.1 ⚖️.
Implementers need to pay special attention to buffer handling when reading or writing log files 🧠. SIP CLF entries can be unbounded in length 🌀. It would be reasonable for a full dump of a SIP message to be thousands of octets long 📜. This matters a lot for CLF log parsers, because SIP CLF log writers may add one or more extension fields to the message being logged 🧾.
11. Operational Guidance 🛠️
SIP CLF log files can eat a substantial amount of disk space, depending on the traffic volume at a processing entity and how much info is being logged 💾. So any organization using SIP CLF should set up operational procedures for file rollovers, and for periodic retrieval of logs before rollover, as fits their needs 🗂️.
Listing those operational guidelines in this doc is out of scope for this work 🙅♀️.
12. Acknowledgments 🫶
Members of the sipping, dispatch, ipfix, and syslog working groups gave invaluable input to the formulation of this doc 🌈. They include Benoit Claise, Spencer Dawkins, John Elwell, David Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, Dale Worley, Theo Zourzouvillys, and others the authors undoubtedly, but inadvertently, missed 💖.
Rainer Gerhards, David Harrington, Cullen Jennings, and Gonzalo Salgueiro helped tremendously in discussions about arriving at the beginnings of an information model 🧚.
13. References 📚
13.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 🔑.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002 📞.
13.2. Informative References
- [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006 🐚.
- [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008 🌊.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008 🔐.
- [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009 📝.
- [RFC6873] Salgueiro, G., Gurbani, V., and A. B. Roach, "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", RFC 6873, February 2013 🧾.
- [rieck2008] Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. Muller, "A Self-learning System for Detection of Anomalous SIP Messages", Principles, Systems and Applications of IP Telecommunications Services and Security for Next Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 2008 🤖.
- [schneier-1] Schneier, B. and J. Kelsey, "Secure audit logs to support computer forensics", ACM Transactions on Information and System Security (TISSEC), 2(2), pp. 159,176, May 1999 🕵️.
Authors' Addresses 🎀
Vijay K. Gurbani (editor)
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Naperville, IL 60566
USA
EMail: vkg@bell-labs.com
Eric W. Burger (editor)
Georgetown University
USA
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Tricha Anjali
Illinois Institute of Technology
316 Siegel Hall
Chicago, IL 60616
USA
EMail: tricha@ece.iit.edu
Humberto Abdelnur
INRIA
INRIA - Nancy Grant Est
Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex
France
EMail: humbol@gmail.com
Olivier Festor
INRIA
INRIA - Nancy Grant Est
Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex
France
EMail: Olivier.Festor@loria.fr📦 where this page comes from
- ietf: rfc6872 2013-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms