Subject: [ipfix-arch] applicability document

From: Tanja Zseby <[email-masked]>
Date: Thu, 21 Feb 2002 19:38:57 +0100

Hi K.C. and Reinaldo,

attached you can find the first version of the applicability document as 
text file.

It includes the sections 8 and 10 from Reinaldo and me from the 
architecture draft. I also included the intrusion detection part 
(section 8.1) Who contributed this to the architecture ?

Regards
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: [email-masked]	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

Internet Draft					T.Zseby
draft-zseby-ipfix-applicability-00.txt		FhI FOKUS
Expires: August 2002				R. Penno
VERSION DATE February 21, 2002			Nortel Networks 
February 2002

			IPFIX Applicability

Status of this Memo

This document is an Internet-Draft and is in full conformance with 
all provisions of Section 10 of RFC2026 [1]. 

Internet-Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that 
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of 
six months and may be updated, replaced, or obsoleted by other 
documents at any time. It is inappropriate to use Internet- Drafts 
as reference material or to cite them other than as "work in 
progress." 

The list of current Internet-Drafts can be accessed at 
http://www.ietf.org/ietf/1id-abstracts.txt   
The list of Internet-Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html.

Abstract

This document describes how various applications can use the IP 
Flow Information Export (IPFIX) protocol. It furthermore shows how 
the IPFIX framework relates to other architectures and frameworks.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
this document are to be interpreted as described in RFC-2119 [ ].

1. INTRODUCTION	2
2. TERMINOLOGY	3
3. APPLICATIONS OF IPFIX	3
3.1. ACCOUNTING WITH IPFIX	3
3.2. TRAFFIC PROFILING WITH IPFIX	3
3.3. TRAFFIC ENGINEERING WITH IPFIX	3
3.4. INTRUSION DETECTION WITH IPFIX	3
3.5. QOS MONITORING WITH IPFIX	3
3.5.1. Measurement of Round-trip-time (RTT) with IPFIX	4
3.5.2. Measurement of One-way-delay (OWD) with IPFIX	4
3.5.3. Measurement of Loss with IPFIX	5
3.5.4. Measurement of delay variation with IPFIX	5
3.5.5. Sampling for QoS Monitoring	5
3.6. DEPLOYMENT OF SAMPLING METHODS IN IPFIX	5
4. RELATION OF IPFIX TO OTHER FRAMEWORKS AND PROTOCOLS	5
4.1. IPFIX AND AAA	6
4.1.1. Connecting via an AAA client	7
4.1.2. Connecting via an Application Specific Module (ASM) 7
4.2. IPFIX AND RTFM	8
4.3. IPFIX CONSIDERATIONS FOR MIDDLEBOXES	8
4.3.1. Firewall	8
4.3.2. Network Address Translation	9
4.3.3. Traffic Conditioners	11
4.3.4. Tunneling	12
4.3.5. VPNs	12
4.4. IPFIX AND RMON	14
4.5. IPFIX AND IPPM	14
4.6. IPFIX AND PSAMP	14
5. SECURITY CONSIDERATION	15
6. REFERENCES	15
7. ACKNOWLEDGEMENTS	16
8. AUTHOR'S ADDRESSES	16
9. FULL COPYRIGHT STATEMENT	17

1. Introduction

The IPFIX protocol defines how IP Flow information can be exported. 
It is intended to provide input for various applications. This 
document describes how applications can use the IPFIX protocol. 
Furthermore the relations of IPFIX to other frameworks and 
architectures are described.

2. Terminology
[maybe needed ]

3. Applications of IPFIX

3.1. Accounting with IPFIX 
[TODO for Tanja] 

3.2. Traffic Profiling with IPFIX 
 
[TODO]

3.3. Traffic Engineering with IPFIX 

[TODO]

3.4. Intrusion detection with IPFIX 
[TODO for Reinaldo ?]

Intrusion Detection System (IDS) monitors and controls the security 
incidents [4]. Typical IDS system includes components like Data 
source, Sensor, Analyzer and Management stations [4]. A Sensor 
monitors the data source and raises the alarm to the Analyzer. The 
analyzer collects various incident information and reports this to 
the management station.

With IPFIX, the event of interest can be exported either from 
collector or from exporter. For smooth integration, it will be better 
for the IDS system to integrate with the collector since the 
collector has all the aggregated information from different 
observation points. The IDS can request the collector to monitor the 
events or IP flow through an IPFIX template.
 
[Who contributed this text to the architecture doc ?]

3.5. QoS Monitoring with IPFIX 

The performance of QoS monitoring is one target application for using 
the IPFIX protocol. QoS monitoring is the passive observation of the 
transmission quality for single flows or traffic aggregates in the 
network. It is needed for instance for the validation of QoS 
guarantees in service level agreements. Some QoS metrics require the 
correlation of data from multiple measurement points. For this the 
clock of the involved exporting devices need to be synchronized. 
Furthermore such measurements would benefit from post-processing 
functions (e.g. packet ID generation) at the exporter and/or 
collector. This section describes how the monitoring of different 
metrics can be performed with IPFIX. The following metrics are 
considered: round trip time, one-way-delay, loss and delay variation.

3.5.1.Measurement of Round-trip-time (RTT) with IPFIX

The passive measurement of round-trip-times (RTT) can be performed by 
using packet pair matching techniques as described in [Brow00]. For 
the measurements, request/response packet pairs from protocols like 
DNS, ICMP,SNMP or TCP (syn/syn-ack, data/ack) are utilized to 
passively observe the RTT. As always for passive measurements this 
only works if the required traffic of interest is actually present in 
the network. In order to use this measurement technique, the IPFIX 
meter needs to measure both directions. A classification of the 
protocols mentioned above has to be done. That means parts of the 
transport header are used for the classification. Since a 
differentiation of flows in accordance to the transport header is one 
of the requirements for IPFIX, such classification can be performed 
without extensions. Nevertheless, the meter needs to recognize 
request and response packets for the given protocols and therefore 
needs to look further into the packet. This is not required for IPFIX 
but can be achieved by optional extensions to the classification 
process. The exporting device needs to assign a timestamp for the 
arrival of the packets. The calculation of the RTT can be done 
directly at the exporter or at the collector. In the first case IPFIX 
would transfer the calculated RTT to the collector. In the second 
case IPFIX needs to send the observed packet types and the timestamps 
to the collector.

3.5.2.Measurement of One-way-delay (OWD) with IPFIX

Passive one-way-delay measurements require the collection of data at 
two measurement points. It is required to recognize packets at the 
second measurement point in order to correlate packet arrival events 
from both points. This can be done for instance by capturing packet 
headers and parts of the packet and recognize packets based on this. 
In order to reduce the amount of measurement data a unique packet ID 
can be calculated from the header and part of the content e.g. by 
using a CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is 
not targeted at packet capturing these functionalities do not need to 
be supported by a standard IPFIX meter. Nevertheless, in some 
scenarios it might be sufficient to calculate a packet ID under 
consideration of header fields including datagram ID and maybe 
sequence numbers (from transport protocols) without looking at parts 
of the packet content. Especially if packet IDs need to be unique 
only for a certain time interval or a certain amount of packet ID 
collisions is tolerable this can be a solution. 

3.5.3.Measurement of Loss with IPFIX

Passive loss measurements for single flows can be performed at one 
measurement point for instance by using sequence numbers that are 
present in higher layer protocols. This requires the capturing of the 
sequence numbers of subsequent packets of the observed flow at the 
IPFIX meter. An alternative to this is to perform a two-point 
measurement as described above and just consider packets as lost that 
do not arrive at the second measurement point in a given maximum time 
frame. 

3.5.4.Measurement of delay variation with IPFIX

Delay variation is defined as the difference of one-way-delay values 
for selected packets.[DeCi01]. Therefore this metric can be 
calculated by performing passive measurement of one-way-delay for 
subsequent packets (e.g. of a flow) and then calculate the 
differences. 

3.5.5.Sampling for QoS Monitoring

Since QoS monitoring can lead to an overwhelming amount of 
measurement result data, it would  highly benefit from the deployment 
of mechanisms to reduce the measurement data, like aggregation of 
results and sampling. Sampling methods can be grouped according to 
the sampling strategy (systematic, random or stratified) and the 
trigger that starts a sampling interval (count-based, time-based or 
packet-content-based) [ClPB93]. Sampling can also be used as a method 
to dynamically reduce resource consumption if the meter is 
overloaded. Then the IPFIX meter can switch to a sampling method if 
too many packets have to be observed. Since the expected estimation 
error depends heavily on the used sampling strategy, the application 
that receives the data needs to be aware of the sampling scheme and 
the used parameters. Therefore it is important that the IPFIX 
exporter informs the collector precisely about the used sampling 
strategy. This is even more required if the IPFIX meter dynamically 
invokes sampling.

3.6. Deployment of Sampling Methods in IPFIX

[TODO for Tanja]

  [other applications ?] 

4. Relation of IPFIX to other frameworks and protocols 

4.1. IPFIX and AAA 

AAA defines a protocol and architecture for authentication, 
authorization and accounting for service usage. The DIAMETER protocol 
is used for AAA communication for network access services (Mobile IP, 
NASREQ, and ROAMOPS). The AAA architecture [XXX-RFC2903] provides a 
framework for extending the AAA support also for other services. 
DIAMETER defines the exchange of messages between AAA entities, e.g. 
between AAA clients at access devices and AAA servers and among AAA 
servers. It is used also for the transfers of accounting records. For 
usage-based accounting measurement data from the network is needed to 
generate an accounting record. IPFIX provides a protocol to export 
measurement data from the measurement point to the consumer of this 
data (like network management and accounting systems). The 
provisioning of accounting with IPFIX can be realized without an AAA 
infrastructure. The collector can directly forward the measurement 
information to an accounting application. Nevertheless, if an AAA 
infrastructure is in place, IPFIX can provide the input for the 
generation of accounting records and several features of the AAA 
architecture can be used. Features include the mapping of a user ID 
to the flow information (by using authentication information), the 
generation of DIAMETER accounting records and the secure exchange of 
accounting records between domains with DIAMETER. Three possibilities 
to connect IPFIX and AAA can be distinguished: 

4.1.1.Connecting via an AAA client

One possibility to connect IPFIX and AAA is to run an AAA client on 
the IPFIX collector. This client can generate DIAMETER accounting 
messages and send them to an AAA server. The mapping of the flow 
information to a user ID can be done in the AAA server by using 
data from the authentication process. DIAMETER accounting messages 
can be sent to the accounting application or to other AAA servers 
(e.g. in roaming scenarios).

       +---------+  DIAMETER    +---------+
       |  AAA-S  |------------->|  AAA-S  |
       +---------+              +---------+
            ^
            | DIAMETER
            |
            |
     +--+--------+--+
     |  |  AAA-C |  |
     +  +--------+  |
     |              |
     |  Collector   |
     +--------------+    
            ^
            | IPFIX
            |
      +------------+
      |  Exporter  |
      +------------+   

Figure 2: IPFIX collector connects to AAA server via AAA client 

4.1.2. Connecting via an Application Specific Module (ASM)

Another possibility is to directly connect the IPFIX collector with 
the AAA server via an application specific module (ASM). 
Application specific modules have been proposed by the IRTF AAA 
architecture research group (AAARCH) in [RFC2903]. They act as an 
interface between AAA server and service equipment. In this case 
the IPFIX collector is part of the ASM. The ASM acts as an 
interface between the IPFIX protocol and the input interface of the 
AAA server. The ASM translates the received IPFIX data into an 
appropriate format for the AAA server. The AAA server then can add 
information about the user ID and generate a DIAMETER accounting 
record. This accounting record can be sent to an accounting 
application or to other AAA serves. 

       +---------+  DIAMETER    +---------+
       |  AAA-S  |------------->|  AAA-S  |
       +---------+              +---------+
            ^
            |
    +------------------+
    |     ASM          |
    |  +------------+  |
    |  |  Collector |  |
    +------------------+
            ^
            | IPFIX
            |
      +------------+
      |  Exporter  |
      +------------+

Figure 3: IPFIX connects to AAA server via ASM

4.2. IPFIX and RTFM 
[TODO for Tanja] 

4.3. IPFIX Considerations for Middleboxes 

A Middlebox is a network intermediate device that implements one or 
more of the middlebox services. Policy based packet filtering (a.k.a. 
firewall), Network address translation (NAT), Intrusion detection, 
Load balancing, Policy based tunneling and IPsec security are all 
examples of a middlebox function (or service). [MCFW]. For instance, 
a NAT middlebox is a middlebox implementing NAT service and a 
firewall middlebox is a middlebox implementing firewall service. 

It is expected that the exporter in the IPFIX architecture will 
probably implement some form of middlebox service given its ubiquity 
today. Since some of these middlebox services might affect flow 
exportation and how the collector interprets them, there is a need to 
provide an analysis of these implications in relation to the IPFIX 
architecture and a set of recommendations. 

The following sections provide a non-exhaustive analysis of middlebox 
services, its implications on the IPFIX architecture and a 
corresponding set of recommendations.

4.3.1. Firewall

Firewall is a policy based packet filtering middlebox function, 
typically used for restricting access to/from specific devices and 
applications. The policies are often termed Access Control Lists 
(ACLs)[MCFW].  

The firewall middlebox service allows the exporter to explicitly drop 
packets based on some administrative policy. In this case, the 
exporter can take one of the following actions that will have a 
direct impact on the information provided by the collector to the 
user.

* Silently Discard

In this case the packet is discarded and no flow information record 
is sent to the collector.

* Discard and export flow

In this case the packet is discarded, and the flow information record 
is sent to the collector.

* Discard and export flow with discard notification

In this case the packet is discarded, and the flow information record 
is sent to the collector with an indication that the packet was 
discarded.

4.3.2. Network Address Translation

Network Address Translation is a method by which IP addresses are 
mapped from one address realm to another, providing transparent 
routing to end hosts. Transparent routing here refers to modifying 
end-node addresses en-route and maintaining state for these updates 
so that when a datagram leaves one realm and enters another, 
datagrams pertaining to a session are forwarded to the right end-host 
in either realm [NAT-TERM]. 

From an exporter (middlebox) perspective, a NAT is composed of two 
flows, one from the client to the NAT middlebox and another from the 
NAT middlebox to the destination. Based on this fact, the exporter 
has several modes of operation, i.e., it can export the private realm 
flow, the public realm, or both. This is further constrained by the 
flavor of NAT implemented, meaning that in order for the exported 
information to be useful for the collector, sometimes the associated 
flows on the two realms need to be exported in the same flow record. 

Although there are many flavors of address translation that lend 
themselves to different applications, this section will only address 
the IPFIX architecture implications of traditional NAT, bi-
directional NAT and twice NAT.

4.3.2.1. Traditional NAT

Traditional NAT would allow hosts within a private network to 
transparently access hosts in the external network, in most cases. In 
a traditional NAT, sessions are unidirectional, outbound from the 
private network. This is in contrast with bi-directional NAT, which 
permits sessions in both inbound and outbound directions. A detailed 
description of traditional NAT may be found in section [NAT-TERM].

If the exporter is providing traditional NAT service and only the 
private realm flow is exported, only destination based information 
can be inferred from the collector. The reason for this is twofold. 
First, the collector will not be able to find the reverse flow (when 
applicable) associated with a private realm flow record, and second 
is that in the more general scenario the collector can be connected 
to several exporters providing NAT service and there might be 
overlapping private realm addresses between the networks connected to 
these exporters.

In a traditional NAT scenario the exporter SHOULD export private and 
public realm information in the same flow record or provide the 
collector with a unique key to associate the two if exported on 
different flow records.

4.3.2.2. Bi-Directional NAT

With a bi-directional NAT, sessions can be initiated from hosts in 
the public network as well as the private network. Private network 
addresses are bound to globally unique addresses, statically or 
dynamically as connections are established in either direction.  
Detailed description of Bi-Directional may be found in section [NAT-
TERM].

4.3.2.3. Twice NAT

Twice NAT is a variation of NAT in that both the source and 
destination addresses are modified by NAT as a datagram crosses 
address realms. This is in contrast to Traditional-NAT and Bi-
Directional NAT, where only one of the addresses (either source or 
destination) is translated. Note, there is no such term as 'Once-
NAT'. Detailed description of Bi-Directional may be found in section 
[NAT-TERM].

In the case of twice NAT the exporter MUST export private and public 
realm information in the same flow record or provide the collector 
with a unique key to associate the two if exported on different flow 
records.

4.3.3. Traffic Conditioners
A traffic conditioner may contain the following elements: meter, 
marker, shaper, and dropper.  A traffic stream is selected by a 
classifier, which steers the packets to a logical instance of a 
traffic conditioner[DIFF-ARCH].

From an IPFIX architecture perspective we are going to address 
marking, shaping and dropping services.

4.3.3.1. Marking 
Diffserv packet markers set the DS field of a packet to a particular 
codepoint, adding the marked packet to a particular DS behavior 
aggregate.  The marker may be configured to mark all packets which 
are steered to it to a single codepoint, or may be configured to mark 
a packet to one of a set of codepoints used to select a PHB in a PHB 
group, according to the state of a meter.  When the marker changes 
the codepoint in a packet it is said to have "re-marked" the packet 
[DIFF-ARCH].

From and IPFIX architecture perspective, the exporter can take one of 
the following actions when it needs to remark a packet.

* Unmarked flow

The exporter can export the flow before it was remarked. This mode of 
operation is strongly discouraged.

* Remarked flow

The exporter can export the flow after it was remarked. 

* Unmarked and remarked flow.

The exporter can export the flow before and after it was remarked or 
export the flow before it was remarked and an indication of what was 
the DSCP after it was remarked. 

4.3.3.2. Shapers

Shapers delay some or all of the packets in a traffic stream in Order 
to bring the stream into compliance with a traffic profile.  A shaper 
usually has a finite-size buffer, and packets may be discarded if 
there is not sufficient buffer space to hold the delayed packets.

For an IPFIX perspective, since the discard of a packet by a shaper 
is not voluntary, no indication should be sent to the collector. 

4.3.3.3. Droppers

Droppers discard some or all of the packets in a traffic stream in 
order to bring the stream into compliance with a traffic profile. 
This process is known as "policing" the stream.  Note that a dropper 
can be implemented as a special case of a shaper by setting the 
shaper buffer size to zero (or a few) packets.

In a manner analogous to the middlebox firewall service, middlebox 
policing services also allow the exporter to explicitly drop packets 
based on some administrative policy. 

The three possible export behaviors described for the firewall 
service when a packet needs to be dropped are also applicable to 
here, i.e., silent discard, discard and export flow, discard and 
export flow with discard notification.

4.3.4. Tunneling

The exporter can export the flows before and/or after they get 
tunneled. In the later case the encapsulated flow information might 
not be available due to confidentiality precautions such as those 
used by IPsec, or due to the fact the exporter lacks the necessary 
intelligence to inspect the encapsulated packet. Moreover, depending 
on where in the network the exporter is located, it might only be 
able to export flows associated with the tunnel, without visibility 
into the encapsulated packet.

Apart from what was said above, it should also be factor in the fact 
that flows exported before they get tunneled, will provide 
information about the private network sites, but not necessarily 
about the backbone, since the route taken by the packet it's now know 
at that point in time (and vice-versa).

Tunnel terminates on exporter

Tunnel initiates on exporter

Exporter implements tunnel switching

4.3.5. VPNs

The term "Virtual Private Network" (VPN) refers to the communication 
between a set of sites, making use of a shared network 
infrastructure.  Multiple sites of a private network may therefore 
communicate via the public infrastructure, in order to facilitate the 
operation of the private network.  The logical structure of the VPN, 
such as addressing, topology, connectivity, reachability, and access 
control, is equivalent to part of or all of a conventional private 
network using private facilities [RFC2764] [VPN-2547BIS].

There are multiple flavors of VPNs, the one with more relevance to 
the IPFIX architecture is the PE-based-VPN. A PE-based VPN (or 
Provider Edge-based Virtual Private Network) is one in which PE 
devices in the SP network provide the VPN.  This allows the existence 
of the VPN to be hidden from the CE devices, which can operate as if 
part of a normal customer network. A detailed discussion of VPNs can 
be found in [PPVPN-FR].

4.3.5.1. Layer 3 PE-based VPN

A layer 3 PE-based VPN is one in which the SP takes part in IP level 
forwarding based on the customer network's IP address space.  In 
general, the customer network is likely to make use of private and/or 
non-unique IP addresses.  This implies that at least some devices in 
the provider network needs to understand the IP address space as used 
in the customer network.  Typically this knowledge is limited to the 
PE device [PPVPN-FR] which is directly attached to the customer.

In a layer 3 PE-based VPN the provider will need to participate in 
some aspects of management and provisioning of the VPNs, such as 
ensuring that the PE devices are configured to support the correct 
VPNs.  This implies that layer 3 PE-based VPNs are by definition 
provider provisioned VPNs [PPVPN-FR].

In order to connect the different VPN sites belonging to the same VPN 
the SP uses a tunneling technique such as MPLS, L2TP or IPsec. These 
tunnels originate and terminate on PE devices. 

One of the characteristics of a layer 3 PE-based VPNs is that they 
offload some aspects of VPN management from the customer network. 
From an IPFIX architecture perspective, this means that the SP is the 
one that potentially will be providing the IPFIX service for the VPNs 
that it provides connectivity.

The exporter in Layer 3 PE-based VPN can be located on the customer's 
network, on the SP's backbone (P Router) or on the edge (PE router). 
The premise of this discussion is that the exporter is the one 
providing middlebox services, so in the case of VPNs we assume that 
the exporter is located in a PE device. 

4.3.5.1.1. Tunneling

[TODO for Reinaldo ?]

4.3.5.1.2. Overlapping Address Realms

In the case the exporter plays the role of a PE router [VPN-2547BIS] 
in a provider provisioned VPN scenario and has VPNs with overlapping 
private address realms, it can only provide useful non-conflicting 
information to the provider for intra-VPN traffic if it uses a 
technique that allows the collector to uniquely identify to which VPN 
the flow belongs.

Several techniques could be used to accomplish this goal. One of 
these techniques is to include the VPN Global unique identifier [VPN-
ID] as one of the keys in the flow record. 

In the case the exporter supports VPNs with overlapping private 
address realms, it MUST include the VPN-ID [VPN-ID] in the exported 
flow record.

4.3.5.2. Layer 2 PE-based VPN [TBD]

A layer 2 PE-based VPN is one in which the network is aware of the 
VPN, but does only layer 2 forwarding and signaling.  This implies 
that the SP provisions and maintains layer 2 connectivity between CE 
devices [VPN-L2].

Forwarding options include MAC addresses (such as LAN emulation), use 
of point-to-point link layer connections (FR or ATM), multipoint-to-
point (using MPLS multipoint to point LSPs), and point-to-multipoint 
(e.g., ATM VCCs).

For a layer 2 PE-based VPN, the PE device may be a router, LSR, or IP 
switch.  From the CE's perspective, the PE will be operating as a 
switch.

4.4. IPFIX and RMON 
[TODO] 

4.5. IPFIX and IPPM 

[TODO for Tanja] 

4.6. IPFIX and PSAMP 

[TODO for Tanja ?] 

[further relations ?]

5. Security Consideration

[TODO]

6. References

[QuZC02] J. Quittek ,et. Al "Requirements for IP Flow Information 
Export ", (work in progress) ,Internet Draft, Internet Engineering 
Task Force, <draft-ietf-ipfix-reqs-01.txt>, February 2002

[Wood02]M. Wood ,et al.," Intrusion Detection Message Exchange 
Requirements",(work in progress), Internet Draft, Internet 
Engineering Task Force, draft-ietf-idwg-requirements-06,February 
2002.

[Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of 
Internet Traffic Engineering", (work in progress), Internet Draft, 
Internet Engineering Task Force, draft-ietf-tewg-principles-02.txt, 
May 2002 

[Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, 
http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-
adelaide/pp-dist/

[DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric 
for IPPM, <draft-ietf-ippm-ipdv-08.txt>, November   2001

[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss 
Metric for IPPM, September 1999

[ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: 
Application of Sampling Methodologies to Network Traffic 
Characterization, Proceedings of ACM SIGCOMM'93, 
San Francisco, CA, USA,  September 13 - 17, 1993

[GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed 
MARTENS, John G. CLEARY: 
Nonintrusive and Accurate Measurement of Unidirectional Delay and 
Delay Variation on the Internet, INET'98, Geneva, Switzerland,  
21-24 July, 1998

[DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling 
for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, 
Stockholm, Sweden, August 28 - September 1, 2000.

[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay 
Metric for IPPM, Request for Comments: 2679, September 1999  

[ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation 
of Building Blocks 
for Passive One-way-delay Measurements, Proceedings of Passive and 
Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, 
April 23-24, 2001 

[MCFW] Srisuresh, S. et al.  "Middlebox Communication Architecture 
and framework," work in progress.  October 2001.

[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 
Translator (NAT) Terminology and Considerations", RFC 2663, August 
1999.

[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network  
Address Translator (Traditional NAT)", RFC 3022, January  2001.

[PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider 
Provisioned Virtual Private Networks ", work in progress, <draft-
ietf-ppvpn-framework-03.txt>, January 2002. 

[VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft 
<draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.

[RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and 
W. Weiss, "An Architecture for Differentiated Services", RFC 2475, 
December 1998.

7. Acknowledgements

8. Author's Addresses

Reinaldo Penno
Nortel Networks, Inc. 
2305 Mission College Boulevard
Building SC9-B1240  
Santa Clara, CA 95134
Email: [email-masked] 

Tanja Zseby
Fraunhofer Institute for Open Communication Systems(FOKUS)  
Kaiserin-Augusta-Allee 31  
10589 Berlin  
Germany  
Phone: +49 30 3463 7153  
Email: [email-masked]

9. Full Copyright Statement

"Copyright (C) The Internet Society (date). All Rights Reserved. 
This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain 
it or assist in its implementation may be prepared, copied, 
published and distributed, in whole or in part, without restriction 
of any kind, provided that the above copyright notice and this 
paragraph are included on all such copies and derivative works. 
However, this document itself may not be modified in any way, such 
as by removing the copyright notice or references to the Internet 
Society or other Internet organizations, except as needed for the 
purpose of developing Internet standards in which case the 
procedures for copyrights defined in the Internet Standards process 
must be followed, or as required to translate it into.

---

From: Robert Lowe <[email-masked]>
Date: Thu, 21 Feb 2002 17:14:57 -0600

Tanja Zseby wrote:

Hi Tanja!

See inline comments... Mostly English stuff -- somewhere where I can rise slightly
above useless in this whole process.  :-)

-Robert

P.S. I ran out of time to go through everything now... I'll try to add more
comments later, beginning with section 4.1.1

>   ------------------------------------------------------------------------------------------
> Internet Draft                                  T.Zseby
             ,    ^^^^^^^^^
                 relationship

> Intrusion Detection System (IDS) monitors and controls the security
 ^^                                                        ^^^
insert 'An' or modify the subject/verbs
drop 'the'

> incidents [4]. Typical IDS system includes components like Data
                 ^^^^^^^
A typical...

> source, Sensor, Analyzer and Management stations [4]. A Sensor

I don't know what common practice is in these documents, but unless
it is accompanied by an acronym, I would change these nouns to 
lowercase (and any others throughout).

> monitors the data source and raises the alarm to the Analyzer. The
                                      ^^^
                                       an

> collector or from exporter. For smooth integration, it will be better

I'd change this to... "from either the collector or the exporter."

> for the IDS system to integrate with the collector since the
                                                    ,

One of the editors can improve the "flow" by not using integration
and integrate in the same sentence.  ;-)

> the IPFIX protocol.

This whole section is about "target applications", so I would drop
this sentence altogether.

> QoS monitoring is the passive observation of the
                                               ^^^ (unnecessary)
> network. It is needed for instance for the validation of QoS

One example of its usefulness is for the validation...

> correlation of data from multiple measurement points. For this the

this=accurate correlation?

> clock of the involved exporting devices need to be synchronized.
                              (the clock) needs
> Furthermore such measurements would benefit from post-processing
             ,
> DNS, ICMP,SNMP or TCP (syn/syn-ack, data/ack) are utilized to
            ^ (insert space)
> passively observe the RTT. As always for passive measurements this
                                      ,
> meter needs to measure both directions. A classification of the

(I second Carter -- meter should be clarified)

> protocols mentioned above has to be done. That means parts of the

Parts of...

> differentiation of flows in accordance to the transport header is one
                                         ^^ (with?)
> needs to look further into the packet. 

IMHO, "therefore needs to" is unnecessary.  The final "packet"
needs to be plural, correct? Otherwise, specifically mention one of 
the packets (request or response).

> This is not required for IPFIX

"This" is ambiguous.  Do you mean measurement of the RTT is not a
required component of any given IPFIX implementation?

> directly at the exporter or at the collector. In the first case IPFIX
                                                                 ,
> two measurement points. It is required to recognize packets at the
                                ^^^^^^^^
                                necessary

> second measurement point in order to correlate packet arrival events
                           ^^^^^^^^^^^
                               to

> from both points. This can be done for instance by capturing packet
                                     ^^^^^^^^^^^^
unnecessary -- implied by "can be".

> headers and parts of the packet and recognize packets based on this.
                             1    2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1. Should agree with packet headers -- both singular, or both plural.
   E.g., This can be done by capturing the packet header and parts of
   the packet...

2. ...that can be used to recognize the same packet at the subsequent
   measurement point.

> In order to reduce the amount of measurement data a unique packet ID
  ^^^^^^^^ (unnecessary)                           ,

> using a CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is
                                                        ^ (insert space)
> of the packet content. Especially if packet IDs need to be unique
                         ^^^^^^^^^^ (delete)
> collisions is tolerable this can be a solution.
                         ,
> measurement point for instance by using sequence numbers that are
                    ^^^^^^^^^^^^ (delete)
> sequence numbers of subsequent packets of the observed flow at the
                                         ^^ (in?)
> subsequent packets (e.g. of a flow) and then calculate the
                                          ^^^^^^^^^^^^^^
                                           calculating
> Since QoS monitoring can lead to an overwhelming amount of
                           ^^^^^^^
                           produce
> measurement result data, it would  highly benefit from the deployment
              ^^1^^^       ^^^^^^^^^2^^^^^^...
1. delete this word
2. ...methods such as aggregation of results, and sampling would 
   greatly increase the efficiency of the collection and analysis process.

> overloaded. 

> Then the IPFIX meter can switch to a sampling method if
> too many packets have to be observed. 

Given the bursty nature of IP traffic, is this an appropriate
strategy???  We had a similar discussion relating to fall-back
strategies when an exporter is under heavy load and came to the
conclusion that this was not worth pursuing.

> Since the expected estimation
                               ^^^^                  ^
                              (delete)              in use
OR... deployed sampling strategy

> the used parameters. Therefore it is important that the IPFIX
      ^^^^
    (delete)         ^in use

> strategy. 

Eliminate this sentence... implied from the previous?  At the very
least, re-word it!

> This is even more required if the IPFIX meter dynamically
          ^^^^^^^^^^^^^^^^^^
No "Versteigerung" possible.  Required is like "dead" -- if you
are, you can't become more dead.  :)

> invokes sampling.
  ^^^^^^^
  or adjusts?

> framework for extending the AAA support also for other services.
                                          ^^^^^^^^
                                            to

> servers. It is used also for the transfers of accounting records. For
                                           ^ (singular)
> generate an accounting record. 

Don't understand this sentence... for (something to happen), (something
else) is needed.

> IPFIX provides a protocol to export
                                  ,

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/