[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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

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

   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

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

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

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

   o  sipMediaType: the media type from a media stream description.

   o  sipMediaEncoding: the encoding name from a media stream

   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

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 <sipFrom, sipTo, sipCallId> 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

   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

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

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

   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 <commonPropertiesID | sipFrom, sipTo, sipCallId>.

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.

              Kobayashi, A. and B. Claise, "IPFIX Mediation: Problem
              April 2009.

              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.

              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

   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

   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

   Phone: +49 551 9969285
   Fax:   +49 551 37075678
   Email: sven@anderson.de

Huici, et al.           Expires December 24, 2009              [Page 17]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/