Re: [ipfix-arch] applicability document

[Robert Lowe <[e-mail]>]

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

> 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: [e-mail]
> Kaiserin-Augusta-Allee 31                               Phone: [phone]
> D-10589 Berlin, Germany                         Fax:   [phone]
> --------------------------------------------------------------------------------------
> "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
             ,    ^^^^^^^^^
                 relationship

> 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
 ^^                                                        ^^^
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

> 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

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.  ;-)

> 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.

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

> QoS monitoring is the passive observation of the
                                               ^^^ (unnecessary)
> transmission quality for single flows or traffic aggregates in the
> network. It is needed for instance for the validation of QoS

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

> guarantees in service level agreements. Some QoS metrics require the
> 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
             ,
> 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
            ^ (insert space)
> 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

(I second Carter -- meter should be clarified)

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

Parts of...

> transport header are used for the classification. Since a
> differentiation of flows in accordance to the transport header is one
                                         ^^ (with?)
> 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. 

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?

> 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
                                ^^^^^^^^
                                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)                           ,

> 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
                                                        ^ (insert space)
> 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
                         ^^^^^^^^^^ (delete)
> 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
                    ^^^^^^^^^^^^ (delete)
> present in higher layer protocols. This requires the capturing of the
> sequence numbers of subsequent packets of the observed flow at the
                                         ^^ (in?)
> 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
                                          ^^^^^^^^^^^^^^
                                           calculating
> differences.
> 
> 3.5.5.Sampling for QoS Monitoring
> 
> 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.

> 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. 

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
> error depends heavily on the used sampling strategy, the application
                               ^^^^                  ^
                              (delete)              in use
OR... deployed sampling strategy

> that receives the data needs to be aware of the sampling scheme and
> the used parameters. Therefore it is important that the IPFIX
      ^^^^
    (delete)         ^in use

> exporter informs the collector precisely about the used sampling
> 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?


> 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.
                                          ^^^^^^^^
                                            to

> 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
                                           ^ (singular)
> usage-based accounting measurement data from the network is needed to
> generate an accounting record. 

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

> 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: [e-mail]
> 
> Tanja Zseby
> Fraunhofer Institute for Open Communication Systems(FOKUS)
> Kaiserin-Augusta-Allee 31
> 10589 Berlin
> Germany
> Phone: [phone]
> Email: [e-mail]
> 
> 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.

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