idnits 2.17.1
draft-leinen-ipfix-eval-contrib-03.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 3667, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1086.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1063.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1070.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1076.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1092), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 37.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** 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.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.)
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 607: '... MUST consist of the description and...'
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 (March 2004) is 7347 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)
== Outdated reference: A later version (-16) exists of
draft-ietf-ipfix-reqs-15
** Downref: Normative reference to an Informational draft:
draft-ietf-ipfix-reqs (ref. '1')
** Downref: Normative reference to an Informational draft:
draft-claise-netflow-9 (ref. '2')
** Obsolete normative reference: RFC 793 (ref. '3') (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960)
** Obsolete normative reference: RFC 2409 (ref. '6') (Obsoleted by RFC 4306)
-- Obsolete informational reference (is this intentional?): RFC 3588 (ref.
'9') (Obsoleted by RFC 6733)
== Outdated reference: A later version (-04) exists of
draft-claise-ipfix-eval-netflow-01
-- Obsolete informational reference (is this intentional?): RFC 2401 (ref.
'20') (Obsoleted by RFC 4301)
-- Obsolete informational reference (is this intentional?): RFC 2246 (ref.
'21') (Obsoleted by RFC 4346)
-- Obsolete informational reference (is this intentional?): RFC 1832 (ref.
'25') (Obsoleted by RFC 4506)
Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 IP Flow Information Export Working S. Leinen
2 Group SWITCH
3 Internet-Draft March 2004
4 Expires: August 30, 2004
6 Evaluation of Candidate Protocols for IP Flow Information Export
7 (IPFIX)
8 draft-leinen-ipfix-eval-contrib-03
10 Status of this Memo
12 By submitting this Internet-Draft, I certify that any applicable
13 patent or other IPR claims of which I am aware have been disclosed,
14 and any of which I become aware will be disclosed, in accordance with
15 RFC 3668.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
20 Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on August 30, 2004.
35 Copyright Notice
37 Copyright (C) The Internet Society (2004). All Rights Reserved.
39 Abstract
41 This document contains an evaluation of the five candidate protocols
42 for an IP Flow Information Export (IPFIX) protocol, based on the
43 requirements document produced by the IPFIX Working Group. The
44 protocols are characterized and grouped in broad categories, and
45 evaluated against specific requirements. Finally, a recommendation
46 is made to select the NetFlow v9 protocol as the basis for the IPFIX
47 specification.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
52 2. Protocol Summaries . . . . . . . . . . . . . . . . . . . . . 4
53 2.1 CRANE . . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 2.2 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . 5
55 2.3 LFAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
56 2.4 NetFlow v9 . . . . . . . . . . . . . . . . . . . . . . . . 6
57 2.5 Streaming IPDR . . . . . . . . . . . . . . . . . . . . . . 7
58 3. Broad Classification of Candidate Protocols . . . . . . . . 8
59 3.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . 8
60 3.2 Data Representation . . . . . . . . . . . . . . . . . . . 9
61 3.3 Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10
62 4. Item-Level Compliance Evaluation . . . . . . . . . . . . . . 12
63 4.1 Meter Reliability (5.1) . . . . . . . . . . . . . . . . . 12
64 4.2 Sampling (5.2) . . . . . . . . . . . . . . . . . . . . . . 12
65 4.3 Overload Behaviour (5.3) . . . . . . . . . . . . . . . . . 13
66 4.4 Timestamps (5.4) . . . . . . . . . . . . . . . . . . . . . 14
67 4.5 Time Synchronization (5.5) . . . . . . . . . . . . . . . . 14
68 4.6 Flow Expiration (5.6) . . . . . . . . . . . . . . . . . . 14
69 4.7 Ignore Port Copy (5.9) . . . . . . . . . . . . . . . . . . 14
70 4.8 Information Model (6.1) . . . . . . . . . . . . . . . . . 14
71 4.9 Data Model (6.2) . . . . . . . . . . . . . . . . . . . . . 14
72 4.10 Data Transfer (6.3) . . . . . . . . . . . . . . . . . . 15
73 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 20
74 5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 20
75 6. Security Considerations . . . . . . . . . . . . . . . . . . 22
76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
78 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
79 8.2 Informative References . . . . . . . . . . . . . . . . . . . 24
80 Author's Address . . . . . . . . . . . . . . . . . . . . . . 26
81 A. A Note on References to the Candidate Protocol Documents . . 27
82 Intellectual Property and Copyright Statements . . . . . . . 28
84 1. Introduction
86 The IP Flow Information Export (IPFIX) Working Group has been
87 chartered to select a protocol for the export of flow information
88 from traffic-observing devices (such as routers or dedicated probes).
89 To this end, an evaluation team was formed to evaluate submitted
90 protocols. Each protocol was represented by an advocate, who
91 submitted a specific evaluation draft for the respective protocol
92 against the requirements document [1]. The specification of each
93 protocol was itself available as one or several Internet-Drafts,
94 sometimes referring normatively to documents from outside the IETF.
96 This document contains an evaluation of the submitted protocols with
97 respect to the requirements document, and on a more general level, to
98 the working group charter.
100 The following IPFIX candidate protocol submissions were evaluated:
102 o CRANE [7], [8]
103 o Diameter [9], [10]
104 o LFAP [11], [12], [13]
105 o NetFlow v9 [2], [15], [16]
106 o Streaming IPDR [17], [18]
108 This document uses terminology defined in [1] intermixed with that
109 from submissions to explain the mapping between the two.
111 2. Protocol Summaries
113 In the following, each candidate protocol is described briefly,
114 highlighting its specific distinguishing features.
116 2.1 CRANE
118 XACCT's Common Reliable Accounting for Network Element Protocol
119 Version 1.0 [7][8] is described as a protocol for the transmission of
120 accounting information from "Network Elements" to "mediation" and
121 "business support systems".
123 2.1.1 CRANE Protocol Operation
125 The exporting side is the CRANE client, the collecting side the CRANE
126 server. Note that it is the server that is responsible for
127 initiating the connection to the client. A client can have multiple
128 simultaneous connections to different servers for robustness. Each
129 server has an associated priority. A client only exports to the
130 server with the highest priority that is perceived operational.
132 Clients and servers exchange messages over a reliable protocol such
133 as TCP [3] or (preferably) the Stream Control Transmission Protocol
134 (SCTP) [5]. The protocol uses application-layer acknowledgements as
135 an indication of successful processing by the server. Strong
136 authentication or data confidentiality aren't support by the
137 protocol, but can be supported by lower-layer mechanisms such as
138 IPsec [20] or TLS [21].
140 The protocol is bidirectional over the entire duration of a session.
141 There are 20 different message types. The protocol supports template
142 negotiation, not only at startup but also later on in a session, as
143 well as general status inquiries. There is a separate version
144 negotiation protocol defined over UDP.
146 2.1.2 CRANE Data Encoding
148 Data encoding is based on templates. Templates contain "keys"
149 representing items in data records. Clients (exporters) publish
150 templates to servers (collectors). Servers can then select the
151 subset of fields in a template that they are interested in. The
152 client will suppress keys that haven't been selected by the server.
154 Data records contain references to template and configuration
155 instances. They also carry sequence numbers (DSNs for Data Sequence
156 Numbers). These sequence numbers can be used to de-duplicate data
157 records that have been delivered multiple times during failover/
158 fail-back in redundant configurations. A "duplicate" bit is set in
159 these situations as a hint for the de-duplication process.
161 The encoding of (flow information) data records themselves is very
162 compact. The client (exporter) can choose to send data in big-endian
163 (network byte order) or little-endian format. There are eighteen
164 fixed-size key types, as well as five variable-length string and
165 binary data (BLOB) types.
167 2.2 Diameter
169 Diameter [9][10] is an evolution of the Remote Authentication Dial In
170 User Service (RADIUS) protocol [22]. RADIUS is widely used to
171 outsource authentication and authorization in dialup access
172 environments. Diameter is a generalized and extensible protocol
173 intended to support Authentication, Authorization and Accounting
174 (AAA) requirements of different applications. Dialup and Mobile IPv4
175 are examples of such applications defined in the IETF.
177 2.2.1 Diameter Protocol Operation
179 Diameter is a peer-to-peer protocol. The base protocol defines
180 fourteen command codes, organized as seven request/response command
181 pairs. Presumably, only a subset of these would be used in a pure
182 IPFIX application. Diameter includes capability negotiation and
183 error notifications. Diameter operates over TCP or (preferred) SCTP.
184 There is a framework for end-to-end security, the mechanisms for
185 which are defined in a separate document. IPsec or TLS can be used
186 to provide authentication or encryption at the underlying layers.
188 2.2.2 Diameter Data Encoding
190 Diameter conveys data in the form of attribute/value pairs (AVPs).
191 An AVP consists of eight bytes of header plus the space to store the
192 data, which depends on the data format. There are numerous
193 predefined AVP data formats, including signed and unsigned integer
194 types, each in 32 and 64 bit variants, IPv4 and IPv6 addresses, as
195 well as others. The advocacy draft [10] suggests that the predefined
196 data formats IPFilterRule and/or QoSFilterRule could be extended to
197 represent IP Flow Information. Such rules are represented as
198 readable UTF-8 strings. Alternatively, new AVPs could be defined to
199 represent flow information.
201 2.3 LFAP
203 LFAP [11][12][13] started out as the "Lightweight Flow Admission
204 Protocol" and was used to outsource shortcut creation decisions on
205 flow-based routers, as well as to provide per-flow statistics. Later
206 versions removed the admission function and changed the name to
207 "Lightweight Flow Accounting Protocol"
209 2.3.1 LFAP Protocol Operation
211 The exporter in LFAP is called the Connection Control Entity (CCE),
212 and the collector is the Flow Accounting Server (FAS). These
213 entities communicate with each other over a TCP connection. LFAP
214 knows thirteen message types, including operations for connection
215 management, version negotiation, flow information messages and
216 administrative requests. Authentication and encryption can be
217 provided by IPsec or TLS at lower layers. Additionally, the LFAP
218 protocol itself supports four levels of security using HMAC-MD5
219 authentication and DES-CBC encryption. Note that DES is now widely
220 regarded as not adequately secure, because its small key size makes
221 brute-force attacks viable.
223 A distinguishing feature is that LFAP has two different message types
224 for flow information: A Flow Accounting Request (FAR) message is sent
225 when a new flow is identified at the CCE (meter/exporter).
226 Accounting information is sent later in one or multiple Flow Update
227 Notification (FUN) messages. A collector must match each FUN to a
228 Flow ID previously sent in a FAR.
230 The LFAP document also defines a set of useful statistics about the
231 accounting process. A separate MIB document [14] is provided for
232 management of LFAP entities using SNMP.
234 2.3.2 LFAP Data Encoding
236 LFAP encodes data in a Type/Length/Value format with four bytes of
237 overhead per data item (two bytes for the type and two bytes for the
238 length field).
240 2.4 NetFlow v9
242 NetFlow v9 [2][15] is a generalized version of Cisco's NetFlow
243 protocol. Previous versions of NetFlow, in particular version 5,
244 have been widely implemented and used for the exporting and
245 collecting of IP flow information.
247 2.4.1 NetFlow Protocol Operation
249 NetFlow uses a very simple protocol, with the exporter sending
250 template, options, and data "FlowSets" to the collector. FlowSets
251 are sequences of data records of similar format. NetFlow is the only
252 one of the candidate protocols that works over UDP [4]. Because of
253 the simple unidirectional nature of the protocol, it should be
254 relatively straightforward to add mappings to other transport
255 protocols such as SCTP or TCP.
257 The use of SCTP to transport NetFlow v9 has been suggested in [16].
258 The suggested mapping describes how control and data can be mapped to
259 different streams within a single SCTP connection, and suggests that
260 the Partial Reliability extension [23] be used on data streams. In
261 the proposed mapping, the exporter would initiate the connection.
263 2.4.2 NetFlow Data Encoding
265 NetFlow v9 uses a template facility to describe exported data. The
266 data itself is represented in a compact way using network byte order.
268 2.5 Streaming IPDR
270 Streaming IPDR [17][18] is an application of the Network Data
271 Management-Usage (NDM-U) For IP Services specification version 3.1
272 [19]. It has been developed by the Internet Protocol Detail Record
273 Organization (IPDR, Inc. or ipdr.org). The terminology used is
274 similar to CRANE's, talking about Service Elements (SEs), mediation
275 systems and Business Support Systems (BSS).
277 2.5.1 Streaming IPDR Protocol Operation
279 Streaming IPDR operates over TCP. There is a "Trivial TCP Delivery"
280 mode as well as an "Acknowledged TCP Delivery" or "Reliable
281 Streaming" mode. The latter uses application-layer acknowledgements
282 for increased reliability.
284 The protocol is basically unidirectional. The exporter opens a
285 connection towards the collector, then sends a header followed by a
286 set of record descriptors. Then it can send "Usage Event" records
287 corresponding to these descriptors until the connection is
288 terminated. New record descriptors can be sent at any time.
289 Messages carry sequence numbers that are used for de-duplication
290 during failover. They are also referenced by application-level
291 acknowledgements when Reliable Streaming is used.
293 2.5.2 Streaming IPDR Data Encoding
295 IPDR uses an information modeling technique based on the XML-Schema
296 language [24]. Data can be represented in XML or in a streamlined
297 encoding based on the External Data Representation [25]. XDR forms
298 the basis of Sun's Remote Procedure Call and Network File System
299 protocols, and has proven to be both space- and processing-efficient.
301 3. Broad Classification of Candidate Protocols
303 In order to evaluate the candidate protocols against the higher-level
304 requirements laid out in the IPFIX Working Group charter, it is
305 useful to group them into broader categories.
307 3.1 Design Goals
309 One way to look at the candidate protocols is to study the goals that
310 have directed their respective design. Note that the intention is
311 not to exclude protocols that have been designed with a different
312 class of applications in mind, but simply to better understand the
313 different tradeoffs that distinguish the protocols.
315 3.1.1 High-Performance Flow Metering (NetFlow, LFAP)
317 Of the candidate protocols, Cisco's NetFlow is the purest example of
318 a highly specialized protocol that has been designed with the sole
319 objective of conveying accounting data from flow-aware routers at
320 high rates. Starting from a fixed set of accounting fields, it has
321 been extended a few times over the years to support additional fields
322 and various types of aggregation in the metering/exporting process.
324 Riverstone's LFAP is similarily focused, except that it originated in
325 a protocol to outsource the decision whether to create shortcuts in
326 flow-based routers. This is still manifest in an increased emphasis
327 on reliable operation, and in the split reporting of flow information
328 using Flow Accounting Request (FAR) and Flow Update Notification
329 (FUN) messages.
331 It has been pointed out that split reporting as done by LFAP can
332 reduce memory requirements at the exporter. This concerns a subset
333 of attributes that are neither "key" attributes which define flows,
334 nor attributes such as packet or byte counters that must be updated
335 for each packet anyway. On the other hand, when there are many
336 short-lived flows, the number of flow export messages will be
337 significantly higher than with "unitary" flow export models, and the
338 collector will have to keep state about active flows until they are
339 terminated.
341 3.1.2 Carrier-Grade Multi-Purpose Accounting (IPDR, CRANE)
343 Streaming IPDR and CRANE describe themselves as protocols to
344 facilitate the reliable transfer of accounting information between
345 Network Elements (or more generally "Service Elements" in the case of
346 IPDR) and Mediation Systems or Business Support Systems (BSS). They
347 reflect a view of the accounting problem and of network system
348 architectures that originates in traditional "vertically integrated"
349 telecommunications.
351 Both protocols also emphasize extensibility with the goal of
352 applicability to a wide range of accounting tasks.
354 IPDR is based on NDM-U, which uses the XML-Schema language for
355 machine-readable specification of accounting data structures, while
356 using the efficient XDR encoding for the actual data transfer.
358 CRANE uses templates to describe exported data. These templates are
359 negotiated between collector and exporter and can change during a
360 session.
362 3.1.3 General-Purpose AAA (Diameter)
364 Diameter is another example of a broader-purpose protocol, in that it
365 covers aspects of authentication and authorization as well as
366 accounting. This explains its strong emphasis on security and
367 reliability. The design also takes into account various types of
368 intermediate agents.
370 3.2 Data Representation
372 IPFIX is intended to be deployed, among others, in high-speed routers
373 and to be used for exporting detailed flow data at high flow rates.
374 Therefore it is useful to look at the tradeoffs between the
375 efficiency of data representation and the extensibility of data
376 models. The two main efficiency goals should be (1) to minimize the
377 export data rate and (2) to minimize data encoding overhead in the
378 exporter. The overhead of decoding flow data at the collector is
379 deemed less critical, and is partly covered by efficiency target (2),
380 since an encoding that is easy on the encoder is often also easy on
381 the decoder.
383 3.2.1 Externally Described Encoding (CRANE, IPDR, NetFlow)
385 The protcols in this group use an external mechanism to fully
386 describe the format in which flow data is encoded. The mechanisms
387 are "templates" in the case of CRANE and NetFlow, and a subset of the
388 XML-Schema language, or alternatively XDR IDL, for IPDR.
390 A fully external data format description allows for very compact
391 encoding, with data components such as 32-bit integers taking up only
392 four octets. The XDR representation used in IPDR additionally
393 ensures that larger fields are always aligned on 32-bit boundaries,
394 which can reduce processing requirements at both the exporter and the
395 collector, at a slight cost of space (thus bandwidth) due to padding.
397 Most protocols specify "network byte order" or "big-endian" format in
398 the export data format. CRANE is the only protocol where the
399 exporter may choose the byte ordering. The principal benefit is that
400 this lowers the processing demand on exporters based on little-endian
401 architectures.
403 3.2.2 Partly Self-describing Encoding (Diameter, LFAP)
405 Diameter and LFAP represent flow data using Type/Length/Value
406 encodings. While this makes it possible to partly decode flow data
407 without full context information - possibly useful for debugging - it
408 does increase the encoding size and thus the bandwidth requirements
409 both on the wire and in the exporter and collector.
411 LFAP has a "multi-record" encoding which claims to provide similar
412 wire efficiency as the externally described encodings while still
413 supporting diagnostic tools.
415 3.3 Protocol Flow
417 Another criterion for classification is the flow of protocol messages
418 between exporter and collector.
420 3.3.1 Mainly Unidirectional Protocols (IPDR, NetFlow)
422 In IPDR and NetFlow, the data flow is essentially from exporter to
423 collector, with the collector only sending acknowledgements. The
424 protocols send data descriptions (templates) on session
425 establishment, and then start sending flow export data based on these
426 templates. "Meta-information" about the operational status of the
427 metering and exporting processes (for example about the sampling
428 parameters in force at a given moment) is conveyed using a special
429 type of "Option" template in NetFlow v9. IPDR currently doesn't have
430 definitions for such "meta-data" types, but they could easily be
431 defined outside the protocol proper.
433 3.3.2 Bidirectional Protocols (CRANE, LFAP)
435 CRANE allows for negotiation of the templates used for data export at
436 the start of a session, and also allows negotiated template updates
437 later on. CRANE sessions include an exporter and potentially several
438 collectors, so these negotiations can involve more than two parties.
440 LFAP has an initial phase of version negotiation, followed by a phase
441 of "data negotiation". After these startup phases, the exporter
442 sends FAR and FUN messages to the collector. However, either party
443 may also send Administrative Request (AR) messages to the other, and
444 will normally receive Administrative Request Answers (ARA) in
445 response. Administrative Requests can be used for status inquiries,
446 including information about a specific active flow, or for
447 negotiation of the "Information Elements" that the collector wants
448 the exporter to export.
450 3.3.3 Unidirectional after Negotiation (Diameter)
452 Diameter has a general capabilities negotiation mechanism. The use
453 of Diameter for IPFIX hasn't been described in sufficient detail to
454 determine how capabilities negotiation would be used. After
455 negotiation, the protocol would operate in essentially unidirectional
456 mode, with Accounting-Request (ACR) messages flowing from the
457 exporter to the collector, and Accounting-Answer (ACA) messages
458 flowing back.
460 4. Item-Level Compliance Evaluation
462 The template for protocol advocates noted that not all requirements
463 in [1] apply directly to the flow export protocol. In particular,
464 sections 4 (Distinguishing Flows) and 5 (Metering Process) mainly
465 specify requirements on the metering mechanism that "feeds" the
466 exporter. However, in some cases they require information about the
467 metering process to be reported to collectors, so the flow export
468 protocol must support conveying this information.
470 4.1 Meter Reliability (5.1)
472 CRANE, Diameter, IPDR consider requirement 5.1 (reliability of the
473 metering process or indication of "missing reliability") out of scope
474 for the IPFIX protocol, which presumably means that they assume the
475 metering process to be reliable.
477 The NetFlow v9 advocacy draft takes a similar stance when it claims
478 "Total Compliance. The metering process is reliable." (although this
479 has been documented not to be true for all current Cisco
480 implementations of NetFlow v5).
482 LFAP is the only protocol that explicitly addresses the possibility
483 that data might be lost in the metering process, and provides useful
484 statistics the collectors to estimate not just the amount of flow
485 data that was lost, but also the amount of data not unaccounted for.
487 Note that in the general case, it can be considered unrealistic to
488 assume total reliability of a flow-based metering process in all
489 situations, unless sampling or coarse flow definitions are used.
490 With the fine-grained flow classification mechanisms mandated by
491 IPFIX, it is easy to imagine traffic where each - possibly very small
492 - packet would create a new flow. This kind of traffic is in fact
493 encountered in practice during aggressive port scans, and will
494 eventually lead to table overflows or exceeding of memory bandwidth
495 at the meter.
497 While some of these situations can be handled by dropping data later
498 on in the exporter, data transfer, or collector, or by transitioning
499 the meter to sampling mode (or increasing the sampling interval), it
500 will sometimes be considered the lesser evil to simply report on the
501 data that couldn't be accounted for. Currently LFAP is the only
502 protocol that supports this.
504 4.2 Sampling (5.2)
506 CRANE and IPDR don't mention the possibility of sampling. This is
507 natural because they are targeted towards telco-grade accounting,
508 where sampling would be considered inadmissible. Since support for
509 sampling is a "MAY" requirement, its lack could be tolerated, but
510 severely restricts the applicability of these protocols in places of
511 high aggregation, where absolute precision is not necessary. This
512 includes applications such as traffic profiling, traffic engineering,
513 and large-scale attack/intrusion detection, but also usage-based
514 accounting applications where charging based on sampling is agreed
515 upon.
517 The Diameter advocate acknowledges the existence of sampling and
518 suggests to define new (grouped) AVPs to carry information about the
519 sampling parameters in use.
521 LFAP does not currently support sampling, although its advocate
522 contends that adding support for this would be relatively
523 straightforward, without going into too much detail.
525 NetFlow v9 does support sampling (and many implementations and
526 deployments of sampled NetFlow exist for previous NetFlow versions).
527 Option Data is supposed to convey sampling configuration, although no
528 sampling-related field types have yet been defined in the draft.
530 4.3 Overload Behaviour (5.3)
532 The requirements document suggests that meters adapt to overload
533 situations, for example by changing to sampling (or reducing the
534 sampling rate if sampling is already in effect), by changing the flow
535 definition to coarser flow categories (thinning), by stopping to
536 meter, or by reducing packet processing.
538 In these situations, the requirements document mandates that flow
539 information from before the modification of metering behavior can be
540 cleanly distinguished from flow information from after the
541 modification. For the suggested mitigation methods of sampling or
542 thinning, this essentially means that all existing flows have to be
543 expired, and an entirely new set of flows must be started. This is
544 undesirable because it causes a peak of resource usage in an already
545 overloaded situation.
547 LFAP and NetFlow claim to handle this requirement, both by supporting
548 only the simple overload mitigation methods that don't require the
549 entire set of existing flows to be expired. The NetFlow advocate
550 claims that the reporting requirement could be easily met by expiring
551 existing flows with the old template, while sending a new template
552 for new flows. While it is true that NetFlow handles this
553 requirement in a very graceful manner, the general performance issue
554 remains.
556 CRANE, Diameter, and IPDR consider the requirement out of scope for
557 the protocol, although Diameter summarily acknowledges the possible
558 need for new AVP definitions related to mitigation methods.
560 4.4 Timestamps (5.4)
562 All protocols support reporting of timestamps with the required (one
563 centisecond) or better precision.
565 4.5 Time Synchronization (5.5)
567 While all other protocols have timestamp types that are relative to a
568 well-known reference time, timestamps in NetFlow are reported
569 relative to the sysUpTime of the exporting device. For applications
570 that require the absolute start/end times of flows, this means that
571 exporter sysUpTime has to be matched with absolute time. Although
572 every NetFlow export packet header contains a "UNIX Secs" field, it
573 cannot be used for UTC synchronization without loss of precision,
574 because this field only has 1-second resolution.
576 4.6 Flow Expiration (5.6)
578 As currently specified, this requirement concerns the metering
579 process only and has no bearing on the export protocol.
581 If it is desired to export the reason for flow expiration (e.g.
582 inactivity timeout, active flow timeout, expiration to reclaim
583 resources, or observation of a flow termination indication such as a
584 TCP FIN segment), then none of the protocols currently supports this,
585 although each could be extended to do so.
587 4.7 Ignore Port Copy (5.9)
589 This requirement concerns the metering process only and has no
590 bearing on the export protocol.
592 4.8 Information Model (6.1)
594 All candidate protocols have information models that can represent
595 all required and all optional attributes. The Diameter contribution
596 lacks some detail on how exactly the IPFIX-specific attributes should
597 be mapped.
599 4.9 Data Model (6.2)
601 4.9.1 Data Model Extensibility
603 Each candidate protocol defines a data model that allows for some
604 degree of extensibility.
606 CRANE uses Keys to specify fields in templates. A key "specification
607 MUST consist of the description and the data type of the accounting
608 item." Apparently extensibility is intended, but it is not clear
609 whether adding a new Key really only involves writing a textual
610 description and deciding upon a base type. Every Key also has a
611 32-bit Key ID, but from the current specification they don't seem to
612 carry global semantics.
614 Diameter's Attribute/Value Pairs (AVP) have a 32-bit identifier (AVP
615 Code) administered by IANA. In addition, there is an optional 32-bit
616 Vendor-ID that can contain an SMI Enterprise Number for
617 vendor-defined attributes. If the Vendor-ID (and a corresponding
618 flag in the attribute) is set, the AVP Code becomes local to that
619 vendor.
621 IPDR uses a subset of the XML-Schema language for extensibility, thus
622 allowing for vendor- and application-specific extensions of the data
623 model.
625 In LFAP, flow attributes are defined as Information Elements. There
626 is a 16-bit IE type code (which is carried in the export protocol for
627 every IE). One type code is reserved for vendor-specific extensions.
628 Arbitrary sub-types of the vendor-specific IE can be defined using
629 ASN.1 Object IDs (OIDs).
631 In NetFlow v9 as reviewed, data items are identified by a sixteen-bit
632 field type. 26 field types are defined in the draft. The draft
633 suggests to look check a Web page at Cisco Systems' site for the
634 current list of field types. It would be preferable if the
635 administration of the field type space would be delegated to IANA.
637 4.9.2 Flexible Flow Record Definition
639 All protocols allow for flexible flow record definitions. CRANE and
640 LFAP make the selection/negotiation of the attributes to be included
641 in flow records a part of the protocol, the other protocols leave
642 this to outside configuration mechanisms.
644 4.10 Data Transfer (6.3)
646 4.10.1 Congestion Awareness (6.3.1)
648 All protocols except for NetFlow v9 operate over a single TCP or SCTP
649 transport connection, and inherit the congestion-friendliness of
650 these protcols.
652 NetFlow v9 was initially defined to operate over UDP, but specified
653 in a transport-independent manner. Recently, a draft [16] has been
654 issued that describes how NetFlow v9 can be run over SCTP with the
655 proposed Partial Reliability extension. This transport mapping would
656 fill the congestion awareness requirement.
658 4.10.2 Reliability (6.3.2)
660 The requirements in the area of reliability are specified as follows:
661 If flow records can be lost during transfer, this must be indicated
662 to the collector in a way that permits the number of lost records to
663 be gauged; and the protocol must be open to reliability extensions
664 including retransmission of lost flow records, detection of exporter/
665 collector disconnection and fail-over, and acknowledgement of flow
666 records by the collecting process (application-level
667 acknowledgements).
669 Here are a few observations regarding the candidate protocols'
670 approaches to reliability. Note that the requirement for multiple
671 collectors (8.3) also touches on the issue of reliability.
673 CRANE, Diameter, and IPDR, as protocols that strive to be
674 carrier-grade accounting protocols, understandably exhibit a strong
675 emphasis on near-total reliability of the flow export process. All
676 three protocols use application-level acknowledgements (in case of
677 IPDR, optionally) to include the entire collection process in the
678 feedback loop. Indications of "lack of reliability" (lost flow data)
679 are somewhat unnatural to these protocols, because they take every
680 effort to never lose anything. These protocols seem suitable in
681 situations where one would rather drop a packet than forward it
682 unaccounted for.
684 LFAP has application-level acknowledgements, and it also reports
685 detailed statistics about lost flows and the amount of data that
686 couldn't be accounted for. It represents a middle ground in that it
687 acknowledges that accounting reliability will sometimes be sacrificed
688 for the benefit of other tasks, such as switching packets, and
689 provides the tools to gracefully deal with such situations.
691 NetFlow v9 is the only protocol for which the use of a "reliable"
692 transport protocol is optional, and the only protocol that doesn't
693 support application-level acknowledgements. In all fairness, it
694 should be noted that it is a very simple and efficient protocol, so
695 in an actual deployment it might exhibit a higher level of
696 reliability than some of the other protocols would given the same
697 amount of resources.
699 4.10.3 Security (6.3.3)
701 4.10.3.1 IPsec and TLS
703 All protocols can use, and their descriptions in fact recommend to
704 use, lower-layer security mechanisms such as IPsec and, with the
705 exception of NetFlow v9 over UDP, TLS. It can be argued that in all
706 envisioned usage scenarios for IPFIX, both IPsec and TLS provide
707 sufficient protection against the main identified threats of flow
708 data disclosure and forgery.
710 The Diameter draft is the only protocol definition that goes into
711 sufficent level of detail with respect to the application of these
712 mechanisms, in particular the negotiation of certificates and ciphers
713 in TLS, and the use of IKE [6] for IPsec. Diameter also mandates
714 that either IPsec or TLS be used.
716 4.10.3.2 Application-level Security
718 Diameter suggests an additional end-to-end security framework for
719 dealing with untrusted third-party agents. I am not entirely
720 convinced that this additional level of security justifies the
721 additional complexity in the context of IPFIX.
723 LFAP [11] is the only other protocol that includes some higher-level
724 security mechanisms, providing four levels of security including no
725 security, authenticated peers, flow data authentication, and flow
726 data encryption using HMAC-MD5-96 and DES-CBC.
728 As far as the author can judge - not being a security expert -,
729 LFAP's built-in support for authentication and encryption doesn't
730 provide significant additional security compared with the use of TLS
731 or IPsec. It is potentially useful in situations where TLS or IPsec
732 are unavailable for some reason, although in the context of IPFIX
733 scenarios it should be possible to assume support for these
734 lower-layer mechanisms if the participating devices are capable of
735 the necessary cryptographic methods at all.
737 4.10.4 Push and Pull Mode Reporting (6.4)
739 All protocols support the mandatory "push" mode.
741 The optional "pull" mode could be supported relatively easily in
742 Diameter, and is foreseen in NDM-U, the basis of the Streaming IPDR
743 proposal. CRANE, LFAP and NetFlow don't have a "pull" mode. For
744 CRANE and LFAP, adding one would not violate the spirit of the
745 protocols because they are already two-way, and in fact LFAP already
746 foresees inquiries about specific active flows using Administrative
747 Request (AR) messages with a RETURN_INDICATED_FLOWS Command Code IE.
749 4.10.5 Regular Reporting Interval (6.5)
751 As stated, this requirement concerns the metering process only and
752 has no bearing on the export protocol.
754 4.10.6 Notification on Specific Events (6.6)
756 The specific events listed in the requirements documents as examples
757 for "specific events" are "the arrival of the first packet of a new
758 flow and the termination of a flow after flow timeout". For the
759 former, only LFAP explicitly generates messages upon creation of a
760 new flow. NetFlow always exported flow information on expiration of
761 flows, either due to timeout or due to an indication of flow
762 termination. The other protocols are unspecific about when flow
763 information is exported.
765 On "specific events" in general, all protocols have some mechanism
766 that could be used for notification of asynchronous events. An
767 example for such an event would be that the sampling rate of the
768 meter was changed in response to a change in the load on the
769 exporting process.
771 CRANE has Status Request/Status Response messages, but as defined,
772 Status Requests can only be issued by the server (collector), so they
773 cannot be used by the server to signal asynchronous events. As in
774 IPDR, this could be circumvented by defining templates for
775 meta-information.
777 Diameter could use special Accounting-Request messages for event
778 notification.
780 IPDR would presumably define pseudo-"Usage Events" using an XML
781 Schema so that events can be reported along with usage data.
783 LFAP has Administrative Requests (AR) that can be initiated from
784 either side. The currently defined ARs are all information inquiries
785 or reconfiguration requests, but new ARs could be defined to provide
786 unsolicited information about specific asynchronous events. The LFAP
787 MIB also defines some traps/notifications. SNMP notifications are
788 useful to signal events to a network management system, but they are
789 less attractive as a mechanism to signal events that should be
790 somehow handled by a collector.
792 In NetFlow v9, Option Data FlowSets are defined to convey information
793 about the metering and export processes. The current draft specifies
794 that Option Data should be exported periodically, although this
795 requirement will be relaxed for asynchronous events. It should be
796 noted that periodical export of option flowsets (and also of
797 templates) may have been considered necessary because NetFlow can run
798 over an unreliable transport; it seems less natural when a reliable
799 transport such as TCP is used.
801 4.10.7 Anonymization (6.7)
803 None of the protocols include explicit support for anonymization.
804 All protocols could be extended to convey when and how anonymization
805 is being performed by an exporter, using mechanisms similar to those
806 that would be used to report on sampling.
808 4.10.8 Several Collecting Processes (8.3)
810 CRANE, Diameter, and IPDR all support multiple collectors in a backup
811 configuration. The failover case is analyzed in some detail, with
812 support for data buffering and de-duplication in failover situations.
814 NetFlow takes a more simple-minded approach in that it allows
815 multiple (currently: two) collectors to be configured in an exporter.
816 Both collectors will generally receive all data and could use
817 sequence numbers and inter-collector communication to de-duplicate
818 them. This is a simple way to improve availability but may also be
819 considered to be wasteful, both in terms of bandwidth and in terms of
820 other exporter resources. With the current UDP mapping it is easy
821 enough to send multiple copies of datagrams to different collectors,
822 but when SCTP or TCP is used, sending all data over multiple
823 connections will exacerbate performance issues.
825 Failover in LFAP must take into account that flow information is
826 split into FARs and FUNs. When a (primary) FAS A fails, a secondary
827 FAS B will receive FUNs for flows whose FARs had only been sent to A.
828 If such FUNs are to be handled correctly in the failover case, then
829 either the set of active flows must be kept in synch between the
830 primary and backup FASs, or the exporting CCE must have a way to
831 generate new FARs on failover.
833 5. Conclusions
835 Every candidate protocol has its strengths and weaknesses. If the
836 primary goal of the IPFIX standardization effort were to define a
837 carrier-grade accounting protocol that can also be used to carry IP
838 flow information, then one of CRANE, Diameter and Streaming IPDR
839 would probably be the candidate of choice.
841 But since the goal is to standardize existing practice in the area of
842 IP Flow Information Export, it makes sense to analyze why previous
843 versions of NetFlow have been so widely implemented and used. The
844 strong position of Cisco in the router market certainly played a
845 major role, but we should not underestimate the value of having a
846 simple and streamlined protocol that "does one thing and does it
847 well". It has been extremely easy to write NetFlow collecting
848 processes, as all the protocol demands from a collector is to sit
849 there and receive data. This model is no longer adequate when one
850 wants to support increased levels of reliability or dynamically
851 changing semantics for data export. But NetFlow remains a simple
852 protocol, mainly by leaving out issues of configuration/negotiation.
854 The biggest issue with NetFlow is that so far it could not resolve
855 itself to mandate a reliable (and congestion-friendly) transport.
856 This could easily be fixed, and bring with it some additional
857 possibilities for simplifications. For example it would no longer be
858 necessary to periodically retransmit Template FlowSets, and Option
859 Data FlowSets could become a more versatile way of reporting
860 meta-information about the metering and exporting processes either
861 synchronously or asynchronously. Application-level acknowledgements
862 - possibly as an option - would be a low-impact addition to improve
863 overall reliability.
865 LFAP is also relatively focused on flow information export, but
866 carries around too much baggage from its youth as the Lightweight
867 Flow Admission Protocol. The bidirectional nature and large number
868 of message types in the protocol are one symptom of this, the
869 separation of flow information into FARs and FUNs - which must be
870 matched at the collector - are another. Data encoding is less
871 space-efficient than that of CRANE, NetFlow or IPDR, and will present
872 a performance issue at high flow rates.
874 LFAP's indications of unaccounted data and its MIB are excellent
875 features that would be very useful in many operational situations.
877 5.1 Recommendation
879 It is the opinion of the evaluation team that the goals of the IPFIX
880 WG charter would best be served by starting with NetFlow v9, working
881 on lacking mechanisms in the areas of transport, security,
882 reliability, and redundant configurations, and doing so very
883 carefully in order to retain as much simplicity as possible and to
884 avoid overloading the protocol. By starting from the simplest
885 protocol that meets a large percentage of the specific requirements,
886 we can hope to arrive at a protocol that meets all requirements and
887 still allows widespread and cost-effective implementation.
889 As evaluated, NetFlow v9 doesn't specify any security mechanisms.
890 The IPFIX protocol specification must specify how the security
891 requirements in section 6.3.3 of [1] can be assured. The IPFIX
892 specification must be specific about the choice of
893 security-supporting protocol(s) and about all relevant issues such as
894 security negotiation, protocol modes permitted, and key management.
896 The other important requirement that isn't fulfilled by NetFlow v9
897 today is support for a congestion-aware protocol (see section 6.3.1
898 of [1]). So a mapping to a known congestion-friendly protocol such
899 as TCP, or, as suggested in [16], (PR-)SCTP, is considered as another
900 necessary step in the preparation of the IPFIX specification.
902 6. Security Considerations
904 The security mechanisms of the candidate protocols were discussed in
905 Section 4.10.3.
907 7. Acknowledgements
909 Many of the issues have been discussed with the other members of the
910 IPFIX evaluation team: Juergen Quittek, Mark Fullmer, Ram Gopal, and
911 Reinaldo Penno. Many participants on the ipfix mailing list provided
912 valuable feedback, including Vamsidhar Valluri, Paul Calato, Tal
913 Givoly, Jeff Meyer, Robert Lowe, Benoit Claise, and Carter Bullard.
914 Bert Wijnen, Steve Bellovin, Russ Housley and Allison Mankin provided
915 valuable feedback during AD and IESG review.
917 8. References
919 8.1 Normative References
921 [1] Quittek, J., "Requirements for IP Flow Information Export",
922 draft-ietf-ipfix-reqs-15 (work in progress), January 2004.
924 [2] Claise, B., "Cisco Systems NetFlow Services Export Version 9",
925 draft-claise-netflow-9-08 (work in progress), April 2004.
927 [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
928 September 1981.
930 [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
931 1980.
933 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
934 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
935 "Stream Control Transmission Protocol", RFC 2960, October 2000.
937 [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
938 RFC 2409, November 1998.
940 8.2 Informative References
942 [7] Zhang, K. and E. Elkin, "XACCT's Common Reliable Accounting for
943 Network Element (CRANE) Protocol Specification Version 1.0",
944 RFC 3423, November 2002.
946 [8] Zhang, K., "Evaluation of the CRANE Protocol Against IPFIX
947 Requirements", draft-kzhang-ipfix-eval-crane-00 (work in
948 progress), September 2002.
950 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
951 "Diameter Base Protocol", RFC 3588, September 2003.
953 [10] Zander, S., "Evaluation of Diameter Protocol against IPFIX
954 Requirements", draft-zander-ipfix-diameter-eval-00 (work in
955 progress), September 2002.
957 [11] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
958 Protocol Specification Vrsion 5.0", July 2002.
960 [12] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
961 Protocol Data Definition Specification Version 5.0", July
962 2002.
964 [13] Calato, P., "Evaluation Of Protocol LFAP Against IPFIX
965 Requirements", draft-calato-ipfix-lfap-eval-00 (work in
966 progress), September 2002.
968 [14] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
969 Protocol MIB", draft-calato-lfap-mib-00 (work in progress),
970 September 2002.
972 [15] Claise, B., "Evaluation Of NetFlow Version 9 Against IPFIX
973 Requirements", draft-claise-ipfix-eval-netflow-01 (work in
974 progress), September 2002.
976 [16] Djernaes, M., "Cisco Systems NetFlow Services Export Version 9
977 Transport", draft-djernaes-netflow-9-transport-00 (work in
978 progress), February 2003.
980 [17] Meyer, J., "Reliable Streaming Internet Protocol Detail
981 Records", draft-meyer-ipdr-streaming-00 (work in progress),
982 August 2002.
984 [18] Meyer, J., "Evaluation Of Streaming IPDR Against IPFIX
985 Requirements", draft-meyer-ipfix-ipdr-eval-00 (work in
986 progress), September 2002.
988 [19] Internet Protocol Detail Record Organization, "Network Data
989 Management - Usage (NDM-U) For IP-Based Services Version 3.1",
990 April 2002. URL: http://www.ipdr.org/documents/NDM-U_3.1.pdf
992 [20] Kent, S. and R. Atkinson, "Security Architecture for the
993 Internet Protocol", RFC 2401, November 1998.
995 [21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
996 2246, January 1999.
998 [22] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
999 Authentication Dial In User Service (RADIUS)", RFC 2865, June
1000 2000.
1002 [23] Stewart, R., "SCTP Partial Reliability Extension",
1003 draft-ietf-tsvwg-prsctp-03 (work in progress), January 2004.
1005 [24] DeRose, S., Maler, E. and D. Orchard, "XML 1.0 Recommendation",
1006 W3C FirstEdition REC-xml-19980210, February 1998.
1008 [25] Srinivasan, R., "XDR: External Data Representation Standard",
1009 RFC 1832, August 1995.
1011 URIs
1013 [26]
1015 [27]
1017 Author's Address
1019 Simon Leinen
1020 SWITCH
1021 Limmatquai 138
1022 P.O. Box
1023 CH-8021 Zurich
1024 Switzerland
1026 Phone: +41 1 268 1536
1027 EMail: simon@switch.ch
1029 Appendix A. A Note on References to the Candidate Protocol Documents
1031 At the time of the evaluation, the candidate protocol definitions, as
1032 well as their respective accompanying advocacy documents, were
1033 available as Internet-Drafts. As of the time of publication of this
1034 document, some of the protocols have been published as RFCs, others
1035 are still being revised as Internet-Drafts, and some will have
1036 expired. This document attempts to extract the relevant information
1037 from the individual protocol definitions and, in the context of the
1038 IPFIX requirements, provide a meaningful comparison between them.
1040 Since this evaluation proposes to use NetFlow v9 as the basis for the
1041 IPFIX protocol, only the reference to this protocol is considered
1042 "normative", although strictly spoken, the present document doesn't
1043 define any protocol, and the selected protocol will have to be
1044 further refined to become the IPFIX protocol.
1046 In the interest of stable references, the bibliography points to RFCs
1047 where those have become available (for DIAMETER and CRANE). Other
1048 protocols are still available only as Internet-Drafts and may
1049 eventually expire. The LFAP drafts - which already have expired -
1050 are still available from the www.nmops.org Web site [26] (as well as
1051 other places). The IPDR documents are available on the IPDR Web site
1052 [27].
1054 Intellectual Property Statement
1056 The IETF takes no position regarding the validity or scope of any
1057 Intellectual Property Rights or other rights that might be claimed to
1058 pertain to the implementation or use of the technology described in
1059 this document or the extent to which any license under such rights
1060 might or might not be available; nor does it represent that it has
1061 made any independent effort to identify any such rights. Information
1062 on the procedures with respect to rights in RFC documents can be
1063 found in BCP 78 and BCP 79.
1065 Copies of IPR disclosures made to the IETF Secretariat and any
1066 assurances of licenses to be made available, or the result of an
1067 attempt made to obtain a general license or permission for the use of
1068 such proprietary rights by implementers or users of this
1069 specification can be obtained from the IETF on-line IPR repository at
1070 http://www.ietf.org/ipr.
1072 The IETF invites any interested party to bring to its attention any
1073 copyrights, patents or patent applications, or other proprietary
1074 rights that may cover technology that may be required to implement
1075 this standard. Please address the information to the IETF at
1076 ietf-ipr@ietf.org.
1078 Disclaimer of Validity
1080 This document and the information contained herein are provided on an
1081 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1082 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1083 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1084 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1085 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1086 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1088 Copyright Statement
1090 Copyright (C) The Internet Society (2004). This document is subject
1091 to the rights, licenses and restrictions contained in BCP 78, and
1092 except as set forth therein, the authors retain all their rights.
1094 Acknowledgment
1096 Funding for the RFC Editor function is currently provided by the
1097 Internet Society.