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