idnits 2.17.1 draft-ietf-ipfix-as-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1074), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1036. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2720' is mentioned on line 701, but not defined == Missing Reference: 'PSAMP-FM' is mentioned on line 744, but not defined == Missing Reference: 'PSAMP-PROTOCOL' is mentioned on line 745, but not defined == Missing Reference: 'RFC 3577' is mentioned on line 755, but not defined == Unused Reference: 'PSAMP-FW' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'RFC3577' is defined on line 963, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3917 -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-PROTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-INFO' == Outdated reference: A later version (-13) exists of draft-ietf-psamp-framework-08 -- Obsolete informational reference (is this intentional?): RFC 2598 (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Tanja Zseby 3 Document: Elisa Boschi 4 Expires: November 2005 Fraunhofer FOKUS 5 Nevil Brownlee 6 CAIDA 7 Benoit Claise 8 Cisco Systems 10 May 2005 12 IPFIX Applicability 13 draft-ietf-ipfix-as-05.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as "work 31 in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 44 This document describes what type of applications can use the IP 45 Flow Information Export (IPFIX) protocol and how they can use 46 the information provided by IPFIX. It also shows how the IPFIX 47 framework relates to other architectures and frameworks. 49 Table of Contents 50 1. Introduction.............................................3 51 2. Applications of IPFIX....................................4 52 2.1 Accounting...............................................4 53 2.1.1 Example.................................................5 54 2.2 Security Analysis and Intrusion Detection with IPFIX.....6 55 2.3 Network Planning.........................................8 56 2.4 Peering Agreements.......................................8 57 2.5 Traffic Engineering......................................8 58 2.6 Trend Analysis...........................................9 59 2.7 SLA Validation and QoS Measurements......................9 60 2.7.1 Measurement of Round-trip-time (RTT)...................10 61 2.7.2 Measurement of One-way-delay (OWD).....................10 62 2.7.3 Measurement of One-way-loss (OWL)......................11 63 2.7.4 Measurement of IP delay variation (IPDV)...............11 64 2.7.5 Transport of IPPM Metrics..............................11 65 2.7.6 Other Applications.....................................12 66 3. Relation of IPFIX to other frameworks and protocols.....12 67 3.1 IPFIX and AAA...........................................12 68 3.1.1 Connecting via an AAA Client...........................13 69 3.1.2 Connecting via an Application Specific Module (ASM)....14 70 3.2 IPFIX and RTFM..........................................15 71 3.2.1 Architecture...........................................15 72 3.2.2 Flow Definition........................................15 73 3.2.3 Configuration and Management...........................16 74 3.2.4 Data Collection........................................16 75 3.2.5 Data Model Details.....................................16 76 3.2.6 Application/Transport Protocol.........................17 77 3.2.7 RTFM Summary...........................................17 78 3.3 IPFIX and IPPM..........................................17 79 3.4 IPFIX and PSAMP.........................................17 80 3.5 IPFIX and RMON..........................................18 81 3.6 IPFIX and IDMEF.........................................18 82 4. Limitations.............................................19 83 4.1 IPFIX and IPv6..........................................20 84 5. Security Considerations.................................20 85 6. Normative References....................................21 86 7. Informative References..................................21 87 8. Acknowledgements........................................23 88 9. Author's Addresses......................................23 89 10. Full Copyright Statement................................24 90 11. Intellectual Property Statement.........................24 91 12. Copyright Statement.....................................25 92 13. Disclaimer..............................................25 94 1. Introduction 95 The IPFIX protocol defines how IP Flow information can be 96 exported from routers, measurement probes or other devices. It 97 is intended to provide this information as input to various 98 applications. IPFIX is a general data transport protocol, easily 99 extensible to suit the needs of different applications. This 100 document describes what applications can use the IPFIX protocol 101 and how they can use it. Furthermore, the relationship of IPFIX 102 to other frameworks and architectures is described. 104 2. Applications of IPFIX 106 IPFIX data enables several critical applications. This section 107 describes how different applications can use the IPFIX protocol. 109 2.1 Accounting 111 Usage-based accounting is one of the major applications for 112 which the IPFIX protocol has been developed. IPFIX data records 113 provide fine-grained measurement results for highly flexible and 114 detailed resource usage accounting. Internet Service Providers 115 (ISPs) can use this information to migrate from single fee, 116 flat-rate billing to more flexible charging mechanisms based on 117 time of day, bandwidth usage, application usage, quality of 118 service, etc. Enterprise customers can use this information for 119 departmental chargeback or cost allocation for resource usage. 121 In order to realize usage-based accounting with IPFIX the flow 122 definition has to be chosen in accordance with the tariff model. 123 IPFIX allows a very flexible flow definition that can be adapted 124 to the need of different tariff models. Arbitrary flow-based 125 accounting models can be realized without any extensions to the 126 IPFIX protocol. 128 A tariff can, for instance, be based on individual end-to-end 129 flows, in which case accounting can be realized with a flow 130 definition determined by the quintuple consisting of source 131 address, destination address, protocol and port numbers. Another 132 example is a class-dependent tariff (e.g. in a DiffServ 133 network). In this case, flows could be distinguished just by the 134 DiffServ codepoint (DSCP) and source IP address. 136 The essential elements needed for accounting are the number of 137 transferred packets and bytes per flow which are contained in 138 IPFIX flow records. 140 For accounting purposes, it would be advantageous to have the 141 ability to use IPFIX flow records as accounting input in an AAA 142 infrastructure. AAA servers then could provide the mapping 143 between user and flow information. 145 2.1.1 Example 147 Let's suppose someone has a Service Level Agreement (SLA) in a 148 DiffServ network requiring accounting based on traffic volume. 149 The information to export in this case is: 150 - The IPv4 source IP address: sourceIPv4Address in [IPFIX- 151 INFO] with a length of 4 octets 152 - The IPv4 destination IP address: destinationIPv4Address in 153 [IPFIX-INFO] with a length of 4 octets 154 - Type of Service: classOfServiceIPv4 in [IPFIX-INFO] with a 155 length of 1 octet 156 - The number of octets of the flow: inOctetDeltaCount in 157 [IPFIX-INFO] with a length of 4 octets 159 The template set (in case we use only IETF-specified Information 160 Elements) will look like: 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Set ID = 2 | Length = 24 octets | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Template ID 256 | Field Count = 4 | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |0| sourceIPv4Address = 8 | Field Length = 4 | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |0| destinationIPv4Address = 12 | Field Length = 4 | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |0| classOfServiceIPv4 = 5 | Field Length = 1 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |0| inOctetDeltaCount = 1 | Field Length = 4 | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 The information to be exported might be as listed in the 177 following example table: 179 Src. IP addr. | Dst. IP addr. | Type of service | Octets Number 180 --------------+---------------+-----------------+-------------- 181 198.18.1.12 | 198.18.2.254 | 101110xx | 987410 182 198.18.1.27 | 198.18.2.23 | 101110xx | 170205 183 198.18.1.56 | 198.18.2.65 | 101110xx | 33113 185 The field "Type of service" contains the DiffServ Codepoint in 186 the first six bits while the last two are currently unused. In 187 the example we use Codepoint 101110, recommended for the EF PHB 188 (Expedited Forwarding Per Hop Behavior)[RFC2598] 189 The Flow Records will then look like: 191 0 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Set ID = 256 | Length = 32 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | 198.18.1.12 | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | 198.18.2.254 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | 101110 00 | 8987410 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 198.18.1.27 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 198.18.2.23 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 101110 00 | 170205 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 198.18.1.56 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 198.18.2.65 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 101110 00 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | 33113 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 2.2 Security Analysis and Intrusion Detection with IPFIX 219 IPFIX provides information about the traffic in a network. 220 Therefore it is very well suited to take a key role in the 221 detection of network threats such as intrusions, propagation of 222 viruses and worms, port scanning and other network attacks. 224 Intrusion detection systems (IDS) monitor and control security 225 incidents. A typical IDS system includes several components 226 including sensors, event collectors, and management stations. 227 Sensors monitor network traffic for attacks and other security- 228 related events. Sensors respond to and notify the administrator 229 via the event collector about these events as they occur. Event 230 collectors are a middle-tier component responsible for 231 transmitting events from sensors to the console and database. 232 The management component serves the following purposes: 234 - visually monitors events (via a console) 235 - collects data from sensors (with one or more event collectors) 236 - stores data from sensors (in a database) 238 IPFIX can report events of interest to the sensor either by the 239 collecting process or directly by the exporting process. Which 240 approach is best depends on the scenario and the events of 241 interest. Getting information directly from the exporting 242 process has the advantage that the sensor gets the information 243 faster. It does not need to wait for collector processing time 244 or until the collecting process has all relevant data. Getting 245 the information from a collecting process enables correlation of 246 data from different exporting processes (e.g. from different 247 routers) to get a better picture of what is happening in the 248 network. 250 IPFIX provides useful input data for basic intrusion detection 251 functions such as reporting unusually high loads, number of 252 flows, number of packets of a specific type, etc. It can provide 253 details on source and destination addresses, along with the 254 start time of flows, TCP flags, application ports and flow 255 volume. This data can be used to analyze network security 256 incidents and identify attacks. Further data analysis and post- 257 processing functions may be needed to generate the metric of 258 interest for specific attack types. The integration of previous 259 measurement results helps to assess traffic changes over time 260 for detection of traffic anomalies. A combination with results 261 from other observation points allows assessing the propagation 262 of the attack and can help locate the source of an attack. 264 For some scenarios, intrusion detection may require further 265 insight into packet content. Since IPFIX allows a flexible 266 report definition, the metering process and the IPFIX report 267 format could be extended to support other data needed for 268 intrusion detection systems. Furthermore, it is possible to get 269 per packet information by using IPFIX to export PSAMP 270 information. 272 Detecting security incidents in real-time would require the pre- 273 processing of data already at the measurement device and 274 immediate data export in case a possible incident has been 275 identified. This means that IPFIX reports must be generated upon 276 incident detection events and not only upon flow end or fixed 277 time intervals. 278 Furthermore, security incidents can become a threat to IPFIX 279 processes themselves (see also security considerations in 280 [IPFIX-PROTO]. If an attack generates a large amount of flows 281 (e.g. by sending packets with spoofed addresses or simulating 282 flow termination) exporting and collecting process may get 283 overloaded by the immense amount of data records that are 284 exported. A flexible deployment of packet or flow sampling 285 methods can prevent the exhaustion of resources. 287 Intrusion detection can profit greatly from the combination of 288 IPFIX and AAA functions (see section 3.1). Such an 289 interoperation enables further means of attack detection, 290 advanced defense strategies and secure inter-domain cooperation. 292 2.3 Network Planning 294 IPFIX data records captured over a long period of time can be 295 used to track and anticipate network growth and plan upgrades to 296 increase the number of routing devices, ports, or higher- 297 bandwidth interfaces. Flow information as provided by IPFIX data 298 records optimizes both strategic network planning (peering, 299 backbone upgrade planning, routing policy planning), and 300 tactical network engineering decisions (upgrading the router or 301 link capacity). This helps to minimize the total cost of network 302 operations through effective capacity planning, while maximizing 303 network performance and reliability. 305 2.4 Peering Agreements 307 IPFIX provides a common data format for the reporting of 308 measurement results. Therefore it is very well suited to share 309 information with neighbor ISPs. If measurement tools in 310 different domains export the data in the same format and 311 collectors at different domains understand this format, IPFIX 312 data records could be directly forwarded to neighbor providers. 313 This can be done either by the IPFIX protocol itself or by 314 converting or encapsulating data records into commonly used 315 protocols for inter-domain data exchange like DIAMETER. 317 Some ISPs are still reluctant to share information due to 318 concerns that competing ISPs might exploit network information 319 from neighbor providers to strengthen their own position in the 320 market. Nevertheless, technical needs have already triggered the 321 exchange of data in the past (e.g. exchange of routing 322 information by BGP). The need to provide inter-domain guarantees 323 is one big incentive to increase inter-domain cooperation. 324 Furthermore, the necessity to defend networks against current 325 and future threats (denial of service attacks, worm 326 distributions, etc.) will further increase the willingness to 327 exchange measurement data between providers. 329 2.5 Traffic Engineering 330 IPIFX data provides traffic engineering details for a set of 331 prefixes. This data can be used in network optimization for load 332 balancing traffic across alternate paths, or for forwarding 333 traffic of a certain set of prefixes on a preferred route. 335 2.6 Trend Analysis 337 IPFIX data records are well suited to perform traffic profiling 338 for trend analysis and as a basis for business models. The 339 flexible flow definition allows different viewpoints on the 340 data. The observation of different traffic statistics (e.g. 341 number of flows, transmitted volume, etc.) over time provides 342 valuable input on the usage of existing services or the planning 343 of future services. 345 IPFIX data records (or information derived from them) can be 346 stored for later retrieval and analysis to support proactive 347 marketing and customer service programs. An example of this is 348 to determine which applications and services are being used by 349 internal and external users and then target them for improved 350 services such as advertising. This is especially useful for ISPs 351 because IPFIX data enables them to create better service 352 packaging. 354 2.7 SLA Validation and QoS Measurements 356 Performing QoS monitoring is one target application of the IPFIX 357 protocol. QoS monitoring is the passive observation of 358 transmission quality for single flows or traffic aggregates in 359 the network. One example of its usefulness is the validation of 360 QoS guarantees in service level agreements (SLAs). Some QoS 361 metrics require the correlation of data from multiple 362 measurement points. For this, the clocks of the involved 363 exporting devices must be synchronized. Furthermore, such 364 measurements would benefit from post-processing functions (e.g. 365 packet ID generation and mapping) at the exporter and/or 366 collector. 368 This section describes how the measurement of different metrics 369 can be performed with IPFIX. All of the metrics require at least 370 an extension of the IPFIX information model since the necessary 371 information such as round-trip-time, packet IDs, etc., is not 372 part of the current model. However given the extensibility and 373 flexibility of IPFIX the missing attributes can be easily 374 defined. The direct reporting of IPPM metrics with the IPIFX 375 protocol is addressed in section 3.3. 377 2.7.1 Measurement of Round-trip-time (RTT) 379 The passive measurement of round-trip-times (RTT) can be 380 performed by using packet pair matching techniques as described 381 in [Brow00]. For the measurements, request/response packet pairs 382 from protocols such as DNS, ICMP, SNMP or TCP (syn/syn-ack, 383 data/ack) are utilized to passively observe the RTT [Brow00]. As 384 always for passive measurements, this only works if the required 385 traffic of interest is actually present in the network. 386 Furthermore, if the observed protocol supports retransmissions 387 (e.g. TCP), the RTT is not the network RTT, but rather the RTT 388 of the network and the protocol stack of the receiver. In case 389 the reply packet is lost or can not be observed, the RTT can not 390 be calculated. 392 In order to use this measurement technique, the IPFIX metering 393 process needs to measure packets from both directions. A 394 classification of the protocols mentioned above has to be done. 395 This means that parts of the transport header are used for the 396 classification. Since a differentiation of flows based on 397 information in the transport header is one of the requirements 398 for IPFIX, such classification can be performed without 399 extensions to the protocol. Nevertheless, the metering process 400 also needs to recognize request and response packets for the 401 given protocols and therefore needs to look further into the 402 packets. The capability to do this analysis is not part of the 403 IPFIX requirements but can be achieved by optional extensions to 404 the classification process. The exporting device needs to assign 405 a timestamp for the arrival of the packets. The calculation of 406 the RTT can be done directly at the exporter or at the 407 collector. In the first case, IPFIX would transfer the 408 calculated RTT to the collector. In the second case, IPFIX needs 409 to send the observed packet types and the timestamps to the 410 collector. The round-trip-time-delay metric is defined in 411 [RFC2681]. 413 2.7.2 Measurement of One-way-delay (OWD) 415 Passive one-way-delay measurements require the collection of 416 data at two measurement points. It is necessary to recognize 417 packets at the second measurement point to correlate packet 418 arrival events from both points. This can be done by capturing 419 packet header and parts of the packet that can be used to 420 recognize the same packet at the subsequent measurement point. 421 To reduce the amount of measurement data, a unique packet ID can 422 be calculated from the header and all, or part of the content 423 e.g. by using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. 424 The capability of using parts of the payload is out of scope of 425 IPFIX but can be achieved by an optional extension. 426 Nevertheless, in some scenarios it might even be sufficient to 427 calculate a packet ID based on header fields (including datagram 428 ID and maybe sequence numbers from transport protocols) without 429 looking at parts of the payload. If packet IDs need to be unique 430 only for a certain time interval, or a certain amount of packet 431 ID collisions is tolerable, this is a sufficient solution. The 432 second issue is the export of packet IDs. IPFIX exports per-flow 433 information. The export of packet IDs is possible by introducing 434 a new information element (packet ID). 435 In order to provide a more efficient data export, one can export 436 the packet information with a flow ID in the data records. The 437 flow ID then can be associated with flow properties in a data 438 record. In this way the flow information only needs to be 439 transferred once. The packet information relates to much smaller 440 flow IDs, without the need to transfer all of the flow 441 information for each packet [PoMB05]. 442 The one way delay metric is defined in [RFC2679]. The export of 443 whole packets, or parts of packets is addressed by the PSAMP 444 working group [PSAMP]. PSAMP uses IPFIX as its export protocol. 446 2.7.3 Measurement of One-way-loss (OWL) 448 Passive loss measurements for single flows can be performed at 449 one measurement point by using sequence numbers that are present 450 in protocols (e.g. IP identification, TCP sequence numbers) 451 similar to the approach described in section 2.7.1. This 452 requires the capturing of the sequence numbers of subsequent 453 packets in the observed flow by the IPFIX metering process. 455 An alternative to this is to perform a two-point measurement as 456 described in section 2.7.2, and to consider packets as lost that 457 do not arrive at the second measurement point in a given time 458 frame. This approach assumes that a packet observed at the first 459 point should be also observed at the second observation point 460 (e.g. measurement should be done close to end-points or border 461 routers). The one-way loss metric is defined in [RFC2680]. 463 2.7.4 Measurement of IP delay variation (IPDV) 465 IP delay variation is defined as the difference of one-way-delay 466 values for selected packets [RFC3393]. Therefore, this metric 467 can be calculated by performing passive measurement of one-way- 468 delay for subsequent packets (e.g. of a flow) and then 469 calculating the differences. 471 2.7.5 Transport of IPPM Metrics 472 The IPFIX protocol can be used to transport not only input for 473 the calculation of IPPM metrics, but also for transporting the 474 metrics themselves. For this, additional information elements 475 need to be defined. 477 2.7.6 Other Applications 479 IPFIX is a quite generic and powerful protocol. It provides a 480 generic export mechanism that might be useful also for many 481 further applications. Apart from sending raw flow information it 482 also can be used to send further aggregated or post-processed 483 data. For this new templates and information elements can be 484 defined if needed. 485 Due to the push mode operation it is also suited to send network 486 initiated events like alarms and other notifications. It also 487 could be used for exchanging information among network nodes to 488 autonomously improve network operation. 489 Nevertheless, IPFIX was designed with respect to the 490 requirements documented in [RFC3917]. Therefore the capabilities 491 of IPFIX have to be carefully checked against requirements of 492 new applications before using it for other purposes than 493 addressed in [RFC3917]. 495 3. Relation of IPFIX to other frameworks and protocols 497 3.1 IPFIX and AAA 499 AAA defines a protocol and architecture for authentication, 500 authorization and accounting for service usage [RFC2903]. The 501 DIAMETER protocol [RFC3588] is used for AAA communication, which 502 is needed for network access services (Mobile IP, NASREQ, and 503 ROAMOPS). The AAA architecture [RFC2903] provides a framework 504 for extending AAA support to other services. DIAMETER defines 505 the exchange of messages between AAA entities, e.g. between AAA 506 clients at access devices and AAA servers, and among AAA 507 servers. It is also used for the transfer of accounting records. 508 Usage-based accounting requires measurement data from the 509 network. IPFIX defines a protocol to export such data from 510 routers, measurement probes and other devices. 512 Accounting functions can be realized without an AAA 513 infrastructure as shown in section 2.1. Accounting applications 514 can directly incorporate an IPFIX collecting process to receive 515 IPFIX data records with information about the transmitted 516 volume. 518 Nevertheless, if an AAA infrastructure is in place, the 519 cooperation between IPFIX and AAA provides many valuable 520 synergistic benefits. 521 IPFIX data records can provide the input for AAA accounting 522 functions and provide the basis for the generation of DIAMETER 523 accounting records. Further potential features include the 524 mapping of a user ID to flow information (by using 525 authentication information) or facilitating the secure 526 authorized exchange of DIAMETER accounting records with neighbor 527 domains. The last feature is especially useful in roaming 528 scenarios where the user connects to a foreign network and the 529 home provider generates the invoice. 531 Coupling an IPFIX collecting process with AAA functions also has 532 high potential for intrusion and attack detection. AAA controls 533 network access and maintains data about users and nodes. AAA 534 functions can help identify the source of malicious traffic. 535 They are able to deny access to suspicious users or nodes. 536 Therefore coupling those functions with an IPFIX collecting 537 process can provide an efficient defense against network 538 attacks. Furthermore, sharing IPFIX data records (either 539 directly or encapsulated in DIAMETER) with neighbor providers 540 allows an efficient inter-domain attack detection. The AAA 541 infrastructure can also be used to configure measurement 542 functions in the network as proposed in [RFC3334]. 544 Two possibilities exist to connect IPFIX and AAA: 546 - Connecting via an AAA Client 547 - Connecting via an Application Specific Module (ASM) 549 Both are explained in the following sections. 551 3.1.1 Connecting via an AAA Client 553 One possibility of connecting IPFIX and AAA is to run an AAA 554 client on the IPFIX collector. This client can generate DIAMETER 555 accounting messages and send them to an AAA server. The mapping 556 of the flow information to a user ID can be done in the AAA 557 server by using data from the authentication process. DIAMETER 558 accounting messages can be sent to the accounting application or 559 to other AAA servers (e.g. in roaming scenarios). 561 +---------+ DIAMETER +---------+ 562 | AAA-S |------------->| AAA-S | 563 +---------+ +---------+ 564 ^ 565 | DIAMETER 566 | 567 | 568 +--+--------+--+ 569 | | AAA-C | | 570 + +--------+ | 571 | | 572 | Collector | 573 +--------------+ 574 ^ 575 | IPFIX 576 | 577 +------------+ 578 | Exporter | 579 +------------+ 581 Figure 2: IPFIX collector connects to AAA server via AAA client 583 3.1.2 Connecting via an Application Specific Module (ASM) 585 Another possibility is to directly connect the IPFIX collector 586 with the AAA server via an application specific module (ASM). 587 Application specific modules have been proposed by the IRTF AAA 588 architecture research group (AAARCH) in [RFC2903]. They act as 589 an interface between AAA server and service equipment. In this 590 case the IPFIX collector is part of the ASM. The ASM acts as an 591 interface between the IPFIX protocol and the input interface of 592 the AAA server. The ASM translates the received IPFIX data into 593 an appropriate format for the AAA server. The AAA server then 594 can add information about the user ID and generate a DIAMETER 595 accounting record. This accounting record can be sent to an 596 accounting application or to other AAA servers. 598 +---------+ DIAMETER +---------+ 599 | AAA-S |------------->| AAA-S | 600 +---------+ +---------+ 601 ^ 602 | 603 +------------------+ 604 | ASM | 605 | +------------+ | 606 | | Collector | | 607 +------------------+ 608 ^ 609 | IPFIX 610 | 611 +------------+ 612 | Exporter | 613 +------------+ 615 Figure 3: IPFIX connects to AAA server via ASM 617 3.2 IPFIX and RTFM 619 The Real-time Traffic Flow Measurement (RTFM) working group 620 defined an architecture for flow measurement [RFC2722]. This 621 section compares the Real-time Traffic Flow Measurement (RTFM) 622 framework with the IPFIX framework. 624 3.2.1 Architecture 626 The RTFM consists of meter, meter reader and a manager that 627 communicate via SNMP. The manager configures the meter, and the 628 meter reader collects data from the meter. 629 The IPFIX architecture [IPFIX-ARCH] defines metering, exporting 630 and collecting processes. 631 The RTFM architecture is very similar to the IPFIX architecture. 632 One could see the metering process as part of the meter and the 633 collecting process as part of the meter reader. IPFIX speaks 634 about processes instead of devices to clarify that multiple of 635 those processes be collocated on the same machine. Nevertheless, 636 IPFIX currently does not define a managing process, because 637 remote configuration is, at this time, out of scope for the 638 working group. 640 3.2.2 Flow Definition 642 RTFM and IPFIX both use the same definition of flow; a flow is a 643 set of packets which share a common set of end-point address 644 attribute values. A flow is therefore completely specified by 645 that set of values, together with an inactivity timeout. A flow 646 is considered to have ended when no packets are seen for at 647 least the inactivity time. 649 RTFM flows, however, are bidirectional, i.e. an RTFM meter 650 matches packets from B to A and A to B as separate parts of a 651 single flow, and maintains two sets of packet and byte counters, 652 one for each direction. IPFIX flows are unidirectional. Users 653 that require bidirectional flows have to match the two 654 directions in post-processing. 656 3.2.3 Configuration and Management 658 In RTFM, remote configuration (using an SNMP MIB) is the only 659 way to configure a meter. IPFIX metering processes can be 660 configured locally by a system administrator. The IPFIX group 661 currently does not address IPFIX remote configuration. 662 IPFIX metering processes export their configuration, i.e. the 663 layout of data within their templates, from time to time. 664 IPFIX collecting processes use that template information to 665 determine how they should interpret the IPFIX flow data they 666 receive. 668 3.2.4 Data Collection 670 One major difference between IPFIX and RTFM is that RTFM uses a 671 pull model whereas IPFIX uses a push model for the data 672 collection. An IPFIX exporting process is configured to export 673 data records to a specified list of IPFIX collecting processes. 674 The data records are pushed to the colleting process. The 675 condition when to send data records (e.g. flow termination) can 676 be configured in the exporting or metering process. 678 In contrast to this, an RTFM meter reader pulls data from a 679 meter by using SNMP. SNMP security on the meter determines 680 whether a reader is allowed to pull data from it. 682 3.2.5 Data Model Details 684 RTFM defines all its attributes in the RTFM Meter MIB [RFC 685 2720]. IPFIX information elements are defined in [IPFIX-INFO]. 687 RTFM uses continuously-incrementing 64-bit counters for the 688 storage of the number of packets of a flow. The counters are 689 never reset and just wrap back to zero if the maximum value is 690 exceeded. Flows can be read at any time. The difference between 691 counter readings gives the counts for activity in the interval 692 between readings. 693 IPFIX allows absolute (totalCounter) and relative counters 694 (deltaCounter) [IPFIX-INFO]. The totalCounter are never reset 695 and just wrap to zero if values are too large, exactly as the 696 counters used in RTFM. The deltaCounter are reset to zero when 697 the associated flow record is exported. 699 3.2.6 Application/Transport Protocol 701 RTFM has a standards-track Meter MIB [RFC 2720], which is used 702 both to configure a meter and to store metering results. The 703 MIB provides a way to read lists of attributes with a single 704 Object Identifier (called a 'package'), which dramatically 705 reduces the SNMP overhead for flow data collection. SNMP, of 706 course, normally uses UDP as its transport protocol. Since RTFM 707 requires a reliable flow data transport system, an RTFM meter 708 reader must time out and resend unanswered SNMP requests. Apart 709 from being clumsy, this can limit the maximum data transfer rate 710 from meter to meter reader. 712 IPFIX is designed to work over a variety of different transport 713 protocols. SCTP and SCTP-PR (partially reliable) are mandatory. 714 UDP and TCP are optional. In addition, the IPFIX protocol 715 encodes data much more efficiently than does SNMP, hence IPFIX 716 will have lower data transport overhead than RTFM. 718 3.2.7 RTFM Summary 720 IPFIX provides a simple, powerful protocol for exporting flow 721 data from a metering process. RTFM provides bi-directional 722 flows and explicitly addresses dynamic configuration with a very 723 flexible flow definition. It may continue to be more suitable 724 in research situations where those features are needed. 725 A major difference between both frameworks is that RTFM works in 726 a pull mode for data collection, while IPFIX uses a push mode 727 for data export. 729 3.3 IPFIX and IPPM 731 The IPFIX protocol can be used to carry IPPM network performance 732 metrics or information that can be used to calculate those 733 metrics (see section 2.7). 735 3.4 IPFIX and PSAMP 736 The PSAMP group defines packet selection methods and the 737 reporting of whole packet or partial packet information. It also 738 defines the configuration of packet selection methods. The major 739 difference between IPFIX and PSAMP is that while the former 740 addresses the export of flow records, the latter addresses the 741 export's packet records. 742 The PSAMP group has decided to use IPIFX as its export protocol 743 for packet information. The Working Group describes a set of 744 requirements in [PSAMP-FM] that directly affect the export 745 protocol. In [PSAMP-PROTOCOL] the requirements have been 746 analyzed with respect to IPFIX. The conclusion was that IPFIX is 747 a general enough export protocol to be suitable for PSAMP 748 export. If needed, the information model can be easily extended. 749 PSAMP defines a PSAMP MIB for the configuration of packet 750 selection processes. One could consider extending this MIB to 751 allow configuration of IPFIX processes. 753 3.5 IPFIX and RMON 755 RMON [RFC 3577] is a widely used monitoring system that gathers 756 traffic data from RMON Agents in network devices using SNMP. The 757 RMON MIB is divided into sections, each section providing 758 different monitoring functions. For example, the 'Hosts' 759 section gathers statistics for hosts which are active on the 760 network and being monitored. 762 RMON does not cover flow measurement at all. To do so, one would 763 need to extend RMON by adding a MIB module to handle flows. 764 Further, one would need to devise a scheme for exporting high 765 volumes of flow data. In short, IPFIX is designed to provide 766 effective flow export; RMON is not. 768 3.6 IPFIX and IDMEF 770 The Intrusion Detection Message Exchange Format (IDMEF) [CuDF05] 771 is a standard data format developed within the IDWG Working 772 Group to exchange data alerts between automated Intrusion 773 Detection Systems (IDS). IDMEF provides a standard 774 representation of the alert information that an intrusion 775 detection analyzer reports when a suspicious event is detected. 776 These alerts may be simple or complex depending on analyzers' 777 capabilities, commercial vendor objectives, and intrusion 778 detection environments. IDMEF messages are implemented in XML 779 and composed by a basic schema and extension modules to define 780 alerts that are more complex. Once the kind of alert that should 781 be sent has been determined by the analyzer, it must be 782 formatted following the IDMEF rules. Generally, alerts are sent 783 when analyzers detect an event that they have been configured to 784 look for. The IPFIX protocol can be used to provide input for 785 intrusion detection systems, but also complementarily to IDMEF 786 by providing detailed information on intrusions traffic, suspect 787 events or anomalous traffic that differs from normal network 788 behavior. 790 4. Limitations 792 The goal of this section is to give recommendations where not to 793 use IPFIX. While the protocol is general enough to be adequate 794 for exporting data records for many applications, it still has 795 limitations. 797 Use of SCTP: 798 SCTP is the preferred protocol for IPFIX, i.e. a conforming 799 implementation must work over SCTP. Although IPFIX can also work 800 over TCP or UDP, users should make sure they have good reasons 801 for using protocols other than SCTP. 803 Push mode: 804 IPFIX works in push mode. That means data records are 805 automatically exported without waiting for a request. 806 The responsibility for initiating a data export is at the 807 exporting process. Exporting criteria are part of the 808 configuration of the exporting process. 810 Traffic characteristics are quite dynamic. Therefore the amount 811 of data (e.g. data records) that has to be exported can vary 812 over time. Push mode has more benefits if the trigger for data 813 export is related to events at the exporting process (e.g. flow 814 termination, memory shortage due to large amount of flows, 815 etc.). If the protocol used pull mode, the exporting process 816 would need to wait for a request to send the data. With push 817 mode it can send data immediately e.g. before memory shortage 818 would require a discarding of data. 820 Pull mode has advantages if the trigger for data export is 821 related to events at the collecting process (e.g. a specific 822 application requests immediate input). 824 In a pull mode, a request could simply be forwarded to the 825 exporting process. In a push mode, the exporting configuration 826 must be changed to trigger the export of the requested data. 827 Furthermore, with pull mode it can be prevented that the 828 collecting process is overloaded by the arrival of more data 829 records than it can process. 831 Whether this is a relevant drawback depends on the flexibility 832 of the IPFIX configuration and how IPFIX configuration rules are 833 implemented. 835 Template ID number: 836 The IPFIX specification limits the different template ID numbers 837 that can be assigned to the newly generated template records in 838 an Observation domain. In particular, template IDs up to 255 are 839 reserved for Template or option sets (or other sets to be 840 created) and template IDs from 256 to 65535 are assigned to data 841 sets. In the case of many exports requiring many different 842 templates, the set of Template IDs could be exhausted. 844 4.1 IPFIX and IPv6 846 There are two issues to consider: 848 - Generation and reporting of data records about IPv6 traffic 849 - Exporting data records over IPv6 851 The generation and reporting of data records about IPv6 traffic 852 is possible as appropriate information elements exist in [IPFIX- 853 INFO]. 855 Exporting data records over IPv6 is not explicitly addressed in 856 [IPFIX-PROTO]. Nevertheless, since IPFIX runs over SCTP, SCTP- 857 PR, UDP or TCP, it is trivial to run IPFIX over IPv6 networks, 858 provided that the transport protocol being used to carry IPFIX 859 is running on the IPv6 network. 861 5. Security Considerations 863 This document describes the usage of IPFIX in various scenarios. 864 Security requirements for IPFIX target applications and security 865 considerations for IPFIX are addressed in [RFC3917] and [IPFIX- 866 PROTO]. These requirements had to be considered for the 867 specification of the IPFIX protocol. The IPFIX extensions 868 proposed in this document do not induce further security 869 hazards. 871 Section 3 of this document describes how IPFIX can be used in 872 combination with other frameworks. New security hazards can 873 arise when two individually secure frameworks are combined. For 874 the combination of AAA with IPFIX an application specific module 875 (ASM) or an IPFIX collector can function as transit point for 876 the messages. It must be ensured that at this point the applied 877 security mechanisms (e.g. encryption of messages) are 878 maintained. 880 6. Normative References 882 [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, 883 Requirements for IP Flow Information Export, 884 October 2004 886 [IPFIX-PROTO] B. Claise (Editor), IPFIX Protocol Specification, 887 Internet Draft , 888 work in progress, May 2005 890 [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, Information Model 891 for IP Flow Information Export, Internet Draft 892 , work in progress, 893 February 2005 895 7. Informative References 897 [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, 898 Architecture for IP Flow Information Export, 899 Internet Draft , work in progress, March 2005 902 [Brow00] Nevil Brownlee, Packet Matching for NeTraMet 903 Distributions, 904 http://www2.auckland.ac.nz/net//Internet/rtfm/meeti 905 ngs/47-adelaide/pp-dist/ 907 [CuDF05] D.Curry, H. Debar, H. Feinstein, The Intrusion 908 Detection Message Exchange Format, work in 909 progress, Internet Draft , January 2005 912 [DuGr00] Nick Duffield, Matthias Grossglauser, Trajectory 913 Sampling for Direct Traffic Observation, 914 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 915 August 28 - September 1, 2000. 917 [GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin, 918 Jed Martens, John G. Cleary, Nonintrusive and 919 Accurate Measurement of Unidirectional Delay and 920 Delay Variation on the Internet, INET'98, Geneva, 921 Switzerland, 21-24 July, 1998 923 [PSAMP] http://www.ietf.org/html.charters/psamp- 924 charter.html 926 [PSAMP-FW] Nick Duffield (Ed.), A Framework for Packet 927 Selection and Reporting, Internet Draft draft-ietf- 928 psamp-framework-08, work in progress, January 2005 930 [PoMB05] G. Pohl, L. Mark, E. Boschi, Use of IPFIX for 931 Export of Per-Packet Information, Internet Draft 932 , work in progress, 933 February 2005 935 [RFC2598] V. Jacobson, K. Nichols, K. Poduri, An Expedited 936 Forwarding PHB, Request for Comments: 2598, June 937 1999 939 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, A One-way 940 Delay Metric for IPPM, Request for Comments: 2679, 941 September 1999 943 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, A One-way 944 Packet Loss Metric for IPPM, September 1999 946 [RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, A Round-trip 947 Delay Metric for IPPM, RFC 2681, September 1999 949 [RFC2722] Brownlee, N., Mills, C., and G. Ruth, Traffic Flow 950 Measurement: Architecture, RFC 2722, October 1999. 952 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. 953 Spence, Generic AAA Architecture, RFC 2903, August 954 2000 956 [RFC3334] T. Zseby, S. Zander, G. Carle, Policy-Based 957 Accounting, Request for Comments: 3334, October 958 2002 960 [RFC3393] C. Demichelis, P. Cimento, IP Packet Delay 961 Variation Metric for IPPM, RFC 3393, November 2002 963 [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, 964 D.Romascanu, Introduction to the Remote Monitoring 965 (RMON) Family of MIB Module, RFC 3577,August 2003 967 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. 968 Arkko, Diameter Base Protocol, Request for Comments 969 3588, September 2003 971 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle, 972 Evaluation of Building Blocks for Passive One-way- 973 delay Measurements, Proceedings of Passive and 974 Active Measurement Workshop (PAM 2001), Amsterdam, 975 The Netherlands, April 23-24, 2001 977 8. Acknowledgements 979 We would like to thank the following persons for their 980 contribution, discussion on the mailing list and valuable 981 comments: 983 Sebastian Zander 984 Robert Lowe 985 Reinaldo Penno 987 Part of the work has been developed in the research project 6QM 988 co-funded with support from the European Commission. 990 9. Author's Addresses 992 Tanja Zseby 993 Fraunhofer Institute for Open Communication Systems (FOKUS) 994 Kaiserin-Augusta-Allee 31 995 10589 Berlin, Germany 996 Phone: +49 30 3463 7153 997 Email: zseby@fokus.fhg.de 999 Elisa Boschi 1000 Fraunhofer Institute for Open Communication Systems (FOKUS) 1001 Kaiserin-Augusta-Allee 31 1002 10589 Berlin, Germany 1003 Phone: +49 30 3463 7366 1004 Email: boschi@fokus.fhg.de 1006 Nevil Brownlee 1007 CAIDA (UCSD/SDSC) 1008 9500 Gilman Drive 1009 La Jolla, CA 92093-0505 1010 Phone : +1 858 534 8338 1011 Email : nevil@caida.org 1013 Benoit Claise 1014 Cisco Systems 1015 De Kleetlaan 6a b1 1016 1831 Diegem 1017 Belgium 1018 Phone: +32 2 704 5622 1019 Email: bclaise@cisco.com 1021 10. Full Copyright Statement 1023 "Copyright (C) The Internet Society (2005). All Rights Reserved. 1024 This document and translations of it may be copied and furnished 1025 to others, and derivative works that comment on or otherwise 1026 explain it or assist in its implementation may be prepared, 1027 copied, published and distributed, in whole or in part, without 1028 restriction of any kind, provided that the above copyright 1029 notice and this paragraph are included on all such copies and 1030 derivative works. However, this document itself may not be 1031 modified in any way, such as by removing the copyright notice or 1032 references to the Internet Society or other Internet 1033 organizations, except as needed for the purpose of developing 1034 Internet standards in which case the procedures for copyrights 1035 defined in the Internet Standards process must be followed, or 1036 as required to translate it into. 1038 11. Intellectual Property Statement 1040 The IETF has been notified by Cisco of intellectual property 1041 rights claimed in regard to some or all of the specification 1042 contained in this document. For more information, see 1043 http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ipfix-as- 1044 02.txt 1046 The IETF takes no position regarding the validity or scope of 1047 any Intellectual Property Rights or other rights that might be 1048 claimed to pertain to the implementation or use of the 1049 technology described in this document or the extent to which any 1050 license under such rights might or might not be available; nor 1051 does it represent that it has made any independent effort to 1052 identify any such rights. Information on the procedures with 1053 respect to rights in RFC documents can be found in BCP 78 and 1054 BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the 1059 use of such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR 1061 repository at http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention 1064 any copyrights, patents or patent applications, or other 1065 proprietary rights that may cover technology that may be 1066 required to implement this standard. Please address the 1067 information to the IETF at ietf-ipr@ietf.org. 1069 12. Copyright Statement 1071 Copyright (C) The Internet Society (2005). This document is 1072 subject to the rights, licenses and restrictions contained in 1073 BCP 78, and except as set forth therein, the authors retain all 1074 their rights. 1076 13. Disclaimer 1078 This document and the information contained herein are provided 1079 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1080 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1081 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1082 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1083 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1084 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1085 FOR A PARTICULAR PURPOSE.