RFC3955 日本語訳
3955 Evaluation of Candidate Protocols for IP Flow Information Export(IPFIX). S. Leinen. October 2004. (Format: TXT=55143 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Leinen Request for Comments: 3955 SWITCH Category: Informational October 2004
Network Working Group S. Leinen Request for Comments: 3955 SWITCH Category: Informational October 2004
Evaluation of Candidate Protocols for
IP Flow Information Export (IPFIX)
Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
Status of this Memo
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
Abstract
Abstract
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Summaries . . . . . . . . . . . . . . . . . . . . . . 2
2.1. CRANE. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Diameter . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. LFAP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. NetFlow v9 . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Streaming IPDR . . . . . . . . . . . . . . . . . . . . . 6
3. Broad Classification of Candidate Protocols . . . . . . . . . 7
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Data Representation. . . . . . . . . . . . . . . . . . . 8
3.3. Protocol Flow. . . . . . . . . . . . . . . . . . . . . . 9
4. Item-Level Compliance Evaluation . . . . . . . . . . . . . . . 10
4.1. Meter Reliability (5.1). . . . . . . . . . . . . . . . . 10
4.2. Sampling (5.2) . . . . . . . . . . . . . . . . . . . . . 11
4.3. Overload Behavior (5.3). . . . . . . . . . . . . . . . . 12
4.4. Timestamps (5.4) . . . . . . . . . . . . . . . . . . . . 12
4.5. Time Synchronization (5.5) . . . . . . . . . . . . . . . 12
4.6. Flow Expiration (5.6). . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Protocol Summaries . . . . . . . . . . . . . . . . . . . . . . 2 2.1. CRANE. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Diameter . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. LFAP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. NetFlow v9 . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Streaming IPDR . . . . . . . . . . . . . . . . . . . . . 6 3. Broad Classification of Candidate Protocols . . . . . . . . . 7 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Data Representation. . . . . . . . . . . . . . . . . . . 8 3.3. Protocol Flow. . . . . . . . . . . . . . . . . . . . . . 9 4. Item-Level Compliance Evaluation . . . . . . . . . . . . . . . 10 4.1. Meter Reliability (5.1). . . . . . . . . . . . . . . . . 10 4.2. Sampling (5.2) . . . . . . . . . . . . . . . . . . . . . 11 4.3. Overload Behavior (5.3). . . . . . . . . . . . . . . . . 12 4.4. Timestamps (5.4) . . . . . . . . . . . . . . . . . . . . 12 4.5. Time Synchronization (5.5) . . . . . . . . . . . . . . . 12 4.6. Flow Expiration (5.6). . . . . . . . . . . . . . . . . . 13
Leinen Informational [Page 1] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 1] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
4.7. Ignore Port Copy (5.9) . . . . . . . . . . . . . . . . . 13
4.8. Information Model (6.1). . . . . . . . . . . . . . . . . 13
4.9. Data Model (6.2) . . . . . . . . . . . . . . . . . . . . 13
4.10. Data Transfer (6.3). . . . . . . . . . . . . . . . . . . 14
5. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Recommendation . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix. A Note on References to the Candidate Protocol
Documents. . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 23
4.7. Ignore Port Copy (5.9) . . . . . . . . . . . . . . . . . 13 4.8. Information Model (6.1). . . . . . . . . . . . . . . . . 13 4.9. Data Model (6.2) . . . . . . . . . . . . . . . . . . . . 13 4.10. Data Transfer (6.3). . . . . . . . . . . . . . . . . . . 14 5. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Recommendation . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix. A Note on References to the Candidate Protocol Documents. . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
1. Introduction
The IP Flow Information Export (IPFIX) Working Group has been chartered to select a protocol for the export of flow information from traffic-observing devices (such as routers or dedicated probes). To this end, an evaluation team was formed to evaluate submitted protocols. Each protocol was represented by an advocate, who submitted a specific evaluation document for the respective protocol against the requirements document [1]. The specification of each protocol was itself available as one or several Internet-Drafts, sometimes referring normatively to documents from outside the IETF.
The IP Flow Information Export (IPFIX) Working Group has been chartered to select a protocol for the export of flow information from traffic-observing devices (such as routers or dedicated probes). To this end, an evaluation team was formed to evaluate submitted protocols. Each protocol was represented by an advocate, who submitted a specific evaluation document for the respective protocol against the requirements document [1]. The specification of each protocol was itself available as one or several Internet-Drafts, sometimes referring normatively to documents from outside the IETF.
This document contains an evaluation of the submitted protocols with respect to the requirements document, and on a more general level, to the working group charter.
This document contains an evaluation of the submitted protocols with respect to the requirements document, and on a more general level, to the working group charter.
The following IPFIX candidate protocol submissions were evaluated:
The following IPFIX candidate protocol submissions were evaluated:
o CRANE [7], [8] o Diameter [9], [10] o LFAP [11], [12], [13] o NetFlow v9 [2], [15], [16] o Streaming IPDR [17], [18]
o CRANE [7], [8] o Diameter [9], [10] o LFAP [11], [12], [13] o NetFlow v9 [2], [15], [16] o Streaming IPDR [17], [18]
This document uses terminology defined in [1] intermixed with that from submissions to explain the mapping between the two.
This document uses terminology defined in [1] intermixed with that from submissions to explain the mapping between the two.
2. Protocol Summaries
2. Protocol Summaries
In the following, each candidate protocol is described briefly, highlighting its specific distinguishing features.
In the following, each candidate protocol is described briefly, highlighting its specific distinguishing features.
Leinen Informational [Page 2] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 2] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
2.1. CRANE
2.1. CRANE
XACCT's Common Reliable Accounting for Network Element Protocol Version 1.0 [7][8] is described as a protocol for the transmission of accounting information from "Network Elements" to "mediation" and "business support systems".
XACCT's Common Reliable Accounting for Network Element Protocol Version 1.0 [7][8] is described as a protocol for the transmission of accounting information from "Network Elements" to "mediation" and "business support systems".
2.1.1. CRANE Protocol Operation
2.1.1. CRANE Protocol Operation
The exporting side is the CRANE client, the collecting side is the CRANE server. Note that it is the server that is responsible for initiating the connection to the client. A client can have multiple simultaneous connections to different servers for robustness. Each server has an associated priority. A client only exports to the server with the highest priority that is perceived operational.
The exporting side is the CRANE client, the collecting side is the CRANE server. Note that it is the server that is responsible for initiating the connection to the client. A client can have multiple simultaneous connections to different servers for robustness. Each server has an associated priority. A client only exports to the server with the highest priority that is perceived operational.
Clients and servers exchange messages over a reliable protocol such as TCP [3] or (preferably) the Stream Control Transmission Protocol (SCTP) [5]. The protocol uses application-layer acknowledgements as an indication of successful processing by the server. Strong authentication or data confidentiality aren't supported by the protocol, but can be supported by lower-layer mechanisms such as IPsec [20] or TLS [21].
Clients and servers exchange messages over a reliable protocol such as TCP [3] or (preferably) the Stream Control Transmission Protocol (SCTP) [5]. The protocol uses application-layer acknowledgements as an indication of successful processing by the server. Strong authentication or data confidentiality aren't supported by the protocol, but can be supported by lower-layer mechanisms such as IPsec [20] or TLS [21].
The protocol is bidirectional over the entire duration of a session. There are 20 different message types. The protocol supports template negotiation, not only at startup but also later on in a session, as well as general status inquiries. There is a separate version negotiation protocol defined over UDP.
The protocol is bidirectional over the entire duration of a session. There are 20 different message types. The protocol supports template negotiation, not only at startup but also later on in a session, as well as general status inquiries. There is a separate version negotiation protocol defined over UDP.
2.1.2. CRANE Data Encoding
2.1.2. CRANE Data Encoding
Data encoding is based on templates. Templates contain "keys" representing items in data records. Clients (exporters) publish templates to servers (collectors). Servers can then select the subset of fields in a template that they are interested in. The client will suppress keys that haven't been selected by the server.
Data encoding is based on templates. Templates contain "keys" representing items in data records. Clients (exporters) publish templates to servers (collectors). Servers can then select the subset of fields in a template that they are interested in. The client will suppress keys that haven't been selected by the server.
Data records contain references to template and configuration instances. They also carry sequence numbers (DSNs for Data Sequence Numbers). These sequence numbers can be used to de-duplicate data records that have been delivered multiple times during failover/fail-back in redundant configurations. A "duplicate" bit is set in these situations as a hint for the de-duplication process.
Data records contain references to template and configuration instances. They also carry sequence numbers (DSNs for Data Sequence Numbers). These sequence numbers can be used to de-duplicate data records that have been delivered multiple times during failover/fail-back in redundant configurations. A "duplicate" bit is set in these situations as a hint for the de-duplication process.
Leinen Informational [Page 3] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 3] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
The encoding of (flow information) data records themselves is very compact. The client (exporter) can choose to send data in big-endian (network byte order) or little-endian format. There are eighteen fixed-size key types, as well as five variable-length string and binary data (BLOB) types.
The encoding of (flow information) data records themselves is very compact. The client (exporter) can choose to send data in big-endian (network byte order) or little-endian format. There are eighteen fixed-size key types, as well as five variable-length string and binary data (BLOB) types.
2.2. Diameter
2.2. Diameter
Diameter [9][10] is an evolution of the Remote Authentication Dial In User Service (RADIUS) protocol [22]. RADIUS is widely used to outsource authentication and authorization in dialup access environments. Diameter is a generalized and extensible protocol intended to support Authentication, Authorization and Accounting (AAA) requirements of different applications. Dialup and Mobile IPv4 are examples of such applications defined in the IETF.
Diameter [9][10] is an evolution of the Remote Authentication Dial In User Service (RADIUS) protocol [22]. RADIUS is widely used to outsource authentication and authorization in dialup access environments. Diameter is a generalized and extensible protocol intended to support Authentication, Authorization and Accounting (AAA) requirements of different applications. Dialup and Mobile IPv4 are examples of such applications defined in the IETF.
2.2.1. Diameter Protocol Operation
2.2.1. Diameter Protocol Operation
Diameter is a peer-to-peer protocol. The base protocol defines fourteen command codes, organized as seven request/response command pairs. Presumably, only a subset of these would be used in a pure IPFIX application. Diameter includes capability negotiation and error notifications. Diameter operates over TCP or (preferred) SCTP. There is a framework for end-to-end security, the mechanisms for which are defined in a separate document. IPsec or TLS can be used to provide authentication or encryption at the underlying layers.
Diameter is a peer-to-peer protocol. The base protocol defines fourteen command codes, organized as seven request/response command pairs. Presumably, only a subset of these would be used in a pure IPFIX application. Diameter includes capability negotiation and error notifications. Diameter operates over TCP or (preferred) SCTP. There is a framework for end-to-end security, the mechanisms for which are defined in a separate document. IPsec or TLS can be used to provide authentication or encryption at the underlying layers.
2.2.2. Diameter Data Encoding
2.2.2. Diameter Data Encoding
Diameter conveys data in the form of attribute/value pairs (AVPs). An AVP consists of eight bytes of header plus the space to store the data, which depends on the data format. There are numerous predefined AVP data formats, including signed and unsigned integer types, each in 32 and 64 bit variants, IPv4 and IPv6 addresses, as well as others. The advocacy document [10] suggests that the predefined data formats IPFilterRule and/or QoSFilterRule could be extended to represent IP Flow Information. Such rules are represented as readable UTF-8 strings. Alternatively, new AVPs could be defined to represent flow information.
Diameter conveys data in the form of attribute/value pairs (AVPs). An AVP consists of eight bytes of header plus the space to store the data, which depends on the data format. There are numerous predefined AVP data formats, including signed and unsigned integer types, each in 32 and 64 bit variants, IPv4 and IPv6 addresses, as well as others. The advocacy document [10] suggests that the predefined data formats IPFilterRule and/or QoSFilterRule could be extended to represent IP Flow Information. Such rules are represented as readable UTF-8 strings. Alternatively, new AVPs could be defined to represent flow information.
2.3. LFAP
2.3. LFAP
LFAP [11][12][13] started out as the "Lightweight Flow Admission Protocol" and was used to outsource shortcut creation decisions on flow-based routers, as well as to provide per-flow statistics. Later versions removed the admission function and changed the name to "Lightweight Flow Accounting Protocol".
LFAP [11][12][13] started out as the "Lightweight Flow Admission Protocol" and was used to outsource shortcut creation decisions on flow-based routers, as well as to provide per-flow statistics. Later versions removed the admission function and changed the name to "Lightweight Flow Accounting Protocol".
Leinen Informational [Page 4] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 4] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
2.3.1. LFAP Protocol Operation
2.3.1. LFAP Protocol Operation
The exporter in LFAP is called the Connection Control Entity (CCE), and the collector is the Flow Accounting Server (FAS). These entities communicate with each other over a TCP connection. LFAP knows thirteen message types, including operations for connection management, version negotiation, flow information messages and administrative requests. Authentication and encryption can be provided by IPsec or TLS at lower layers. Additionally, the LFAP protocol itself supports four levels of security using HMAC-MD5 authentication and DES-CBC encryption. Note that DES is now widely regarded as not adequately secure, because its small key size makes brute-force attacks viable.
The exporter in LFAP is called the Connection Control Entity (CCE), and the collector is the Flow Accounting Server (FAS). These entities communicate with each other over a TCP connection. LFAP knows thirteen message types, including operations for connection management, version negotiation, flow information messages and administrative requests. Authentication and encryption can be provided by IPsec or TLS at lower layers. Additionally, the LFAP protocol itself supports four levels of security using HMAC-MD5 authentication and DES-CBC encryption. Note that DES is now widely regarded as not adequately secure, because its small key size makes brute-force attacks viable.
A distinguishing feature is that LFAP has two different message types for flow information: A Flow Accounting Request (FAR) message is sent when a new flow is identified at the CCE (meter/exporter). Accounting information is sent later in one or multiple Flow Update Notification (FUN) messages. A collector must match each FUN to a Flow ID previously sent in a FAR.
A distinguishing feature is that LFAP has two different message types for flow information: A Flow Accounting Request (FAR) message is sent when a new flow is identified at the CCE (meter/exporter). Accounting information is sent later in one or multiple Flow Update Notification (FUN) messages. A collector must match each FUN to a Flow ID previously sent in a FAR.
The LFAP document also defines a set of useful statistics about the accounting process. A separate MIB document [14] is provided for management of LFAP entities using SNMP.
The LFAP document also defines a set of useful statistics about the accounting process. A separate MIB document [14] is provided for management of LFAP entities using SNMP.
2.3.2. LFAP Data Encoding
2.3.2. LFAP Data Encoding
LFAP encodes data in a Type/Length/Value format with four bytes of overhead per data item (two bytes for the type and two bytes for the length field).
LFAP encodes data in a Type/Length/Value format with four bytes of overhead per data item (two bytes for the type and two bytes for the length field).
2.4. NetFlow v9
2.4. NetFlow v9
NetFlow v9 [2][15] is a generalized version of Cisco's NetFlow protocol. Previous versions of NetFlow, in particular version 5, have been widely implemented and used for the exporting and collecting of IP flow information.
NetFlow v9 [2][15] is a generalized version of Cisco's NetFlow protocol. Previous versions of NetFlow, in particular version 5, have been widely implemented and used for the exporting and collecting of IP flow information.
2.4.1. NetFlow Protocol Operation
2.4.1. NetFlow Protocol Operation
NetFlow uses a very simple protocol, with the exporter sending template, options, and data "FlowSets" to the collector. FlowSets are sequences of data records of similar format. NetFlow is the only one of the candidate protocols that works over UDP [4]. Because of the simple unidirectional nature of the protocol, it should be relatively straightforward to add mappings to other transport protocols such as SCTP or TCP.
NetFlow uses a very simple protocol, with the exporter sending template, options, and data "FlowSets" to the collector. FlowSets are sequences of data records of similar format. NetFlow is the only one of the candidate protocols that works over UDP [4]. Because of the simple unidirectional nature of the protocol, it should be relatively straightforward to add mappings to other transport protocols such as SCTP or TCP.
Leinen Informational [Page 5] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 5] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
The use of SCTP to transport NetFlow v9 has been suggested in [16]. The suggested mapping describes how control and data can be mapped to different streams within a single SCTP connection, and suggests that the Partial Reliability extension [23] be used on data streams. In the proposed mapping, the exporter would initiate the connection.
The use of SCTP to transport NetFlow v9 has been suggested in [16]. The suggested mapping describes how control and data can be mapped to different streams within a single SCTP connection, and suggests that the Partial Reliability extension [23] be used on data streams. In the proposed mapping, the exporter would initiate the connection.
2.4.2. NetFlow Data Encoding
2.4.2. NetFlow Data Encoding
NetFlow v9 uses a template facility to describe exported data. The data itself is represented in a compact way using network byte order.
NetFlow v9 uses a template facility to describe exported data. The data itself is represented in a compact way using network byte order.
2.5. Streaming IPDR
2.5. Streaming IPDR
Streaming IPDR [17][18] is an application of the Network Data Management-Usage (NDM-U) for IP Services specification version 3.1 [19]. It has been developed by the Internet Protocol Detail Record Organization (IPDR, Inc. or ipdr.org). The terminology used is similar to CRANE's, talking about Service Elements (SEs), mediation systems and Business Support Systems (BSS).
Streaming IPDR [17][18] is an application of the Network Data Management-Usage (NDM-U) for IP Services specification version 3.1 [19]. It has been developed by the Internet Protocol Detail Record Organization (IPDR, Inc. or ipdr.org). The terminology used is similar to CRANE's, talking about Service Elements (SEs), mediation systems and Business Support Systems (BSS).
2.5.1. Streaming IPDR Protocol Operation
2.5.1. Streaming IPDR Protocol Operation
Streaming IPDR operates over TCP. There is a "Trivial TCP Delivery" mode as well as an "Acknowledged TCP Delivery" or "Reliable Streaming" mode. The latter uses application-layer acknowledgements for increased reliability.
Streaming IPDR operates over TCP. There is a "Trivial TCP Delivery" mode as well as an "Acknowledged TCP Delivery" or "Reliable Streaming" mode. The latter uses application-layer acknowledgements for increased reliability.
The protocol is basically unidirectional. The exporter opens a connection towards the collector, then sends a header followed by a set of record descriptors. Then it can send "Usage Event" records corresponding to these descriptors until the connection is terminated. New record descriptors can be sent at any time. Messages carry sequence numbers that are used for de-duplication during failover. They are also referenced by application-level acknowledgements when Reliable Streaming is used.
The protocol is basically unidirectional. The exporter opens a connection towards the collector, then sends a header followed by a set of record descriptors. Then it can send "Usage Event" records corresponding to these descriptors until the connection is terminated. New record descriptors can be sent at any time. Messages carry sequence numbers that are used for de-duplication during failover. They are also referenced by application-level acknowledgements when Reliable Streaming is used.
2.5.2. Streaming IPDR Data Encoding
2.5.2. Streaming IPDR Data Encoding
IPDR uses an information modeling technique based on the XML-Schema language [24]. Data can be represented in XML or in a streamlined encoding based on the External Data Representation [25]. XDR forms the basis of Sun's Remote Procedure Call and Network File System protocols, and has proven to be both space- and processing-efficient.
IPDR uses an information modeling technique based on the XML-Schema language [24]. Data can be represented in XML or in a streamlined encoding based on the External Data Representation [25]. XDR forms the basis of Sun's Remote Procedure Call and Network File System protocols, and has proven to be both space- and processing-efficient.
Leinen Informational [Page 6] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 6] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
3. Broad Classification of Candidate Protocols
3. Broad Classification of Candidate Protocols
In order to evaluate the candidate protocols against the higher-level requirements laid out in the IPFIX Working Group charter, it is useful to group them into broader categories.
In order to evaluate the candidate protocols against the higher-level requirements laid out in the IPFIX Working Group charter, it is useful to group them into broader categories.
3.1. Design Goals
3.1. Design Goals
One way to look at the candidate protocols is to study the goals that have directed their respective design. Note that the intention is not to exclude protocols that have been designed with a different class of applications in mind, but simply to better understand the different tradeoffs that distinguish the protocols.
One way to look at the candidate protocols is to study the goals that have directed their respective design. Note that the intention is not to exclude protocols that have been designed with a different class of applications in mind, but simply to better understand the different tradeoffs that distinguish the protocols.
3.1.1. High-Performance Flow Metering (NetFlow, LFAP)
3.1.1. High-Performance Flow Metering (NetFlow, LFAP)
Of the candidate protocols, Cisco's NetFlow is the purest example of a highly specialized protocol that has been designed with the sole objective of conveying accounting data from flow-aware routers at high rates. Starting from a fixed set of accounting fields, it has been extended a few times over the years to support additional fields and various types of aggregation in the metering/exporting process.
Of the candidate protocols, Cisco's NetFlow is the purest example of a highly specialized protocol that has been designed with the sole objective of conveying accounting data from flow-aware routers at high rates. Starting from a fixed set of accounting fields, it has been extended a few times over the years to support additional fields and various types of aggregation in the metering/exporting process.
Riverstone's LFAP is similarly focused, except that it originated in a protocol to outsource the decision whether to create shortcuts in flow-based routers. This is still manifest in an increased emphasis on reliable operation, and in the split reporting of flow information using Flow Accounting Request (FAR) and Flow Update Notification (FUN) messages.
Riverstone's LFAP is similarly focused, except that it originated in a protocol to outsource the decision whether to create shortcuts in flow-based routers. This is still manifest in an increased emphasis on reliable operation, and in the split reporting of flow information using Flow Accounting Request (FAR) and Flow Update Notification (FUN) messages.
It has been pointed out that split reporting as done by LFAP can reduce memory requirements at the exporter. This concerns a subset of attributes that are neither "key" attributes which define flows, nor attributes such as packet or byte counters that must be updated for each packet anyway. On the other hand, when there are many short-lived flows, the number of flow export messages will be significantly higher than with "unitary" flow export models, and the collector will have to keep state about active flows until they are terminated.
It has been pointed out that split reporting as done by LFAP can reduce memory requirements at the exporter. This concerns a subset of attributes that are neither "key" attributes which define flows, nor attributes such as packet or byte counters that must be updated for each packet anyway. On the other hand, when there are many short-lived flows, the number of flow export messages will be significantly higher than with "unitary" flow export models, and the collector will have to keep state about active flows until they are terminated.
3.1.2. Carrier-Grade Multi-Purpose Accounting (IPDR, CRANE)
3.1.2. Carrier-Grade Multi-Purpose Accounting (IPDR, CRANE)
Streaming IPDR and CRANE describe themselves as protocols to facilitate the reliable transfer of accounting information between Network Elements (or more generally "Service Elements" in the case of IPDR) and Mediation Systems or Business Support Systems (BSS). They
Streaming IPDR and CRANE describe themselves as protocols to facilitate the reliable transfer of accounting information between Network Elements (or more generally "Service Elements" in the case of IPDR) and Mediation Systems or Business Support Systems (BSS). They
Leinen Informational [Page 7] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 7] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
reflect a view of the accounting problem and of network system architectures that originates in traditional "vertically integrated" telecommunications.
reflect a view of the accounting problem and of network system architectures that originates in traditional "vertically integrated" telecommunications.
Both protocols also emphasize extensibility with the goal of applicability to a wide range of accounting tasks.
Both protocols also emphasize extensibility with the goal of applicability to a wide range of accounting tasks.
IPDR is based on NDM-U, which uses the XML-Schema language for machine-readable specification of accounting data structures, while using the efficient XDR encoding for the actual data transfer.
IPDR is based on NDM-U, which uses the XML-Schema language for machine-readable specification of accounting data structures, while using the efficient XDR encoding for the actual data transfer.
CRANE uses templates to describe exported data. These templates are negotiated between collector and exporter and can change during a session.
CRANE uses templates to describe exported data. These templates are negotiated between collector and exporter and can change during a session.
3.1.3. General-Purpose AAA (Diameter)
3.1.3. General-Purpose AAA (Diameter)
Diameter is another example of a broader-purpose protocol, in that it covers aspects of authentication and authorization as well as accounting. This explains its strong emphasis on security and reliability. The design also takes into account various types of intermediate agents.
Diameter is another example of a broader-purpose protocol, in that it covers aspects of authentication and authorization as well as accounting. This explains its strong emphasis on security and reliability. The design also takes into account various types of intermediate agents.
3.2. Data Representation
3.2. Data Representation
IPFIX is intended to be deployed, among others, in high-speed routers and to be used for exporting detailed flow data at high flow rates. Therefore it is useful to look at the tradeoffs between the efficiency of data representation and the extensibility of data models. The two main efficiency goals should be (1) to minimize the export data rate and (2) to minimize data encoding overhead in the exporter. The overhead of decoding flow data at the collector is deemed less critical, and is partly covered by efficiency target (2), since an encoding that is easy on the encoder is often also easy on the decoder.
IPFIX is intended to be deployed, among others, in high-speed routers and to be used for exporting detailed flow data at high flow rates. Therefore it is useful to look at the tradeoffs between the efficiency of data representation and the extensibility of data models. The two main efficiency goals should be (1) to minimize the export data rate and (2) to minimize data encoding overhead in the exporter. The overhead of decoding flow data at the collector is deemed less critical, and is partly covered by efficiency target (2), since an encoding that is easy on the encoder is often also easy on the decoder.
3.2.1. Externally Described Encoding (CRANE, IPDR, NetFlow)
3.2.1. Externally Described Encoding (CRANE, IPDR, NetFlow)
The protocols in this group use an external mechanism to fully describe the format in which flow data is encoded. The mechanisms are "templates" in the case of CRANE and NetFlow, and a subset of the XML-Schema language, or alternatively XDR IDL, for IPDR.
The protocols in this group use an external mechanism to fully describe the format in which flow data is encoded. The mechanisms are "templates" in the case of CRANE and NetFlow, and a subset of the XML-Schema language, or alternatively XDR IDL, for IPDR.
Leinen Informational [Page 8] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 8] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
A fully external data format description allows for very compact encoding, with data components such as 32-bit integers taking up only four octets. The XDR representation used in IPDR additionally ensures that larger fields are always aligned on 32-bit boundaries, which can reduce processing requirements at both the exporter and the collector, at a slight cost of space (thus bandwidth) due to padding.
A fully external data format description allows for very compact encoding, with data components such as 32-bit integers taking up only four octets. The XDR representation used in IPDR additionally ensures that larger fields are always aligned on 32-bit boundaries, which can reduce processing requirements at both the exporter and the collector, at a slight cost of space (thus bandwidth) due to padding.
Most protocols specify "network byte order" or "big-endian" format in the export data format. CRANE is the only protocol where the exporter may choose the byte ordering. The principal benefit is that this lowers the processing demand on exporters based on little-endian architectures.
Most protocols specify "network byte order" or "big-endian" format in the export data format. CRANE is the only protocol where the exporter may choose the byte ordering. The principal benefit is that this lowers the processing demand on exporters based on little-endian architectures.
3.2.2. Partly Self-describing Encoding (Diameter, LFAP)
3.2.2. Partly Self-describing Encoding (Diameter, LFAP)
Diameter and LFAP represent flow data using Type/Length/Value encodings. While this makes it possible to partly decode flow data without full context information - possibly useful for debugging - it does increase the encoding size and thus the bandwidth requirements both on the wire and in the exporter and collector.
Diameter and LFAP represent flow data using Type/Length/Value encodings. While this makes it possible to partly decode flow data without full context information - possibly useful for debugging - it does increase the encoding size and thus the bandwidth requirements both on the wire and in the exporter and collector.
LFAP has a "multi-record" encoding which claims to provide similar wire efficiency as the externally described encodings while still supporting diagnostic tools.
LFAP has a "multi-record" encoding which claims to provide similar wire efficiency as the externally described encodings while still supporting diagnostic tools.
3.3. Protocol Flow
3.3. Protocol Flow
Another criterion for classification is the flow of protocol messages between exporter and collector.
Another criterion for classification is the flow of protocol messages between exporter and collector.
3.3.1. Mainly Unidirectional Protocols (IPDR, NetFlow)
3.3.1. Mainly Unidirectional Protocols (IPDR, NetFlow)
In IPDR and NetFlow, the data flow is essentially from exporter to collector, with the collector only sending acknowledgements. The protocols send data descriptions (templates) on session establishment, and then start sending flow export data based on these templates. "Meta-information" about the operational status of the metering and exporting processes (for example about the sampling parameters in force at a given moment) is conveyed using a special type of "Option" template in NetFlow v9. IPDR currently doesn't have definitions for such "meta-data" types, but they could easily be defined outside the protocol proper.
In IPDR and NetFlow, the data flow is essentially from exporter to collector, with the collector only sending acknowledgements. The protocols send data descriptions (templates) on session establishment, and then start sending flow export data based on these templates. "Meta-information" about the operational status of the metering and exporting processes (for example about the sampling parameters in force at a given moment) is conveyed using a special type of "Option" template in NetFlow v9. IPDR currently doesn't have definitions for such "meta-data" types, but they could easily be defined outside the protocol proper.
Leinen Informational [Page 9] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 9] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
3.3.2. Bidirectional Protocols (CRANE, LFAP)
3.3.2. Bidirectional Protocols (CRANE, LFAP)
CRANE allows for negotiation of the templates used for data export at the start of a session, and also allows negotiated template updates later on. CRANE sessions include an exporter and potentially several collectors, so these negotiations can involve more than two parties.
CRANE allows for negotiation of the templates used for data export at the start of a session, and also allows negotiated template updates later on. CRANE sessions include an exporter and potentially several collectors, so these negotiations can involve more than two parties.
LFAP has an initial phase of version negotiation, followed by a phase of "data negotiation". After these startup phases, the exporter sends FAR and FUN messages to the collector. However, either party may also send Administrative Request (AR) messages to the other, and will normally receive Administrative Request Answers (ARA) in response. Administrative Requests can be used for status inquiries, including information about a specific active flow, or for negotiation of the "Information Elements" that the collector wants the exporter to export.
LFAP has an initial phase of version negotiation, followed by a phase of "data negotiation". After these startup phases, the exporter sends FAR and FUN messages to the collector. However, either party may also send Administrative Request (AR) messages to the other, and will normally receive Administrative Request Answers (ARA) in response. Administrative Requests can be used for status inquiries, including information about a specific active flow, or for negotiation of the "Information Elements" that the collector wants the exporter to export.
3.3.3. Unidirectional after Negotiation (Diameter)
3.3.3. Unidirectional after Negotiation (Diameter)
Diameter has a general capabilities negotiation mechanism. The use of Diameter for IPFIX hasn't been described in sufficient detail to determine how capabilities negotiation would be used. After negotiation, the protocol would operate in essentially unidirectional mode, with Accounting-Request (ACR) messages flowing from the exporter to the collector, and Accounting-Answer (ACA) messages flowing back.
Diameter has a general capabilities negotiation mechanism. The use of Diameter for IPFIX hasn't been described in sufficient detail to determine how capabilities negotiation would be used. After negotiation, the protocol would operate in essentially unidirectional mode, with Accounting-Request (ACR) messages flowing from the exporter to the collector, and Accounting-Answer (ACA) messages flowing back.
4. Item-Level Compliance Evaluation
4. Item-Level Compliance Evaluation
The template for protocol advocates noted that not all requirements in [1] apply directly to the flow export protocol. In particular, sections 4 (Distinguishing Flows) and 5 (Metering Process) mainly specify requirements on the metering mechanism that "feeds" the exporter. However, in some cases they require information about the metering process to be reported to collectors, so the flow export protocol must support conveying this information.
The template for protocol advocates noted that not all requirements in [1] apply directly to the flow export protocol. In particular, sections 4 (Distinguishing Flows) and 5 (Metering Process) mainly specify requirements on the metering mechanism that "feeds" the exporter. However, in some cases they require information about the metering process to be reported to collectors, so the flow export protocol must support conveying this information.
4.1. Meter Reliability (5.1)
4.1. Meter Reliability (5.1)
CRANE, Diameter, IPDR consider requirement 5.1 (reliability of the metering process or indication of "missing reliability") out of scope for the IPFIX protocol, which presumably means that they assume the metering process to be reliable.
CRANE, Diameter, IPDR consider requirement 5.1 (reliability of the metering process or indication of "missing reliability") out of scope for the IPFIX protocol, which presumably means that they assume the metering process to be reliable.
The NetFlow v9 advocacy document takes a similar stance when it claims "Total Compliance. The metering process is reliable." (although this has been documented not to be true for all current Cisco implementations of NetFlow v5).
The NetFlow v9 advocacy document takes a similar stance when it claims "Total Compliance. The metering process is reliable." (although this has been documented not to be true for all current Cisco implementations of NetFlow v5).
Leinen Informational [Page 10] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
Leinen Informational [Page 10] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
LFAP is the only protocol that explicitly addresses the possibility that data might be lost in the metering process, and provides useful statistics for the collectors to estimate, not just the amount of flow data that was lost, but also the amount of data that was not unaccounted for.
LFAP is the only protocol that explicitly addresses the possibility that data might be lost in the metering process, and provides useful statistics for the collectors to estimate, not just the amount of flow data that was lost, but also the amount of data that was not unaccounted for.
Note that in the general case, it can be considered unrealistic to assume total reliability of a flow-based metering process in all situations, unless sampling or coarse flow definitions are used. With the fine-grained flow classification mechanisms mandated by IPFIX, it is easy to imagine traffic where each - possibly very small - packet would create a new flow. This kind of traffic is in fact encountered in practice during aggressive port scans, and will eventually lead to table overflows or exceeding of memory bandwidth at the meter.
一般的な場合では、すべての状況における、流れベースの計量プロセスの総信頼性を仮定するために非現実的であるとそれを考えることができることに注意してください、標本抽出か下品なフロー定義が使用されていない場合。 きめ細かに粒状の流れ分類メカニズムがIPFIXによって強制されている状態で、それぞれ、ことによると非常に小さいところでトラフィックを想像するのは簡単です--パケットは新しい流れを引き起こすでしょう。 この種類のトラフィックは、事実上、実際には攻撃的なポート・スキャンの間、遭遇して、結局、メーターでメモリ帯域幅のテーブルオーバーフローか超過につながるでしょう。
While some of these situations can be handled by dropping data later on in the exporter, data transfer, or collector, or by transitioning the meter to sampling mode (or increasing the sampling interval), it will sometimes be considered the lesser evil to simply report on the data that couldn't be accounted for. Currently LFAP is the only protocol that supports this.
標本抽出モードへの後で輸出業者でデータを下げるか、データ転送、コレクタ、または移行によるメーターでこれらの状況のいくつかを扱うことができますが(標本抽出間隔を増強して)、それは、説明できなかったデータに関して単に報告するためにレサー・イーブルであると時々考えられるでしょう。 現在の、LFAPはこれをサポートする唯一のプロトコルです。
4.2. Sampling (5.2)
4.2. 標本抽出(5.2)
CRANE and IPDR don't mention the possibility of sampling. This is natural because they are targeted towards telco-grade accounting, where sampling would be considered inadmissible. Since support for sampling is a "MAY" requirement, its lack could be tolerated, but severely restricts the applicability of these protocols in places of high aggregation, where absolute precision is not necessary. This includes applications such as traffic profiling, traffic engineering, and large-scale attack/intrusion detection, but also usage-based accounting applications where charging based on sampling is agreed upon.
CRANEとIPDRは標本抽出の可能性について言及しません。 これは、通信業者グレード会計に向かって狙うので、当然です。そこでは、標本抽出が承認しがたいと考えられるでしょう。 標本抽出のサポートが「5月」要件であるので、不足は、許容できましたが、高い集合の場所で厳しくこれらのプロトコルの適用性を制限します。そこでは、絶対精度は必要ではありません。 これは標本抽出に基づく充電が同意されるトラフィックプロフィールや、交通工学や、大規模な攻撃/侵入検出ですが、用法ベースのも会計アプリケーションなどの応用を含んでいます。
The Diameter advocate acknowledges the existence of sampling and suggests to define new (grouped) AVPs to carry information about the sampling parameters in use.
Diameter支持者は、標本抽出の存在を承認して、使用中の標本抽出パラメタの情報を運ぶために新しい(分類される)AVPsを定義するために示します。
LFAP does not currently support sampling, although its advocate contends that adding support for this would be relatively straightforward, without going into too much detail.
LFAPは現在標本抽出をサポートしません、支持者は、このサポートを加えるのが比較的簡単であると主張しますが、あまりに多くの詳細を調べないで。
NetFlow v9 does support sampling (and many implementations and deployments of sampled NetFlow exist for previous NetFlow versions). Option Data is supposed to convey sampling configuration, although no sampling-related field types have yet been defined in the document.
NetFlow v9は標本抽出をサポートします(抽出されたNetFlowの多くの実装と展開は前のNetFlowバージョンのために存在しています)。 どんな標本抽出関連のフィールド・タイプもドキュメントではまだ定義されていませんが、オプションDataは標本抽出構成を伝えるべきです。
Leinen Informational [Page 11] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[11ページ]のRFC3955評価
4.3. Overload Behavior (5.3)
4.3. 振舞いを積みすぎてください。(5.3)
The requirements document suggests that meters adapt to overload situations, for example by changing to sampling (or reducing the sampling rate if sampling is already in effect), by changing the flow definition to coarser flow categories (thinning), by stopping to meter, or by reducing packet processing.
それが計量するドキュメントが、示す要件は、例えば、標本抽出(標本抽出が既に有効であるなら標本抽出率を減少させて)に変化するか、フロー定義をより下品な流れカテゴリ(間引き)に変えるか、計量するために止まるか、またはパケット処理を抑えることによって状況を積みすぎるために適合します。
In these situations, the requirements document mandates that flow information from before the modification of metering behavior can be cleanly distinguished from flow information from after the modification. For the suggested mitigation methods of sampling or thinning, this essentially means that all existing flows have to be expired, and an entirely new set of flows must be started. This is undesirable because it causes a peak of resource usage in an already overloaded situation.
これらの状況、ドキュメントが変更の後に以前と、流れ情報と計量の振舞いの変更を清潔に区別できるというその流れ情報を強制する要件で。 標本抽出か間引きの提案された緩和メソッドのために、これは、すべての既存の流れが吐き出されなければならなくて、完全に新しい流れを始めなければならないことを本質的には意味します。 既に積みすぎられた状況におけるリソース用法のピークを引き起こすので、これは望ましくありません。
LFAP and NetFlow claim to handle this requirement, both by supporting only the simple overload mitigation methods that don't require the entire set of existing flows to be expired. The NetFlow advocate claims that the reporting requirement could be easily met by expiring existing flows with the old template, while sending a new template for new flows. While it is true that NetFlow handles this requirement in a very graceful manner, the general performance issue remains.
LFAPとNetFlowは、この要件を扱うと主張します、ともに吐き出されるために全体のセットに存在を要求しない簡単なオーバーロード緩和メソッドだけに流れをサポートすることによって。 NetFlowは新しい流れのために新しいテンプレートを送る間、古いテンプレートで既存の流れを吐き出すことによって容易に報告必要条件を満たすことができるだろうというクレームを支持します。 NetFlowが非常に優雅な方法でこの要件を扱うのが、本当ですが、一般的能力問題は残っています。
CRANE, Diameter, and IPDR consider the requirement out of scope for the protocol, although Diameter summarily acknowledges the possible need for new AVP definitions related to mitigation methods.
CRANE、Diameter、およびIPDRはプロトコルのために範囲から要件を考えます、Diameterが要約して緩和メソッドに関連する新しいAVP定義の可能な必要性を承認しますが。
4.4. Timestamps (5.4)
4.4. タイムスタンプ(5.4)
All protocols support reporting of timestamps with the required (one centisecond) or better precision.
すべてのプロトコルが必要(1つのセンチセカンド)か、より良い精度でタイムスタンプの報告をサポートします。
4.5. Time Synchronization (5.5)
4.5. 時間同期化(5.5)
While all other protocols have timestamp types that are relative to a well-known reference time, timestamps in NetFlow are reported relative to the sysUpTime of the exporting device. For applications that require the absolute start/end times of flows, this means that exporter sysUpTime has to be matched with absolute time. Although every NetFlow export packet header contains a "UNIX Secs" field, it cannot be used for UTC synchronization without loss of precision, because this field only has 1-second resolution.
他のすべてのプロトコルにはよく知られる参照時間に比例しているタイムスタンプタイプがある間、NetFlowのタイムスタンプは輸出デバイスのsysUpTimeに比例して報告されます。 流れの絶対始め/終わりの倍を必要とするアプリケーションのために、これは、輸出業者sysUpTimeが絶対時間に合わせられなければならないことを意味します。 すべてのNetFlow輸出パケットのヘッダーが「UNIX Secs」分野を含みますが、UTC同期に精度の損失なしでそれを使用できません、この分野には1秒の解決があるだけであるので。
Leinen Informational [Page 12] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[12ページ]のRFC3955評価
4.6. Flow Expiration (5.6)
4.6. 流れ満了(5.6)
As currently specified, this requirement concerns the metering process only and has no bearing on the export protocol.
現在指定されるように、この要件は、計量プロセスだけに関係があって、輸出プロトコルに堪えることを持っていません。
If it is desired to export the reason for flow expiration (e.g., inactivity timeout, active flow timeout, expiration to reclaim resources, or observation of a flow termination indication such as a TCP FIN segment), then none of the protocols currently supports this, although each could be extended to do so.
流れ満了(TCP FINセグメントなどの流れ終了しるしの例えば、不活発タイムアウト、アクティブな流れタイムアウト、リソースを取り戻す満了、または観測)の理由をエクスポートするのが必要であるなら、プロトコルのいずれも現在これをサポートしません、そうするためにそれぞれを広げることができましたが。
4.7. Ignore Port Copy (5.9)
4.7. ポートコピーを無視してください。(5.9)
This requirement only concerns the metering process and has no bearing on the export protocol.
この要件は、計量プロセスに関係があるだけであり、輸出プロトコルに堪えることを持っていません。
4.8. Information Model (6.1)
4.8. 情報モデル(6.1)
All candidate protocols have information models that can represent all required and all optional attributes. The Diameter contribution lacks some detail on how exactly the IPFIX-specific attributes should be mapped.
すべての候補プロトコルには、すべての必要な属性とすべての任意の属性を表すことができる情報モデルがあります。 貢献が何らかの詳細を欠いているDiameter IPFIX特有の属性が写像されるべきである。
4.9. Data Model (6.2)
4.9. データモデル(6.2)
4.9.1. Data Model Extensibility
4.9.1. データモデル伸展性
Each candidate protocol defines a data model that allows for some degree of extensibility.
それぞれの候補プロトコルはいくらかの伸展性を考慮するデータモデルを定義します。
CRANE uses Keys to specify fields in templates. A key "specification MUST consist of the description and the data type of the accounting item." Apparently extensibility is intended, but it is not clear whether adding a new Key really only involves writing a textual description and deciding upon a base type. Every Key also has a 32- bit Key ID, but from the current specification they don't seem to carry global semantics.
CRANEは、テンプレートの分野を指定するのにキーズを使用します。 A「仕様は会計項目に関する記述とデータ型から成らなければなりません」主要な。 明らかに、伸展性は意図しますが、新しいKeyが、本当に原文の記述を書くことを伴うだけであると言い足して、ベースについて決めるのがタイプされるかどうかは、明確ではありません。 また、あらゆるKeyには、Key IDが32ビットありますが、現在の仕様から、彼らは、グローバルな意味論を運ぶように思えません。
Diameter's Attribute/Value Pairs (AVP) have a 32-bit identifier (AVP Code) administered by IANA. In addition, there is an optional 32-bit Vendor-ID that can contain an SMI Enterprise Number for vendor- defined attributes. If the Vendor-ID (and a corresponding flag in the attribute) is set, the AVP Code becomes local to that vendor.
直径のAttribute/値のペア(AVP)で、IANAは32ビットの識別子(AVP Code)を管理します。 さらに、ベンダーの定義された属性のためのSMIエンタープライズNumberを含むことができる任意の32ビットのVendor-IDがあります。 Vendor-ID(そして、属性における対応する旗)が設定されるなら、AVP Codeはそのベンダーに地方になります。
IPDR uses a subset of the XML-Schema language for extensibility, thus allowing for vendor- and application-specific extensions of the data model.
IPDRは伸展性にXML-スキーマ言語の部分集合を使用します、その結果、データモデルのベンダーとアプリケーション特有の拡大を考慮します。
Leinen Informational [Page 13] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[13ページ]のRFC3955評価
In LFAP, flow attributes are defined as Information Elements. There is a 16-bit IE type code (which is carried in the export protocol for every IE). One type code is reserved for vendor-specific extensions. Arbitrary sub-types of the vendor-specific IE can be defined using ASN.1 Object IDs (OIDs).
LFAPでは、流れ属性はInformation Elementsと定義されます。 16ビットのIEタイプコード(あらゆるIEのために輸出プロトコルで運ばれる)があります。 1つのタイプコードがベンダー特有の拡大のために予約されます。 ASN.1Object ID(OIDs)を使用することでベンダー特有のIEの任意のサブタイプを定義できます。
In NetFlow v9 as reviewed, data items are identified by a sixteen-bit field type. 26 field types are defined in the document. The document suggests to look check a Web page at Cisco Systems' site for the current list of field types. It would be preferable if the administration of the field type space would be delegated to IANA.
見直されるとしてのNetFlow v9では、データ項目は16ビットのフィールド・タイプによって特定されます。 26 分野タイプはドキュメントで定義されます。 ドキュメントはフィールド・タイプの現在のリストのためにシスコシステムズのサイトに外観チェックにウェブページを示します。 フィールド・タイプスペースの管理をIANAへ代表として派遣するなら、望ましいでしょう。
4.9.2. Flexible Flow Record Definition
4.9.2. フレキシブルな流れ記録的な定義
All protocols allow for flexible flow record definitions. CRANE and LFAP make the selection/negotiation of the attributes to be included in flow records a part of the protocol, the other protocols leave this to outside configuration mechanisms.
すべてのプロトコルがフレキシブルな流れのために記録的な定義を許します。 CRANEとLFAPは、プロトコルの一部であり、他のプロトコルが外の構成メカニズムにこれを残すという流れ記録に含まれるように属性の選択/交渉をします。
4.10. Data Transfer (6.3)
4.10. データ転送(6.3)
4.10.1. Congestion Awareness (6.3.1)
4.10.1. 混雑認識(6.3.1)
All protocols except for NetFlow v9 operate over a single TCP or SCTP transport connection, and inherit the congestion-friendliness of these protocols.
NetFlow v9以外のすべてのプロトコルが、独身のTCPかSCTP輸送接続の上で作動して、これらのプロトコルの混雑友情を引き継ぎます。
NetFlow v9 was initially defined to operate over UDP, but specified in a transport-independent manner. Recently, a document [16] has been issued that describes how NetFlow v9 can be run over SCTP with the proposed Partial Reliability extension. This transport mapping would fill the congestion awareness requirement.
NetFlow v9は初めはUDPの上で作動するために定義されましたが、輸送から独立している方法で指定されました。 最近、提案されたPartial Reliability拡張子でどうNetFlow v9を実行できるかをSCTPに説明するドキュメント[16]を発行しました。 この輸送マッピングは混雑認識要件をいっぱいにしているでしょう。
4.10.2. Reliability (6.3.2)
4.10.2. 信頼性(6.3.2)
The requirements in the area of reliability are specified as follows: If flow records can be lost during transfer, this must be indicated to the collector in a way that permits the number of lost records to be gauged; and the protocol must be open to reliability extensions including retransmission of lost flow records, detection of exporter/collector disconnection and fail-over, and acknowledgement of flow records by the collecting process (application-level acknowledgements).
信頼性の領域の要件は以下の通り指定されます: 転送の間、流れ記録を失うことができるなら、無くなっている記録の数が測られることを許可する方法でこれをコレクタに示さなければなりません。 そして、プロトコルは収集プロセス(アプリケーションレベル承認)で無くなっている流れ記録の「再-トランスミッション」、輸出業者/コレクタ断線とフェイルオーバーの検出、および流れ記録の承認を含む信頼性の拡大に開かれているに違いありません。
Here are a few observations regarding the candidate protocols' approaches to reliability. Note that the requirement for multiple collectors (8.3) also touches on the issue of reliability.
ここに、信頼性への候補プロトコルのアプローチに関していくつかの観測があります。 また、複数のコレクタ(8.3)のための要件が信頼性の問題に触れることに注意してください。
Leinen Informational [Page 14] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[14ページ]のRFC3955評価
CRANE, Diameter, and IPDR, as protocols that strive to be carrier- grade accounting protocols, understandably exhibit a strong emphasis on near-total reliability of the flow export process. All three protocols use application-level acknowledgements (in case of IPDR, optionally) to include the entire collection process in the feedback loop. Indications of "lack of reliability" (lost flow data) are somewhat unnatural to these protocols, because they take every effort to never lose anything. These protocols seem suitable in situations where one would rather drop a packet than forward it unaccounted for.
CRANE(プロトコルとしてのキャリヤーグレード会計プロトコルであるように努力するDiameter、およびIPDR)は合計における、流れ輸出プロセスの信頼性への強い強調を目立って示します。 すべての3つのプロトコルが、フィードバックループに全体の収集プロセスを含むのに、アプリケーションレベル承認(IPDRの場合に任意に)を使用します。 「信頼性の不足」(フロー・データを失う)のしるしはこれらのプロトコルにいくらか不自然です、何も決して失わないようにあらゆる取り組みを取るので。 これらのプロトコルは1つがそれが非説明したフォワードよりパケットを下げる方がましである状況で適当に思えます。
LFAP has application-level acknowledgements, and it also reports detailed statistics about lost flows and the amount of data that couldn't be accounted for. It represents a middle ground in that it acknowledges that accounting reliability will sometimes be sacrificed for the benefit of other tasks, such as switching packets, and provides the tools to gracefully deal with such situations.
LFAPには、アプリケーションレベル承認があります、そして、また、それは原因にならされることができなかった無くなっている流れとデータ量に関する詳細な統計を報告します。 会計の信頼性が切り換えパケットなどの他のタスクの利益のために時々犠牲にされて、優雅にそのような状況に対処するためにツールを提供すると認めるので、それは妥協点を表します。
NetFlow v9 is the only protocol for which the use of a "reliable" transport protocol is optional, and the only protocol that doesn't support application-level acknowledgements. In all fairness, it should be noted that it is a very simple and efficient protocol, so in an actual deployment it might exhibit a higher level of reliability than some of the other protocols given the same amount of resources.
NetFlow v9は「信頼できる」トランスポート・プロトコルの使用が任意である唯一のプロトコルと、アプリケーションレベル承認をサポートしない唯一のプロトコルです。 公平に見て、同じ量のリソースを考えて、実際の展開では、他のプロトコルのいくつかより高いレベルの信頼性を示すことができるようにそれが非常に簡単で効率的なプロトコルであることに注意されるべきです。
4.10.3. Security (6.3.3)
4.10.3. セキュリティ(6.3.3)
4.10.3.1. IPsec and TLS
4.10.3.1. IPsecとTLS
All protocols can use, and their descriptions in fact recommend them to use, lower-layer security mechanisms such as IPsec and, with the exception of NetFlow v9 over UDP, TLS. It can be argued that in all envisioned usage scenarios for IPFIX, both IPsec and TLS provide sufficient protection against the main identified threats of flow data disclosure and forgery.
プロトコルが使用できて、事実上、彼らの記述が使用、IPsecやUDPの上のNetFlow v9以外のTLSなどの下層セキュリティー対策へのそれらを推薦するすべて。 IPFIXのためのすべての思い描かれた用法シナリオに、IPsecとTLSの両方がフロー・データ公開と偽造の主な特定された脅威に対する十分な保護を提供すると主張できます。
The Diameter document is the only protocol definition that goes into sufficient level of detail with respect to the application of these mechanisms, in particular the negotiation of certificates and ciphers in TLS, and the use of IKE [6] for IPsec. Diameter also mandates that either IPsec or TLS be used.
DiameterドキュメントはIPsecのために特にこれらのメカニズムの応用、TLSの証明書と暗号の交渉、およびIKE[6]の使用に関して十分なレベルの詳細を調べる唯一のプロトコル定義です。 また、直径は、IPsecかTLSのどちらかが使用されるのを強制します。
4.10.3.2. Application-level Security
4.10.3.2. アプリケーションレベルセキュリティ
Diameter suggests an additional end-to-end security framework for dealing with untrusted third-party agents. I am not entirely convinced that this additional level of security justifies the additional complexity in the context of IPFIX.
直径は、信頼されていない第三者エージェントに対応するために終わりから終わりへの追加セキュリティフレームワークを示します。 私はこの追加レベルのセキュリティがIPFIXの文脈における追加複雑さを正当化すると完全に確信していません。
Leinen Informational [Page 15] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[15ページ]のRFC3955評価
LFAP [11] is the only other protocol that includes some higher-level security mechanisms, providing four levels of security including no security, authenticated peers, flow data authentication, and flow data encryption using HMAC-MD5-96 and DES-CBC.
LFAP[11]はいくつかの、よりハイレベルのセキュリティー対策を含んでいる他の唯一のプロトコルです、HMAC-MD5-96とDES-CBCを使用することでセキュリティがなく、認証された同輩、フロー・データ認証、および流れデータ暗号化を含む4つのレベルのセキュリティを提供して。
As far as the author can judge (not being a security expert), LFAP's built-in support for authentication and encryption doesn't provide significant additional security compared with the use of TLS or IPsec. It is potentially useful in situations where TLS or IPsec are unavailable for some reason, although in the context of IPFIX scenarios, it should be possible to assume support for these lower- layer mechanisms if the participating devices are capable of the necessary cryptographic methods at all.
作者が判断できる(安全保障専門家でなく)限り、認証と暗号化のためのLFAPの標準装備はTLSかIPsecの使用と比べて重要な追加担保を提供しません。 それはTLSかIPsecがある理由で入手できないところで状況で潜在的に役に立ちます、参加デバイスが全く必要な暗号のメソッドができるならこれらの低い層のメカニズムのサポートを仮定するのがIPFIXシナリオの文脈で可能であるべきですが。
4.10.4. Push and Pull Mode Reporting (6.4)
4.10.4. モード報告を押して、引いてください。(6.4)
All protocols support the mandatory "push" mode.
すべてのプロトコルが、義務的な「プッシュ」がモードであるとサポートします。
The optional "pull" mode could be supported relatively easily in Diameter, and is foreseen in NDM-U, the basis of the Streaming IPDR proposal. CRANE, LFAP and NetFlow don't have a "pull" mode. For CRANE and LFAP, adding one would not violate the spirit of the protocols because they are already two-way, and in fact LFAP already foresees inquiries about specific active flows using Administrative Request (AR) messages with a RETURN_INDICATED_FLOWS Command Code IE.
任意の「牽引力」モードは、Diameterで比較的容易にサポートすることができて、NDM-U(Streaming IPDR提案の基礎)で見通されます。 CRANE、LFAP、およびNetFlowには、「牽引力」モードがありません。 CRANEとLFAPに関しては、それらが既に両用であるので、1つを加えるのはプロトコルの精神に違反しないで、事実上、LFAPはRETURN_INDICATED_FLOWS Command Code IEがあるAdministrative Request(AR)メッセージを使用することで既に特定のアクティブな流れに関する問い合せについて見通します。
4.10.5. Regular Reporting Interval (6.5)
4.10.5. 一定の報告間隔(6.5)
As stated, this requirement concerns the metering process only and has no bearing on the export protocol.
述べられているように、この要件は、計量プロセスだけに関係があって、輸出プロトコルに堪えることを持っていません。
4.10.6. Notification on Specific Events (6.6)
4.10.6. 特定のイベントに関する通知(6.6)
The specific events listed in the requirements documents as examples for "specific events" are "the arrival of the first packet of a new flow and the termination of a flow after flow timeout". For the former, only LFAP explicitly generates messages upon creation of a new flow. NetFlow always exported flow information on expiration of flows, either due to timeout or due to an indication of flow termination. The other protocols are unspecific about when flow information is exported.
特定のイベントは、「特定のイベント」のための例が「新しい流れの最初のパケットの到着と流れタイムアウトの後の流れの終了」であるので、要件ドキュメントに記載しました。 前者のために、LFAPだけが明らかに新しい流れの作成に関するメッセージを生成します。 NetFlowは、タイムアウトのためか流れの満了か、流れ終了のしるしのためいつも流れが情報であるとエクスポートしました。 他のプロトコルは流れ情報がエクスポートされる時に関して「非-特定」です。
On "specific events" in general, all protocols have some mechanism that could be used for notification of asynchronous events. An example for such an event would be that the sampling rate of the meter was changed in response to a change in the load on the exporting process.
一般に、「特定のイベント」では、すべてのプロトコルが非同期的なイベントの通知に使用できる何らかのメカニズムを持っています。 そのようなイベントのための例は輸出プロセスで負荷における変化に対応してメーターの標本抽出率を変えたということでしょう。
Leinen Informational [Page 16] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[16ページ]のRFC3955評価
CRANE has Status Request/Status Response messages, but as defined, Status Requests can only be issued by the server (collector), so they cannot be used by the server to signal asynchronous events. As in IPDR, this could be circumvented by defining templates for meta- information.
彼らはCRANEにはStatus Request/状態Responseメッセージがありますが、定義されるようにサーバ(コレクタ)でStatus Requestsを発行できるだけであるのでサーバによって使用されて、非同期的なイベントに合図することがないことができます。 IPDRのように、メタ情報のためにテンプレートを定義することによって、これを回避できるでしょう。
Diameter could use special Accounting-Request messages for event notification.
直径はイベント通知に特別なAccounting-要求メッセージを使用するかもしれません。
IPDR would presumably define pseudo-"Usage Events" using an XML Schema so that events can be reported along with usage data.
おそらく、IPDRは用法データと共にイベントを報告できるようにXML Schemaを使用する疑似な「用法Events」を定義するでしょう。
LFAP has Administrative Requests (AR) that can be initiated from either side. The currently defined ARs are all information inquiries or reconfiguration requests, but new ARs could be defined to provide unsolicited information about specific asynchronous events. The LFAP MIB also defines some traps/notifications. SNMP notifications are useful to signal events to a network management system, but they are less attractive as a mechanism to signal events that should be somehow handled by a collector.
LFAPはどちらの側からも開始できるAdministrative Requests(AR)を持っています。 現在定義されたARsはすべての情報問い合せか再構成要求ですが、特定の非同期的なイベントの求められていない情報を提供するために新しいARsを定義できました。 また、LFAP MIBはいくつかの罠/通知を定義します。 SNMP通知はネットワーク管理システムにイベントに合図するために役に立ちますが、それらはメカニズムとしてそれほどコレクタによってどうにか扱われるべきである信号イベントに魅力的ではありません。
In NetFlow v9, Option Data FlowSets are defined to convey information about the metering and export processes. The current document specifies that Option Data should be exported periodically, although this requirement will be relaxed for asynchronous events. It should be noted that periodical export of option flowsets (and also of templates) may have been considered necessary because NetFlow can run over an unreliable transport; it seems less natural when a reliable transport such as TCP is used.
NetFlow v9では、Option Data FlowSetsは、計量に関して情報を伝達して、プロセスをエクスポートするために定義されます。 この要件は非同期的なイベントのためにリラックスするでしょうが、現在のドキュメントは、Option Dataが定期的にエクスポートされるべきであると指定します。 NetFlowが頼り無い輸送をひくことができるのでオプションflowsets(そしてテンプレートについても)の定期刊行の輸出が必要であると考えられたかもしれないことに注意されるべきです。 TCPなどの信頼できる輸送が使用されているとき、それは、より自然でなく見えます。
4.10.7. Anonymization (6.7)
4.10.7. Anonymization(6.7)
None of the protocols include explicit support for anonymization. All protocols could be extended to convey when and how anonymization is being performed by an exporter, using mechanisms similar to those that would be used to report on sampling.
プロトコルのいずれもanonymizationの明白なサポートを含んでいません。 いつ、anonymizationが輸出業者によってどう実行されているかを運ぶためにすべてのプロトコルを広げることができました、標本抽出に関して報告するのに使用されるものと同様のメカニズムを使用して。
4.10.8. Several Collecting Processes (8.3)
4.10.8. いくつかの収集プロセス(8.3)
CRANE, Diameter, and IPDR all support multiple collectors in a backup configuration. The failover case is analyzed in some detail, with support for data buffering and de-duplication in failover situations.
CRANE、Diameter、およびIPDRはバックアップ構成で複数のコレクタを皆、サポートします。 フェイルオーバーケースはフェイルオーバー状況におけるデータバッファリングと反-複製のサポートで何らかの詳細に分析されます。
NetFlow takes a more simple-minded approach in that it allows multiple (currently: two) collectors to be configured in an exporter. Both collectors will generally receive all data and could use sequence numbers and inter-collector communication to de-duplicate them. This is a simple way to improve availability but may also be
複数の(: 現在の2)コレクタが輸出業者で構成されるのを許容するので、NetFlowは、より純真なアプローチを取ります。 両方のコレクタは、一般に、すべてのデータを受け取って、反-それらをコピーするのに一連番号と相互コレクタコミュニケーションを使用できました。 これは、有用性を改良する簡単な方法ですが、また、あるかもしれません。
Leinen Informational [Page 17] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[17ページ]のRFC3955評価
considered to be wasteful, both in terms of bandwidth and in terms of other exporter resources. With the current UDP mapping it is easy enough to send multiple copies of datagrams to different collectors, but when SCTP or TCP is used, sending all data over multiple connections will exacerbate performance issues.
帯域幅と他の輸出業者リソースで無駄であると考えられます。 現在のUDPでは、それを写像するのは複本のデータグラムを異なったコレクタに送るほど簡単ですが、SCTPかTCPが使用されているとき、複数の接続の上にすべてのデータを送るのは性能問題を悪化させるでしょう。
Failover in LFAP must take into account that flow information is split into FARs and FUNs. When a (primary) FAS A fails, a secondary FAS B will receive FUNs for flows whose FARs had only been sent to A. If such FUNs are to be handled correctly in the failover case, then either the set of active flows must be kept in sync between the primary and backup FASs, or the exporting CCE must have a way to generate new FARs on failover.
LFAPのフェイルオーバーは、流れ情報がFARsとFUNsに分けられるのを考慮に入れなければなりません。 (プライマリ)のFAS Aが失敗すると、セカンダリFAS BがFARsによるA.Ifに送って、そのようなFUNsがフェイルオーバー場合で正しく扱われることになっていて、次に、予備選挙とバックアップFASsの間の同時性でアクティブな流れのセットを維持しなければならないということだけであった流れのためにFUNsを受けなければならないでしょうか、または輸出CCEにはフェイルオーバーで新しいFARsを生成する方法がなければなりません。
5. Conclusions
5. 結論
Every candidate protocol has its strengths and weaknesses. If the primary goal of the IPFIX standardization effort were to define a carrier-grade accounting protocol that can also be used to carry IP flow information, then one of CRANE, Diameter and Streaming IPDR would probably be the candidate of choice.
あらゆる候補プロトコルには、その長所と短所があります。 IPFIX標準化取り組みのプライマリ目標がまた、IP流れ情報を運ぶのに使用できるキャリヤーグレード会計プロトコルを定義することであるなら、CRANE、Diameter、およびStreaming IPDRの1つはたぶん選択の候補です。
But since the goal is to standardize existing practice in the area of IP Flow Information Export, it makes sense to analyze why previous versions of NetFlow have been so widely implemented and used. The strong position of Cisco in the router market certainly played a major role, but we should not underestimate the value of having a simple and streamlined protocol that "does one thing and does it well". It has been extremely easy to write NetFlow collecting processes, as all the protocol demands from a collector is to sit there and receive data. This model is no longer adequate when one wants to support increased levels of reliability or dynamically changing semantics for data export. But NetFlow remains a simple protocol, mainly by leaving out issues of configuration/negotiation.
しかし、目標がIP Flow情報Exportの領域の既存の習慣を標準化することであるので、それはNetFlowの旧バージョンがそれほど広く実装されて、使用された理由を分析する意味になります。 ルータ市場のシスコの強い立場は確かに大きな役割を果たしましたが、私たちは「1つのことをして、上手にそれをする」簡単で流線型のプロトコルを持つ値を過小評価するべきではありません。 NetFlow収集にプロセスを書くのは非常に簡単です、プロトコルがコレクタから要求するすべてがそこに座って、データを受け取ることであるので。 人がデータ輸出のために増強されたレベルの信頼性かダイナミックに変化している意味論をサポートしたがっているとき、このモデルはもう適切ではありません。 しかし、NetFlowは、主に構成/交渉の問題を省くことによって、簡単なプロトコルのままで残っています。
So far, the biggest issue with NetFlow is that it could not resolve itself to mandate a reliable (and congestion-friendly) transport. This could easily be fixed, and bring with it some additional possibilities for simplifications. For example it would no longer be necessary to periodically retransmit Template FlowSets, and Option Data FlowSets could become a more versatile way of reporting meta- information about the metering and exporting processes either synchronously or asynchronously. Application-level acknowledgements - possibly as an option - would be a low-impact addition to improve overall reliability.
今までのところ、NetFlowの最も大きい問題は信頼できて(混雑に優しい)の輸送を強制するために自然に解決できなかったということです。 これは、容易に修理されていて、簡素化にそれと共にいくつかの追加可能性をもたらすかもしれません。 例えば、定期的にTemplate FlowSetsを再送するのはもう必要でないだろう、Option Data FlowSetsは計量とプロセスをエクスポートすることのメタ情報を同期か非同期に報告するより多能な方法になるかもしれません。 ことによるとオプションとしてのアプリケーションレベル承認は、総合的な信頼性を改良するためには低い影響追加でしょう。
Leinen Informational [Page 18] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[18ページ]のRFC3955評価
LFAP is also relatively focused on flow information export, but carries around too much baggage from its youth as the Lightweight Flow Admission Protocol. The bidirectional nature and large number of message types in the protocol are one symptom of this, the separation of flow information into FARs and FUNs - which must be matched at the collector - are another. Data encoding is less space-efficient than that of CRANE, NetFlow or IPDR, and will present a performance issue at high flow rates.
LFAPはまた、流れ情報輸出に比較的集中していますが、ライト級Flow Admissionプロトコルとして若者からあまりに多くの手荷物を持ち歩きます。 プロトコルの双方向の自然と多くのメッセージタイプが、この1回の兆候、FARsとFUNs(コレクタで合わせなければならない)への流れ情報の分離です--別です。 zデータの符号化は、それほどスペースCRANE、NetFlowまたはIPDRで効率的でなく、ハイフローレートで性能問題を提示するでしょう。
LFAP's indications of unaccounted data and its MIB are excellent features that would be very useful in many operational situations.
非説明されたデータとそのMIBに関するLFAPの指摘は多くの操作上の状況で非常に役に立つ素晴らしい特徴です。
5.1. Recommendation
5.1. 推薦
It is the opinion of the evaluation team that the goals of the IPFIX WG charter would best be served by starting with NetFlow v9, working on lacking mechanisms in the areas of transport, security, reliability, and redundant configurations, and doing so very carefully in order to retain as much simplicity as possible and to avoid overloading the protocol. By starting from the simplest protocol that meets a large percentage of the specific requirements, we can hope to arrive at a protocol that meets all requirements and still allows widespread and cost-effective implementation.
できるだけ多くの簡単さを保有して、プロトコルを積みすぎるのを避けるのは、欠いているメカニズムに取り組んで、輸送と、セキュリティと、信頼性と、冗長構成と、そうする領域でNetFlow v9から始まることによって非常に慎重にIPFIX WG特許の目標に役立つだろうというのが最も良いという評価チームに関する意見です。 決められた一定の要求の大きな割合を達成する最も簡単なプロトコルから始めることによって、私たちは、すべての必要条件を満たして、まだ広範囲の、そして、費用対効果に優れた実装を許容しているプロトコルに到着することを望むことができます。
As evaluated, NetFlow v9 doesn't specify any security mechanisms. The IPFIX protocol specification must specify how the security requirements in section 6.3.3 of [1] can be assured. The IPFIX specification must be specific about the choice of security- supporting protocol(s) and about all relevant issues such as security negotiation, protocol modes permitted, and key management.
評価されるように、NetFlow v9は少しのセキュリティー対策も指定しません。IPFIXプロトコル仕様はどう[1]のセキュリティ要件コネセクション6.3.3を保証できるかを指定しなければなりません。 IPFIX仕様はセキュリティがプロトコルをサポートすることの選択とセキュリティ交渉や、受入れられたプロトコルモードや、かぎ管理などのすべての当該の問題に関して特定であるに違いありません。
The other important requirement that isn't fulfilled by NetFlow v9 today is support for a congestion-aware protocol (see section 6.3.1 of [1]). So a mapping to a known congestion-friendly protocol such as TCP, or, as suggested in [16], (PR-)SCTP, is considered as another necessary step in the preparation of the IPFIX specification.
NetFlow v9が今日実現していないもう片方の重要な要件は混雑意識しているプロトコルのサポートです。([1])についてセクション6.3.1を見てください。 それで、TCP、または[16]に示されるときの(PR)SCTPなどの知られている混雑に優しいプロトコルへのマッピングはIPFIX仕様の準備における必要なもう1ステップであるとみなされます。
6. Security Considerations
6. セキュリティ問題
The security mechanisms of the candidate protocols were discussed in Section 4.10.3.
セクション4.10.3で候補プロトコルのセキュリティー対策について議論しました。
7. Acknowledgements
7. 承認
Many of the issues have been discussed with the other members of the IPFIX evaluation team: Juergen Quittek, Mark Fullmer, Ram Gopal, and Reinaldo Penno. Many participants on the ipfix mailing list provided valuable feedback, including Vamsidhar Valluri, Paul Calato, Tal
IPFIX評価チームの他のメンバーと問題の多くについて議論しました: ユルゲンQuittek(マークフルマー)はゴパル、およびレイナルド・ペンノに激突します。 ipfixメーリングリストの多くの関係者がVamsidhar Valluri、ポールCalatoを含んでいるタルを有益なフィードバックに提供しました。
Leinen Informational [Page 19] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[19ページ]のRFC3955評価
Givoly, Jeff Meyer, Robert Lowe, Benoit Claise, and Carter Bullard. Bert Wijnen, Steve Bellovin, Russ Housley, and Allison Mankin provided valuable feedback during AD and IESG review.
Givoly、ジェフ・マイヤー、Robert Lowe、ブノワClaise、およびカーター・ブラード。 バートWijnen、スティーブBellovin、ラスHousley、およびアリソン・マンキンはADとIESGレビューの間、有益なフィードバックを提供しました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export", RFC 3917,
October 2004.
2004年10月の[1]QuittekとJ.とZsebyとT.とClaise、B.とS.ザンダー、「IP流れ情報輸出のための要件」RFC3917。
[2] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version
9", RFC 3954, October 2004.
[2]がClaiseする、B.、エド、「シスコシステムズのNetFlowサービスはバージョン9インチ、RFC3954に2004年10月をエクスポートします」。
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[4] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[5] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[6] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
8.2. Informative References
8.2. 有益な参照
[7] Zhang, K. and E. Elkin, "XACCT's Common Reliable Accounting for
Network Element (CRANE) Protocol Specification Version 1.0",
RFC 3423, November 2002.
[7] チャンとK.とE.エルキン、ネットワーク要素(クレーン)のための「のXACCT一般的な信頼できる会計は仕様バージョン1インチについて議定書の中で述べます、RFC3423、2002インチ年11月。
[8] Zhang, K., "Evaluation of the CRANE Protocol Against IPFIX
Requirements", Work in Progress, September 2002.
[8] チャン、K.、「IPFIX要件に対するクレーンプロトコルの評価」、処理中の作業、2002年9月。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[9] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[10] Zander, S., "Evaluation of Diameter Protocol against IPFIX
Requirements", Work in Progress, September 2002.
[10] ザンダー、S.、「IPFIX要件に対する直径プロトコルの評価」、処理中の作業、2002年9月。
[11] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
Protocol Specification Version 5.0", July 2002.
[11]CalatoとP.とM.MacFaden、「5インチと、2002年7月にプロトコル仕様がバージョンであることを説明する軽量の流れ。」
Leinen Informational [Page 20] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[20ページ]のRFC3955評価
[12] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
Protocol Data Definition Specification Version 5.0", July 2002.
[12]CalatoとP.とM.MacFaden、「バージョン5インチと、2002年7月にプロトコルデータ定義が仕様であることを説明する軽量の流れ。」
[13] Calato, P., "Evaluation Of Protocol LFAP Against IPFIX
Requirements", Work in Progress, September 2002.
[13] P.、「IPFIX要件に対するプロトコルLFAPの評価」というCalatoは進歩、2002年9月に働いています。
[14] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
Protocol MIB", Work in Progress, September 2002.
[14] 「軽量の流れ会計プロトコルMIB」というCalato、P.、およびM.MacFadenは進歩、2002年9月に働いています。
[15] Claise, B., "Evaluation Of NetFlow Version 9 Against IPFIX
Requirements", Work in Progress, September 2002.
[15]はClaiseして、「IPFIX要件に対するNetFlowバージョン9の評価」というB.は進歩、2002年9月に働いています。
[16] Djernaes, M., "Cisco Systems NetFlow Services Export Version 9
Transport", Work in Progress, February 2003.
[16] M.、「シスコシステムズのNetFlowサービスはバージョン9輸送を輸出する」というDjernaesが進歩、2003年2月に働いています。
[17] Meyer, J., "Reliable Streaming Internet Protocol Detail
Records", Work in Progress, August 2002.
[17] マイヤー、J.、「信頼できるストリーミングのインターネットプロトコル明細レコード」が進歩、2002年8月に働いています。
[18] Meyer, J., "Evaluation Of Streaming IPDR Against IPFIX
Requirements", Work in Progress, September 2002.
[18] マイヤー、J.、「IPFIX要件に対するストリーミングのIPDRの評価」、処理中の作業、2002年9月。
[19] Internet Protocol Detail Record Organization, "Network Data
Management - Usage (NDM-U) For IP-Based Services Version 3.1",
April 2002. URL: http://www.ipdr.org/documents/NDM-U_3.1.pdf
[19] インターネットプロトコルの詳細は、組織を記録して、「3.1インチと、2002年4月にIPベースのサービスバージョンのために、データ管理--用法(NDM-U)をネットワークでつなぎます」。 URL: http://www.ipdr.org/documents/NDM-U_3.1.pdf
[20] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[20] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[21] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[22] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[22]RigneyとC.とウィレンスとS.とルーベン、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[23] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial
Reliability Extension", RFC 3758, May 2004.
[23] スチュワート、R.、Ramalho(M.、シェ、Q.、Tuexen、M.、およびP.コンラッド)は「制御伝動のプロトコルの(SCTP)部分的な信頼性の拡大を流します」、RFC3758、2004年5月。
[24] DeRose, S., Maler, E. and D. Orchard, "XML 1.0 Recommendation",
W3C FirstEdition REC-xml-19980210, February 1998.
[24]DeRoseとS.とMalerとE.とD.果樹園、「XML1.0推薦」、W3C FirstEdition REC-xml-19980210、1998年2月。
[25] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
[25]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
[26] <http://www.nmops.org/>
[26] <http://www.nmops.org/>。
[27] <http://www.ipdr.org/>
[27] <http://www.ipdr.org/>。
Leinen Informational [Page 21] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[21ページ]のRFC3955評価
Appendix A. A Note on References to the Candidate Protocol Documents
候補プロトコルの参照に関する注が記録する付録A.
At the time of the evaluation, the candidate protocol definitions, as well as their respective accompanying advocacy documents, were available as Internet-Drafts. As of the time of publication of this document, some of the protocols have been published as RFCs, others are still being revised as Internet-Drafts, and some will have expired. This document attempts to extract the relevant information from the individual protocol definitions and, in the context of the IPFIX requirements, provide a meaningful comparison between them.
評価時点で、候補プロトコル定義、およびそれらのそれぞれの付随の支持ドキュメントはインターネット草稿として利用可能でした。 このドキュメントの公表の時付けで、RFCs、他のものがインターネット草稿としてまだ改訂されていて、或るものが期限が切れてしまうだろうというとき、プロトコルのいくつかが発表されました。 このドキュメントは、個々のプロトコル定義から関連情報を抜粋して、IPFIX要件の文脈で重要な比較をそれらの間に提供するのを試みます。
Since this evaluation proposes to use NetFlow v9 as the basis for the IPFIX protocol, only the reference to this protocol is considered "normative", although strictly spoken, the present document doesn't define any protocol, and the selected protocol will have to be further refined to become the IPFIX protocol.
この評価が、IPFIXプロトコルの基礎としてNetFlow v9を使用するよう提案するので、このプロトコルの参照だけが「規範的である」と考えられます、厳密に話されます、現在のドキュメントはどんなプロトコルも定義しません、そして、選択されたプロトコルはIPFIXプロトコルになるようにさらに洗練されなければならないでしょうが。
In the interest of stable references, the bibliography points to RFCs where those have become available (for DIAMETER and CRANE). Other protocols are still available only as Internet-Drafts and may eventually expire. The LFAP drafts - which already have expired - are still available from the www.nmops.org Web site [26] (as well as other places). The IPDR documents are available on the IPDR Web site [27].
安定した参照のために、図書目録はものが利用可能に(DIAMETERとCRANEのための)なったRFCsを示します。 他のプロトコルは、単にインターネット草稿としてまだ利用可能であり、結局、期限が切れるかもしれません。 LFAP草稿はwww.nmops.orgウェブサイト[26](他の場所と同様に)からまだ利用可能です。(既に、草稿は期限が切れました)。 IPDRドキュメントはIPDRウェブサイト[27]で利用可能です。
Author's Address
作者のアドレス
Simon Leinen SWITCH Limmatquai 138 P.O. Box CH-8021 Zurich Switzerland
サイモンLeinenスイッチLimmatquai138私書箱CH-8021チューリッヒスイス
Phone: +41 1 268 1536 EMail: simon@switch.ch
以下に電話をしてください。 +41 1 268 1536はメールされます: simon@switch.ch
Leinen Informational [Page 22] RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
IPFIX2004年10月のための候補プロトコルのLeinen情報[22ページ]のRFC3955評価
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と、www.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Leinen Informational [Page 23]
Leinen情報です。[23ページ]
一覧
スポンサーリンク
