IPFIX F. Huici Internet-Draft S. Niccolini Intended status: Informational NEC Europe Ltd. Expires: December 24, 2009 S. Anderson Goettingen University June 22, 2009 SIPFIX: Use Cases and Problem Statement for VoIP Monitoring and Exporting draft-huici-ipfix-sipfix-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 24, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Huici, et al. Expires December 24, 2009 [Page 1] Internet-Draft SIPFIX June 2009 Abstract The deployment of Voice-over-IP (VoIP) telephony is increasing fast. VoIP's paradigm and the features it offers differ significantly from that of regular telephony, and, as a result, its monitoring requirements do so as well. This draft employs use cases to derive these requirements and introduces SIPFIX, an extension to IPFIX (IP Flow Information eXchange), that meets them. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Quality-of-Service Monitoring . . . . . . . . . . . . . . 4 2.2. Security and Troubleshooting . . . . . . . . . . . . . . . 4 2.3. Billing . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Law Enforcement . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement and Requirements . . . . . . . . . . . . . . 7 4. Solution: SIPFIX . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Building Blocks . . . . . . . . . . . . . . . . . . . . . 8 4.2. New Information Elements . . . . . . . . . . . . . . . . . 8 4.2.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Media . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Performance Metrics . . . . . . . . . . . . . . . . . 9 4.3. Flow Type Definitions . . . . . . . . . . . . . . . . . . 10 4.4. Recommended IPFIX Extensions . . . . . . . . . . . . . . . 11 4.4.1. Bidirectional Flows . . . . . . . . . . . . . . . . . 11 4.4.2. Common Properties . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Huici, et al. Expires December 24, 2009 [Page 2] Internet-Draft SIPFIX June 2009 1. Introduction The deployment of Voice-over-IP (VoIP) telephony is increasing fast. VoIP's paradigm and the features it offers differ significantly from that of regular telephony, and, as a result, its monitoring requirements do so as well. In addition to its wider set of features, the fact that VoIP runs over an unreliable network makes monitoring even more important if operators are to ensure good quality of service and secure VoIP calls against attack. Fulfilling these requirements, however, presents a number of difficult challenges. The main goal of this draft is to introduce SIPFIX, a set of extensions to IPFIX [RFC5101] aimed at meeting these VoIP monitoring challenges, and in particular those of the two most popular protocols currently in use for VoIP telephony: SIP and RTP. In addition, the draft presents a number of use cases to illustrate VoIP monitoring requirements and to show the need for a standard solution such as SIPFIX. Huici, et al. Expires December 24, 2009 [Page 3] Internet-Draft SIPFIX June 2009 2. Use Cases This section introduces a number of VoIP monitoring use cases. The aim is to show that important VoIP applications need monitoring as well as a flexible mechanism such as SIPFIX to export monitored data. Further, such mechanism should be standardized in order to provide a better alternative to today's wide array of custom, non-interoperable solutions. Finally, this section provides the background and requirements needed to discuss the problem statement in the next section. 2.1. Quality-of-Service Monitoring Quality of service monitoring is an important issue for VoIP providers and operators wishing to comply with service-level- agreements, to monitor the performance of the infrastructure for upgrade planning, or to generally provide a good call experience for their users. VoIP quality of service includes measuring signalling quality (e.g., session request delay, session completion ratio or hops for request), media QoS (e.g., jitter, delay or bit rate) and user experience (e.g., Mean Opinion Score). Calculating these metrics requires dealing not only with a potentially large amount of traffic in real-time, but also having to collect data from monitoring probes distributed throughout the network and aggregate them in a scalable way. In addition, the types of metric are quite varied, and so require a flexible, general data export mechanism. 2.2. Security and Troubleshooting Because VoIP runs over a significantly different network than regular telephony, it is vulnerable to a host of different attacks. This section's focus is on SIP and RTP, since these are the most popular protocols currently in use for VoIP telephony. The following list, which is by no means exhaustive, gives a good overview of the types of attacks possible against VoIP traffic as well as the requirements for a monitoring system aimed at mitigating them. o Spoofed media sender: Most SIP devices currently do not take the security of media streams into account. They expect packets to arrive at a certain IP address and port but normally do not inspect their origin, making it easy for an attacker to inject media packets in order to take over or disturb the media stream. A monitoring system could prevent these sort of attacks by detecting that two different media flows matched the same media flow descriptor of a SIP session. o Stateful, cross-protocol IDS: Previous work on VoIP Intrusion Detection Systems proposed analyzing the traffic across different Huici, et al. Expires December 24, 2009 [Page 4] Internet-Draft SIPFIX June 2009 protocol levels and tracking their states [scidive]. In order to do so, a monitoring system should be able to track the states of SIP sessions and correlate them with information from other protocols such as TCP. o DoS attacks: Despite its popularity, many SIP implementations are still in their infancy and vulnerable to malicious messages. Cancel and Bye session attacks, as well as unregister attacks, flooding and SIP parser attacks are certainly feasible, and so a strong monitoring infrastructure is needed in order to detect and filter them. Such a monitoring system should also be able to detect DoS flooding attacks. Further, the system should be distributed and its results aggregated in order to catch attackers who try to avoid detection by sending small flooding rates to many destinations. o Spam-over-IP telephony (SPIT): SPIT has recently become a problem and is likely to keep growing as VoIP adoption increases. A monitoring system could keep track of repeat offenders and block them from initiating further calls. o Routing misconfigurations: Signalling packets may traverse a number of routing hops when traveling from source to destination. Routing misconfigurations can potentially lead to degraded signalling quality or loss of signalling packets. To detect such misconfigurations, monitoring could be use to sample signalling packets in order to ensure that they are traversing the correct paths. 2.3. Billing Billing is an essential element in telephony. Calculating accurate billing data for VoIP traffic presents new challenges when compared to regular telephony. A naive approach would be to monitor SIP INVITE and BYE messages, deriving a call's duration from these packets. Unfortunately, because VoIP has separate signalling and media streams, such a simplistic approach would be vulnerable to billing fraud: an attacker could reduce his or her bill by sending a BYE message while keeping the media session open. To prevent this, the operator could distributedly monitor both streams, exporting the data from them to a common point for correlation. In this way, the operator would be able to detect billing frauds by noticing media streams that are alive despite their corresponding SIP session having finished. Because streams can follow different paths through a network (and even different return paths), such a system would have to ensure that no streams are missed. In addition, tracking media streams in real-time would Huici, et al. Expires December 24, 2009 [Page 5] Internet-Draft SIPFIX June 2009 stress the monitoring system, so care should be taken to ensure that the infrastructure is scalable. 2.4. Law Enforcement In order to comply with law enforcement agencies, operators are required to not only monitor VoIP traffic, but also to record it for after-the-fact auditing. Such a monitoring system should be flexible enough to export only the relevant data to reduce storage costs. Huici, et al. Expires December 24, 2009 [Page 6] Internet-Draft SIPFIX June 2009 3. Problem Statement and Requirements The VoIP applications described in the previous section impose a set of challenges and requirements on the monitoring infrastructure. Because VoIP traffic may traverse various points in the network, distributed monitoring is clearly a necessity. In addition, since the type of VoIP application varies quite significantly, the monitoring infrastructure needs application-specific, L7 monitoring and exporting that is flexible enough to accommodate them. Performing real-time distributed monitoring and exporting on a potentially large amount of traffic presents obvious scalability concerns. The naive approach of exporting data directly to a central collector does not scale, and so intermediate nodes called mediators are needed to pre-aggregate data before it reaches the collector. Such a mediator would have to be flexible and configurable in order to allow for the different types of VoIP applications that might use the monitoring infrastructure. For instance, mediation may consist of data reduction by aggregation or filtering, data correlation and combination from different devices, data modification (e.g., anonymization, encryption), or data storage. Another requirement for a monitoring infrastructure is a flexible export mechanism so that applications only export the data that they need, and no more. While introducing intermediate mediators is a necessary step towards achieving scalability, these additional hops mean that data takes longer to arrive at the collector. Essentially this is a trade-off between aggregation and delay, and different applications will have different priorities. For instance, a billing application might care more about aggregation and not be so concerned if data are not reported every couple of seconds. As a result, in order to accommodate the largest possible number of applications, the monitoring infrastructure should allow per-application mediation and export settings. A further difficulty arises from the fact that VoIP traffic splits signalling and media streams. As mentioned, several applications need to correlate these separate streams which may traverse disjoint paths through the network (indeed, due to path asymmetry, even a single stream may traverse different paths). The challenge for a monitoring infrastructure is then to ensure that both streams are captured and that, when correlation is needed, that exported data from them do not have to traverse a large number of hops before arriving at a common mediator that can correlate them. Huici, et al. Expires December 24, 2009 [Page 7] Internet-Draft SIPFIX June 2009 4. Solution: SIPFIX This section describes SIPFIX, a SIP/media-focused extension to IPFIX targeted at addressing some of the problems and requirements discussed in the previous section. 4.1. Building Blocks SIPFIX is based on IPFIX (IP Flow Information Export), which consists of a protocol and an information model. IPFIX defines the transport and storage of general IP flow information, while allowing for a distributed, efficient and extensible monitoring architecture. In IPFIX, the traffic observation is handled by IPFIX Devices which obtain flow information from direct network observation and export these data to one or more receivers as Flow Records. The final receiver of the Flow Records is called a Collector, which is responsible for centrally processing and storing the flow information. IPFIX supports flexible flow definitions by using Template Records describing the order, type and size of each field for certain types of Flow Records. The type of a field is given by Information Elements (IE), and besides having a base set of IEs, IPFIX supports the definition of new ones. In addition to IPFIX, SIPFIX also relies on so-called mediators. The original architecture of IPFIX comprises IPFIX Devices including Exporters that send out flow information, and Collectors that directly receive it. Since clearly this architecture does not scale, a draft [draft-mediators] has introduced the concept of a Mediator. A Mediator receives Flow Records from IPFIX devices or other Mediators and can process the data in a number of different ways, such as data reduction by aggregation or filtering, data correlation and combination from different devices, data modification (anonymization for instance), and data storage in distributed repositories. 4.2. New Information Elements This section presents the SIPFIX Information Elements used to send SIP and media-related information to Mediators and Collectors. IPFIX supports new IEs either by defining enterprise-specific ones or by registering new IEs at the IANA registry. The new IPFIX IEs introduced here are either mandatory or optional, showcasing the possible functionality and feature extensions. 4.2.1. SIP The following IEs contain information gathered from the header of SIP packets Huici, et al. Expires December 24, 2009 [Page 8] Internet-Draft SIPFIX June 2009 Required fields o sipFrom: the value of the From: header field. o sipTo: the value of the To: header field. o sipCallId: the value of the CallID: header field. Optional fields o sipRequestMethod: the method of a SIP request. o sipRequestURI: the request-URI of a SIP request. o sipResponseStatus: numerical status code of a SIP response. 4.2.2. Media The IEs in this section describe specific properties of media streams related to a SIP session. This information is either gathered from media descriptors in the content of SIP packets (usually SDP), or from directly monitoring media packets. o sipMediaId: a unique identifier for a media stream description of a SIP dialog. o sipMediaProtocol: the transport protocol from a media stream description. o sipMediaType: the media type from a media stream description. o sipMediaEncoding: the encoding name from a media stream description. o rtpPayloadType: the RTP payload type number. 4.2.3. Performance Metrics Many metrics can be used in order to describe the characteristics of signalling and media streams ([voip-perf],[draft-pmol]); this section presents just a few possibilities. o mediaPacketLoss: the ratio of lost packets to total packets. o mediaDelay{To,From}Terminal: the one way delay from a media gateway to the terminal and vice versa. Huici, et al. Expires December 24, 2009 [Page 9] Internet-Draft SIPFIX June 2009 o mediaDelayMGW: the one way delay from the ingress media gateway to the egress media gateway. o rtpJitter: the inter-arrival jitter as defined by the RTP specification. 4.3. Flow Type Definitions In order to transmit the information about SIP sessions and their related media streams, SIPFIX defines a set of special Flows. These Flows are constructed to make sure that the data can be correctly correlated by a Mediator or Collector. +------------------------------+-------------------------------+ | SIP Header | SIP Payload (SDP) | +------------------------------+-------------------------------+ | | | | | | v | v +- - - - - - - - - - - - -+ | +- - - - - - - - - - - - - -+ | SIP Flow | +---> | Media Flow Descriptor | +- - - - - - - - - - - - -+ +- - - - - - - - - - - - - -+ Figure 1: Dependencies of SIP and media flow descriptors o SIP flow: A SIP Flow is a normal flow of SIP packets, but in addition to the normal fields it must include fields with the Information Elements which represent the sipDialogId. SIP Flow fields may include any number of SIP specific IEs such as those described in the previous section. o Media Flow: A Media Flow is a normal flow of media packets. There are no mandatory fields, as these flows may also be exported by standard IPFIX devices unrelated to SIP monitoring. However, for applications based on media-specific information like metrics for performance and QoS monitoring, the media probe can gather this information and export it in the Media Flow using media-specific IEs. o Media Flow Descriptor: SIP media stream sessions are defined by media descriptions in the SIP packets' payloads. This data cannot be exported as normal SIP Flows fields since there can be an arbitrary number of media streams described in one single SIP Huici, et al. Expires December 24, 2009 [Page 10] Internet-Draft SIPFIX June 2009 packet. To address this, SIPFIX defines a Media Flow Descriptor. This descriptor is not a real flow based on measured packet properties, but rather a pseudo flow that describes an expected Media Flow based on media descriptions contained in SIP packets, usually in the form of SDP information (see Figure 1). The Media Flow Descriptor must include the sipDialogId IEs and the sipMediaId in order to identify a SIP dialog and its corresponding media stream, respectively. As it is not a measured flow, it does not contain any kind of counter fields like number of packets or bytes. 4.4. Recommended IPFIX Extensions This section proposes the use of two existing IPFIX extensions that optimize the export of the Flow Types described in the previous section. Although not strictly necessary, they are highly recommended as they improve the efficiency and functionality of SIPFIX. 4.4.1. Bidirectional Flows RFC 5103 [RFC5103] defines a method to export associated bidirectional Flows (Biflows) in a single Flow Record. Two flows combine to a Biflow if all non-directional fields directly match and all source-related fields match the corresponding destination-related field of the other flow. The flows are merged by adding special IEs for counter fields of the "reverse" direction from the destination to the source. This approach has several advantages. First, in most cases it is more efficient to assemble Biflows at the measuring device rather than at a Collector. Further, Biflows share information, so exporting them individually generates a large amount of redundant data. Finally, the most important advantage for SIP monitoring is that Biflows keep directional information which might otherwise be lost: by using Biflows, the SIP flows of requests and responses can be merged so that the normal counter fields refer to the SIP requests, while reverse-counters refer to the SIP response packets. 4.4.2. Common Properties Standard IPFIX may export several Flow Records with common properties or values, leading to a large amount of redundant data being transmitted. To improve this, RFC5473 [RFC5473] proposes a method to reduce the used bandwidth of IPFIX exports arising from redundant data. SIPFIX can make extensive use of this method. For instance, the set Huici, et al. Expires December 24, 2009 [Page 11] Internet-Draft SIPFIX June 2009 of IEs called sipDialogId described in Section 4.2.1 is often used as an identifier throughout SIFPIX and is even mandatory for SIP Flows and Media Flow Descriptors. As a result, it is advisable to define a template . Huici, et al. Expires December 24, 2009 [Page 12] Internet-Draft SIPFIX June 2009 5. Security Considerations This document does not yet have any security considerations; these will be added in future revisions. Huici, et al. Expires December 24, 2009 [Page 13] Internet-Draft SIPFIX June 2009 6. IANA Considerations This document has no actions for IANA. Huici, et al. Expires December 24, 2009 [Page 14] Internet-Draft SIPFIX June 2009 7. Conclusions The deployment of Voice-over-IP (VoIP) telephony is increasing fast. VoIP's paradigm and the features it offers differ significantly from that of regular telephony, and, as a result, its monitoring requirements do so as well. This draft introduced SIPFIX, a set of extensions to IPFIX aimed at meeting these VoIP monitoring requirements and providing a standard exporting mechanism in order to avoid the inter-operability problems generated by the wide array of solutions available today. Further, the draft presented a number of use cases to illustrate VoIP monitoring requirements and to show the need for a standard solution such as SIPFIX. Huici, et al. Expires December 24, 2009 [Page 15] Internet-Draft SIPFIX June 2009 8. References [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008. [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. [draft-mediators] Kobayashi, A. and B. Claise, "IPFIX Mediation: Problem Statement", draft-ietf-ipfix-mediators-problem-statement-03, April 2009. [draft-pmol] Morton, A., "SIP End-to-End Performance Metrics", draft-ietf-pmol-sip-perf-metrics-03, March 2009. [scidive] Wu, Y., Bagchi, S., Garg, S., Singh, N., and T. Tsai, "Scidive: A stateful and cross protocol intrusion detection architecture for voice-overip environments", In DSN 2004: Proceedings of the 2004 International Conference on Dependable Systems and Networks, 2004. [voip-perf] ITU-T, "Recommendation Y.1530: Call processing performance for voice service in hybrid IP networks", 2004. Huici, et al. Expires December 24, 2009 [Page 16] Internet-Draft SIPFIX June 2009 Authors' Addresses Felipe Huici NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 241 Fax: +49 6221 4342 155 Email: felipe.huici@nw.neclab.eu URI: http://www.nw.neclab.eu/ Saverio Niccolini NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 118 Fax: +49 6221 4342 155 Email: saverio.niccolini@nw.neclab.eu URI: http://www.nw.neclab.eu/ Sven Anderson Goettingen University Nikolausberger Weg 31 Goettingen 37073 Germany Phone: +49 551 9969285 Fax: +49 551 37075678 Email: sven@anderson.de Huici, et al. Expires December 24, 2009 [Page 17]