idnits 2.17.1 draft-huici-ipfix-sipfix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2009) is 5416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX F. Huici 3 Internet-Draft S. Niccolini 4 Intended status: Informational NEC Europe Ltd. 5 Expires: December 24, 2009 S. Anderson 6 Goettingen University 7 June 22, 2009 9 SIPFIX: Use Cases and Problem Statement for VoIP Monitoring and 10 Exporting 11 draft-huici-ipfix-sipfix-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 24, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The deployment of Voice-over-IP (VoIP) telephony is increasing fast. 50 VoIP's paradigm and the features it offers differ significantly from 51 that of regular telephony, and, as a result, its monitoring 52 requirements do so as well. This draft employs use cases to derive 53 these requirements and introduces SIPFIX, an extension to IPFIX (IP 54 Flow Information eXchange), that meets them. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Quality-of-Service Monitoring . . . . . . . . . . . . . . 4 61 2.2. Security and Troubleshooting . . . . . . . . . . . . . . . 4 62 2.3. Billing . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Law Enforcement . . . . . . . . . . . . . . . . . . . . . 6 64 3. Problem Statement and Requirements . . . . . . . . . . . . . . 7 65 4. Solution: SIPFIX . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Building Blocks . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. New Information Elements . . . . . . . . . . . . . . . . . 8 68 4.2.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.2. Media . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2.3. Performance Metrics . . . . . . . . . . . . . . . . . 9 71 4.3. Flow Type Definitions . . . . . . . . . . . . . . . . . . 10 72 4.4. Recommended IPFIX Extensions . . . . . . . . . . . . . . . 11 73 4.4.1. Bidirectional Flows . . . . . . . . . . . . . . . . . 11 74 4.4.2. Common Properties . . . . . . . . . . . . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 The deployment of Voice-over-IP (VoIP) telephony is increasing fast. 84 VoIP's paradigm and the features it offers differ significantly from 85 that of regular telephony, and, as a result, its monitoring 86 requirements do so as well. In addition to its wider set of 87 features, the fact that VoIP runs over an unreliable network makes 88 monitoring even more important if operators are to ensure good 89 quality of service and secure VoIP calls against attack. 91 Fulfilling these requirements, however, presents a number of 92 difficult challenges. The main goal of this draft is to introduce 93 SIPFIX, a set of extensions to IPFIX [RFC5101] aimed at meeting these 94 VoIP monitoring challenges, and in particular those of the two most 95 popular protocols currently in use for VoIP telephony: SIP and RTP. 96 In addition, the draft presents a number of use cases to illustrate 97 VoIP monitoring requirements and to show the need for a standard 98 solution such as SIPFIX. 100 2. Use Cases 102 This section introduces a number of VoIP monitoring use cases. The 103 aim is to show that important VoIP applications need monitoring as 104 well as a flexible mechanism such as SIPFIX to export monitored data. 105 Further, such mechanism should be standardized in order to provide a 106 better alternative to today's wide array of custom, non-interoperable 107 solutions. Finally, this section provides the background and 108 requirements needed to discuss the problem statement in the next 109 section. 111 2.1. Quality-of-Service Monitoring 113 Quality of service monitoring is an important issue for VoIP 114 providers and operators wishing to comply with service-level- 115 agreements, to monitor the performance of the infrastructure for 116 upgrade planning, or to generally provide a good call experience for 117 their users. VoIP quality of service includes measuring signalling 118 quality (e.g., session request delay, session completion ratio or 119 hops for request), media QoS (e.g., jitter, delay or bit rate) and 120 user experience (e.g., Mean Opinion Score). Calculating these 121 metrics requires dealing not only with a potentially large amount of 122 traffic in real-time, but also having to collect data from monitoring 123 probes distributed throughout the network and aggregate them in a 124 scalable way. In addition, the types of metric are quite varied, and 125 so require a flexible, general data export mechanism. 127 2.2. Security and Troubleshooting 129 Because VoIP runs over a significantly different network than regular 130 telephony, it is vulnerable to a host of different attacks. This 131 section's focus is on SIP and RTP, since these are the most popular 132 protocols currently in use for VoIP telephony. The following list, 133 which is by no means exhaustive, gives a good overview of the types 134 of attacks possible against VoIP traffic as well as the requirements 135 for a monitoring system aimed at mitigating them. 137 o Spoofed media sender: Most SIP devices currently do not take the 138 security of media streams into account. They expect packets to 139 arrive at a certain IP address and port but normally do not 140 inspect their origin, making it easy for an attacker to inject 141 media packets in order to take over or disturb the media stream. 142 A monitoring system could prevent these sort of attacks by 143 detecting that two different media flows matched the same media 144 flow descriptor of a SIP session. 146 o Stateful, cross-protocol IDS: Previous work on VoIP Intrusion 147 Detection Systems proposed analyzing the traffic across different 148 protocol levels and tracking their states [scidive]. In order to 149 do so, a monitoring system should be able to track the states of 150 SIP sessions and correlate them with information from other 151 protocols such as TCP. 153 o DoS attacks: Despite its popularity, many SIP implementations are 154 still in their infancy and vulnerable to malicious messages. 155 Cancel and Bye session attacks, as well as unregister attacks, 156 flooding and SIP parser attacks are certainly feasible, and so a 157 strong monitoring infrastructure is needed in order to detect and 158 filter them. Such a monitoring system should also be able to 159 detect DoS flooding attacks. Further, the system should be 160 distributed and its results aggregated in order to catch attackers 161 who try to avoid detection by sending small flooding rates to many 162 destinations. 164 o Spam-over-IP telephony (SPIT): SPIT has recently become a problem 165 and is likely to keep growing as VoIP adoption increases. A 166 monitoring system could keep track of repeat offenders and block 167 them from initiating further calls. 169 o Routing misconfigurations: Signalling packets may traverse a 170 number of routing hops when traveling from source to destination. 171 Routing misconfigurations can potentially lead to degraded 172 signalling quality or loss of signalling packets. To detect such 173 misconfigurations, monitoring could be use to sample signalling 174 packets in order to ensure that they are traversing the correct 175 paths. 177 2.3. Billing 179 Billing is an essential element in telephony. Calculating accurate 180 billing data for VoIP traffic presents new challenges when compared 181 to regular telephony. A naive approach would be to monitor SIP 182 INVITE and BYE messages, deriving a call's duration from these 183 packets. Unfortunately, because VoIP has separate signalling and 184 media streams, such a simplistic approach would be vulnerable to 185 billing fraud: an attacker could reduce his or her bill by sending a 186 BYE message while keeping the media session open. 188 To prevent this, the operator could distributedly monitor both 189 streams, exporting the data from them to a common point for 190 correlation. In this way, the operator would be able to detect 191 billing frauds by noticing media streams that are alive despite their 192 corresponding SIP session having finished. Because streams can 193 follow different paths through a network (and even different return 194 paths), such a system would have to ensure that no streams are 195 missed. In addition, tracking media streams in real-time would 196 stress the monitoring system, so care should be taken to ensure that 197 the infrastructure is scalable. 199 2.4. Law Enforcement 201 In order to comply with law enforcement agencies, operators are 202 required to not only monitor VoIP traffic, but also to record it for 203 after-the-fact auditing. Such a monitoring system should be flexible 204 enough to export only the relevant data to reduce storage costs. 206 3. Problem Statement and Requirements 208 The VoIP applications described in the previous section impose a set 209 of challenges and requirements on the monitoring infrastructure. 210 Because VoIP traffic may traverse various points in the network, 211 distributed monitoring is clearly a necessity. In addition, since 212 the type of VoIP application varies quite significantly, the 213 monitoring infrastructure needs application-specific, L7 monitoring 214 and exporting that is flexible enough to accommodate them. 216 Performing real-time distributed monitoring and exporting on a 217 potentially large amount of traffic presents obvious scalability 218 concerns. The naive approach of exporting data directly to a central 219 collector does not scale, and so intermediate nodes called mediators 220 are needed to pre-aggregate data before it reaches the collector. 221 Such a mediator would have to be flexible and configurable in order 222 to allow for the different types of VoIP applications that might use 223 the monitoring infrastructure. For instance, mediation may consist 224 of data reduction by aggregation or filtering, data correlation and 225 combination from different devices, data modification (e.g., 226 anonymization, encryption), or data storage. Another requirement for 227 a monitoring infrastructure is a flexible export mechanism so that 228 applications only export the data that they need, and no more. 230 While introducing intermediate mediators is a necessary step towards 231 achieving scalability, these additional hops mean that data takes 232 longer to arrive at the collector. Essentially this is a trade-off 233 between aggregation and delay, and different applications will have 234 different priorities. For instance, a billing application might care 235 more about aggregation and not be so concerned if data are not 236 reported every couple of seconds. As a result, in order to 237 accommodate the largest possible number of applications, the 238 monitoring infrastructure should allow per-application mediation and 239 export settings. 241 A further difficulty arises from the fact that VoIP traffic splits 242 signalling and media streams. As mentioned, several applications 243 need to correlate these separate streams which may traverse disjoint 244 paths through the network (indeed, due to path asymmetry, even a 245 single stream may traverse different paths). The challenge for a 246 monitoring infrastructure is then to ensure that both streams are 247 captured and that, when correlation is needed, that exported data 248 from them do not have to traverse a large number of hops before 249 arriving at a common mediator that can correlate them. 251 4. Solution: SIPFIX 253 This section describes SIPFIX, a SIP/media-focused extension to IPFIX 254 targeted at addressing some of the problems and requirements 255 discussed in the previous section. 257 4.1. Building Blocks 259 SIPFIX is based on IPFIX (IP Flow Information Export), which consists 260 of a protocol and an information model. IPFIX defines the transport 261 and storage of general IP flow information, while allowing for a 262 distributed, efficient and extensible monitoring architecture. In 263 IPFIX, the traffic observation is handled by IPFIX Devices which 264 obtain flow information from direct network observation and export 265 these data to one or more receivers as Flow Records. The final 266 receiver of the Flow Records is called a Collector, which is 267 responsible for centrally processing and storing the flow 268 information. IPFIX supports flexible flow definitions by using 269 Template Records describing the order, type and size of each field 270 for certain types of Flow Records. The type of a field is given by 271 Information Elements (IE), and besides having a base set of IEs, 272 IPFIX supports the definition of new ones. 274 In addition to IPFIX, SIPFIX also relies on so-called mediators. The 275 original architecture of IPFIX comprises IPFIX Devices including 276 Exporters that send out flow information, and Collectors that 277 directly receive it. Since clearly this architecture does not scale, 278 a draft [draft-mediators] has introduced the concept of a Mediator. 279 A Mediator receives Flow Records from IPFIX devices or other 280 Mediators and can process the data in a number of different ways, 281 such as data reduction by aggregation or filtering, data correlation 282 and combination from different devices, data modification 283 (anonymization for instance), and data storage in distributed 284 repositories. 286 4.2. New Information Elements 288 This section presents the SIPFIX Information Elements used to send 289 SIP and media-related information to Mediators and Collectors. IPFIX 290 supports new IEs either by defining enterprise-specific ones or by 291 registering new IEs at the IANA registry. The new IPFIX IEs 292 introduced here are either mandatory or optional, showcasing the 293 possible functionality and feature extensions. 295 4.2.1. SIP 297 The following IEs contain information gathered from the header of SIP 298 packets 299 Required fields 301 o sipFrom: the value of the From: header field. 303 o sipTo: the value of the To: header field. 305 o sipCallId: the value of the CallID: header field. 307 Optional fields 309 o sipRequestMethod: the method of a SIP request. 311 o sipRequestURI: the request-URI of a SIP request. 313 o sipResponseStatus: numerical status code of a SIP response. 315 4.2.2. Media 317 The IEs in this section describe specific properties of media streams 318 related to a SIP session. This information is either gathered from 319 media descriptors in the content of SIP packets (usually SDP), or 320 from directly monitoring media packets. 322 o sipMediaId: a unique identifier for a media stream description of 323 a SIP dialog. 325 o sipMediaProtocol: the transport protocol from a media stream 326 description. 328 o sipMediaType: the media type from a media stream description. 330 o sipMediaEncoding: the encoding name from a media stream 331 description. 333 o rtpPayloadType: the RTP payload type number. 335 4.2.3. Performance Metrics 337 Many metrics can be used in order to describe the characteristics of 338 signalling and media streams ([voip-perf],[draft-pmol]); this section 339 presents just a few possibilities. 341 o mediaPacketLoss: the ratio of lost packets to total packets. 343 o mediaDelay{To,From}Terminal: the one way delay from a media 344 gateway to the terminal and vice versa. 346 o mediaDelayMGW: the one way delay from the ingress media gateway to 347 the egress media gateway. 349 o rtpJitter: the inter-arrival jitter as defined by the RTP 350 specification. 352 4.3. Flow Type Definitions 354 In order to transmit the information about SIP sessions and their 355 related media streams, SIPFIX defines a set of special Flows. These 356 Flows are constructed to make sure that the data can be correctly 357 correlated by a Mediator or Collector. 359 +------------------------------+-------------------------------+ 360 | SIP Header | SIP Payload (SDP) | 361 +------------------------------+-------------------------------+ 362 | | | 363 | | | 364 v | v 365 +- - - - - - - - - - - - -+ | +- - - - - - - - - - - - - -+ 366 | SIP Flow | +---> | Media Flow Descriptor | 367 +- - - - - - - - - - - - -+ +- - - - - - - - - - - - - -+ 369 Figure 1: Dependencies of SIP and media flow descriptors 371 o SIP flow: A SIP Flow is a normal flow of SIP packets, but in 372 addition to the normal fields it must include fields with the 373 Information Elements which represent 374 the sipDialogId. SIP Flow fields may include any number of SIP 375 specific IEs such as those described in the previous section. 377 o Media Flow: A Media Flow is a normal flow of media packets. There 378 are no mandatory fields, as these flows may also be exported by 379 standard IPFIX devices unrelated to SIP monitoring. However, for 380 applications based on media-specific information like metrics for 381 performance and QoS monitoring, the media probe can gather this 382 information and export it in the Media Flow using media-specific 383 IEs. 385 o Media Flow Descriptor: SIP media stream sessions are defined by 386 media descriptions in the SIP packets' payloads. This data cannot 387 be exported as normal SIP Flows fields since there can be an 388 arbitrary number of media streams described in one single SIP 389 packet. To address this, SIPFIX defines a Media Flow Descriptor. 390 This descriptor is not a real flow based on measured packet 391 properties, but rather a pseudo flow that describes an expected 392 Media Flow based on media descriptions contained in SIP packets, 393 usually in the form of SDP information (see Figure 1). The Media 394 Flow Descriptor must include the sipDialogId IEs and the 395 sipMediaId in order to identify a SIP dialog and its corresponding 396 media stream, respectively. As it is not a measured flow, it does 397 not contain any kind of counter fields like number of packets or 398 bytes. 400 4.4. Recommended IPFIX Extensions 402 This section proposes the use of two existing IPFIX extensions that 403 optimize the export of the Flow Types described in the previous 404 section. Although not strictly necessary, they are highly 405 recommended as they improve the efficiency and functionality of 406 SIPFIX. 408 4.4.1. Bidirectional Flows 410 RFC 5103 [RFC5103] defines a method to export associated 411 bidirectional Flows (Biflows) in a single Flow Record. Two flows 412 combine to a Biflow if all non-directional fields directly match and 413 all source-related fields match the corresponding destination-related 414 field of the other flow. The flows are merged by adding special IEs 415 for counter fields of the "reverse" direction from the destination to 416 the source. 418 This approach has several advantages. First, in most cases it is 419 more efficient to assemble Biflows at the measuring device rather 420 than at a Collector. Further, Biflows share information, so 421 exporting them individually generates a large amount of redundant 422 data. Finally, the most important advantage for SIP monitoring is 423 that Biflows keep directional information which might otherwise be 424 lost: by using Biflows, the SIP flows of requests and responses can 425 be merged so that the normal counter fields refer to the SIP 426 requests, while reverse-counters refer to the SIP response packets. 428 4.4.2. Common Properties 430 Standard IPFIX may export several Flow Records with common properties 431 or values, leading to a large amount of redundant data being 432 transmitted. To improve this, RFC5473 [RFC5473] proposes a method to 433 reduce the used bandwidth of IPFIX exports arising from redundant 434 data. 436 SIPFIX can make extensive use of this method. For instance, the set 437 of IEs called sipDialogId described in Section 4.2.1 is often used as 438 an identifier throughout SIFPIX and is even mandatory for SIP Flows 439 and Media Flow Descriptors. As a result, it is advisable to define a 440 template . 442 5. Security Considerations 444 This document does not yet have any security considerations; these 445 will be added in future revisions. 447 6. IANA Considerations 449 This document has no actions for IANA. 451 7. Conclusions 453 The deployment of Voice-over-IP (VoIP) telephony is increasing fast. 454 VoIP's paradigm and the features it offers differ significantly from 455 that of regular telephony, and, as a result, its monitoring 456 requirements do so as well. This draft introduced SIPFIX, a set of 457 extensions to IPFIX aimed at meeting these VoIP monitoring 458 requirements and providing a standard exporting mechanism in order to 459 avoid the inter-operability problems generated by the wide array of 460 solutions available today. Further, the draft presented a number of 461 use cases to illustrate VoIP monitoring requirements and to show the 462 need for a standard solution such as SIPFIX. 464 8. References 466 [RFC5101] Claise, B., "Specification of the IP Flow Information 467 Export (IPFIX) Protocol for the Exchange of IP Traffic 468 Flow Information", RFC 5101, January 2008. 470 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 471 Using IP Flow Information Export (IPFIX)", RFC 5103, 472 January 2008. 474 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 475 in IP Flow Information Export (IPFIX) and Packet Sampling 476 (PSAMP) Reports", RFC 5473, March 2009. 478 [draft-mediators] 479 Kobayashi, A. and B. Claise, "IPFIX Mediation: Problem 480 Statement", 481 draft-ietf-ipfix-mediators-problem-statement-03, 482 April 2009. 484 [draft-pmol] 485 Morton, A., "SIP End-to-End Performance Metrics", 486 draft-ietf-pmol-sip-perf-metrics-03, March 2009. 488 [scidive] Wu, Y., Bagchi, S., Garg, S., Singh, N., and T. Tsai, 489 "Scidive: A stateful and cross protocol intrusion 490 detection architecture for voice-overip environments", In 491 DSN 2004: Proceedings of the 2004 International Conference 492 on Dependable Systems and Networks, 2004. 494 [voip-perf] 495 ITU-T, "Recommendation Y.1530: Call processing performance 496 for voice service in hybrid IP networks", 2004. 498 Authors' Addresses 500 Felipe Huici 501 NEC Laboratories Europe 502 Kurfuerstenanlage 36 503 Heidelberg 69115 504 Germany 506 Phone: +49 6221 4342 241 507 Fax: +49 6221 4342 155 508 Email: felipe.huici@nw.neclab.eu 509 URI: http://www.nw.neclab.eu/ 511 Saverio Niccolini 512 NEC Laboratories Europe 513 Kurfuerstenanlage 36 514 Heidelberg 69115 515 Germany 517 Phone: +49 6221 4342 118 518 Fax: +49 6221 4342 155 519 Email: saverio.niccolini@nw.neclab.eu 520 URI: http://www.nw.neclab.eu/ 522 Sven Anderson 523 Goettingen University 524 Nikolausberger Weg 31 525 Goettingen 37073 526 Germany 528 Phone: +49 551 9969285 529 Fax: +49 551 37075678 530 Email: sven@anderson.de