Subject: [ipfix-arch] IPFIX Architecture writeup from Ram Gopal

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 06 Feb 2002 10:36:21 -0800

Hi Ram, Man Li,
   I have some comments on the arch spec portion that you sent out.
   The comments are inline between 2 "G:"s.
Thanks
Ganesh

   IPFIX working group                                      Ram Gopal 
   Internet Draft                                              Man Li 
   Expires July 2002                                            Nokia 

                                                        February 2002 

                            IPFIX Architecture 
                        draft-gopal-ipfix-arch.txt 

   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 defines architecture for scalable monitoring, 
   measuring and exporting IP flow information to collectors.   

   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 [2]. 

Gopal, Li                Expires January, 2002                       1 

                          IPFIX Architecture                July, 2001 

  1. Introduction 
    
   Many applications e.g., Intrusion detection, traffic engineering, 
   require the monitoring, measuring of IP traffic flows. It is hence 
   important to have a standard way of exporting information related 
   to IP flows. This document defines architecture for IP traffic 
   flow monitoring, measuring and exporting. It provides a high-level 
   description of the key components and their functions.  

  2. Scope  
       
   This document defines architecture for IPFIX[3]. Specifically, 
   this document  
    
   o Describes the key architectural components of IPFIX. 
    
   o Describes the  external dependency and identifies those 
   interfaces explicitly.  
    
   o Defines architectural requirements, e.g., Recovery, Security, 
   etc. 
    
   o Defines the required external interfaces to interoperate with 
   other protocol/architecture this may includes AAA or Diameter or 
   Intrusion Detection system. 
G:
I'm not sure what can be done in connection with AAA or
other protocol here?
G:
    
   o Identifies a minimal set of applications for IPFIX. 

 3. Architecture Overview 
 
Figure 1 shows the reference model for IPFIX. The blocks shown are 
logical entities. The functionalities of these components remain the 
same regardless of their placements inside a network.  
 
The main purpose of the IPFIX subsystems is to effectively 
communicate the information model using IPFIX. The information model 
is composed of set of attributes that are of interest to the 
applications. Each application may require a subset of the parameters 
specified in the information model. The information model is 
generalized and communicated between IPFIX endpoints as Templates for 
operational purpose. 

   Gopal, Li           Expires January, 2002                       2 

                          IPFIX Architecture                July, 2001 

                                  +------------+    +-------------+ 
                                  |Application |    | Application |            
                                  | (1)        | .  |    (n)      | 
                                  +------------+    +-------------+ 
                                        ||                  || 
                                        ======================  

                                                        || 
                                                        ||  
                                                        ||  
            +---------------+---------+                 ||       
            |               |         |                 ||  
            |   Exporter(1) |  IPFIX  |<=+              ||  
            |               |         |  ||             ||   
            +---------------+---------+  ||             ||    
                        .                ||             ||    
                        .                ||             ||  
            +---------------+---------+  ||   +-------+-----------+ 
            |               |         |  ||   |       |           | 
            |   Exporter(n) |  IPFIX  |<=====>| IPFIX | Collector | 
            |               |         |  ||   |       |           | 
            +---------------+---------+  ||   +-------+-----------+ 
                       ||                ||  

                       ||                || 
           +=====================+       ||   +-------+-------------+  
           ||                    ||      ||   |       |             | 
           ||                    ||      ====>| IPFIX | Collector   | 
      +------------+    +-------------+       |       |(Application)| 
      |Observation |    | Observation |       +-------+-------------+     
      | Point(1)   |..  | Point (n)   | 
      +------------+    +-------------+ 

             Figure 1: IPFIX architectural view 
 
G:
The diagram is confusing. 
Observation Point and exporter are 2 pieces of a single system and not
separate entities. 

G:
 
   3.1 Observation Point 
 
The observation point may be one or a set of interfaces through which 
the IP flows are monitored. The functions of an observation point 
include: 

 o Monitoring and filtering of IP Flows according to configured rules 
 o Forward either IP packets or requirement information to the 
Exporter 
 o In some cases, an observation point may perform metering as well. 

G:
Observation point is the place where metering is done. 
I did not understand why it is an option. Metering includes 
filtering also.
From http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt:

  4. Metering Process

     The following are requirements for the metering process. They
     describe the requirements for the process at the measurement
     instance. All measurements MUST be conducted from the point of view
     of the observation point.
     .....
G:
 
The interface between the Observation point and the Exporter is 
beyond the scope of IPFIX.  

   Gopal, Li           Expires January, 2002                       3 

                          IPFIX Architecture                July, 2001 

3.2 Exporter 
 
The exporter is a subsystem that interacts with one or more 
observation points.  The functions of an exporter include: 
 
o Performing Flow ID management that includes the creation of tags to 
refer a flow between Exporter and the Collector for configuration and 
statistical purpose. 
o Assembling collected information into the right format to be 
carried by the IPFIX protocol 
o Configuring observation points with flow monitoring rules 

G:
Configuring the observation point itself is not a strict functionality
of the exporter.But once some other subsystem has done the configuration,
the exporter needs to send the configuration to the collector.
G:

o Measuring, aggregating and exporting IP Flow information to the 
respective collectors. 
 
The information collected can be either pushed periodically to the 
collector or pulled by the collector on demand. 

3.3 IPFIX protocol 

IPFIX protocol may run on top of either Transport or IP layer. If the 
underlying network is not reliable, it is the responsibility of the 
IPFIX protocol to perform transport level functions. It is 
recommended to use reliable transport protocols like SCTP or TCP. 
The functions of IPFIX protocol include: 
 
o Reliably and securely transporting application level information 
between an exporter and a collector ( security functions are  
leveraged by using underlying security protocols) 

G:
If reliability is guarenteed by transport layer or network, this
is really not necessary. 
G:
 
o Maintaining the communication links between IPFIX endpoints. This 
includes detection of loss of connections and recovery processes. 

3.4 Collector 
 
Collector is a subsystem that interacts with one or more Exporters. 

The functions of the collector include: 
 
o Requesting an exporter sub-system to collect IP flows. 
G:
It is the exporter who decides what to
measure , where to measure & what to send. We are not defining
how to configure a metering process from a collector.
- the exporter configuration is out of the scope of this document
- the exporter configuration SHOULD be done out of band

G:

o Communicating with different applications.  
o Maintaining  a repository of IP flow statistics  
o Aggregating application level requests and form a template that 
will suitable for exporter. 
G:
This is out of scope for this doc. 
G:

The application(s) and the collector may be tightly coupled in one 
system. They may also be logically or physically a separate subsystem 
from the application(s). In which case, the communication between 
them is beyond the scope of IPFIX. 

   Gopal, Li           Expires January, 2002                       4 

                          IPFIX Architecture                July, 2001 

3.5 Applications 
 
IPFIX applications may be Billing, Network Surveillance, and 
Intrusion Detection sub-systems. etc.[3]. An application requests the 
Collector to gather the relevant IP Flow information.   

4. Some Applications of IPFIX  

G:
 This is already covered in the req. spec.Is there a necessity
 to repeat it here?
G:

This section describes the IPFIX applications that are identified in 
the requirement document[3]. These applications are not exhaustive. 

4.1 IPFIX usage in Intrusion Detection 
 
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. 
  
4.2 IPFIX usage in usage-based accounting 
 
Usage-based accounting typically includes monitoring of IP packets 
from a particular data source or user. This information is then used 
for billing purpose. Typically a usage-based application has details 
about the user service plans and the IP addresses being used by the 
user. The application may request an IPFIX collector to monitor the 
IP flows based on the service plan and the IP address of the user. 
The collector reports the IP flow statistics to the accounting 
application and it is the responsibility of the accounting 
application to correlate this statistics with a particular user in 
order to generate billing information. 
 
  4.3 IPFIX usage in Traffic Engineering/Traffic Profiling 
 
To better utilize the network, traffic engineering [5] is performed 
by the network administrator. IPFIX can monitor and report different 
flows. Using this information as a baseline, network administrators 
can  perform optimized network planning and engineering.   
 
 more to be written  

   Gopal, Li           Expires January, 2002                       5 

                          IPFIX Architecture                July, 2001 

5. Architectural Requirements 
 
   5.1 Recovery 
    
   5.2 Performance 
    
   5.3 Security 
 
Refer Security Consideration section for details 

6. Security Consideration 
    
   (a) Data Integrity and Authentication 
    
   As IPFIX is relying on underling transport protocol like TCP or 
   SCTP etc., IPFIX can leverage all the authentication and 
   encryption mechanism to the underlying protocol e.g. TLS or IPSec.    
     
   (b) End point Authentication 
    
   Since there may be more than one application interested in the 
   collected data.  IPFIX exporter may be able to authenticate each 
   collector on before exchanging of packets. This may be done by 
   having pre-established security associations between endpoints. 
G:
Yes. This can be achieved by using Authentication Header or
ESP and need not be built into the IPFIX framework.
G:
    
   (d) Resistance to attacks 
    
   As a general security measure, any new protocol should not 
   introduce possibilities of new attacks. IPFIX depends on the 
   transport layers for basic communications. Hence DoS attack 
   resistance and prevention is out of scope. 

8. References
 
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
    
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   3. J. Quittek ,et al., Requirements for IP Flow Information 
   Export , (work in progress) ,Internet Draft, Internet Engineering 
   Task Force, <draft-ietf-ipfix-reqs-00.txt>, November 2001 
     
   4. 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. 

   Gopal, Li           Expires January, 2002                       6 

                          IPFIX Architecture                July, 2001 

   5. 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  
 
9. Author's Addresses 
    
   Ram Gopal 
   Nokia  
   5 Wayside Road,  
   Burlington, MA 01803 
   Phone:+1 781 993 3685 
   Email: [email-masked] 

   Man Li  
   Nokia  
   5 Wayside Road,  
   Burlington, MA 01803  
   Phone: +1 781 993 3923  
   Email: [email-masked]  

   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. 

   Gopal, Li           Expires January, 2002                       7

---

From: <[email-masked]>
Date: Thu, 7 Feb 2002 16:23:21 -0500

Hello Ganesh,

>> >> (2)
>> >> The logical functionalities are described whether u have
>> >everything in one piece
>> >> or distributed it is upto the implementation.
>> >
>> >The point here is that IPFIX does not try to define the
>> >interface between
>> >observation point and exporter. Showing it as 2 pieces lets
>> >one think why
>> >the interface between these 2 should not be defined. Showing
>> >the way Kevin
>> >Zhang has shown for the exporter part looks cleaner to me.
>>
>> We are defining the IPFIX endpoint and the protocol 
>requirement for those endpoints.
>> Logically exporter and collector two different components, 
>even we had talk with Kevin
>> also and merged the document into one.  I think you view 
>from logical functional point rather
>> than physical view - No one wants to have  big monolithic piece.
>
>In the case of collector, you put 2 set of  boxes
>[collector + App]
>[collector] [App]
>
>If you go by the arg. above it should be
>
>[ obsv. 1..n, exporter]
>[obsv 1..] [exporter].

What we were conveyening is that different combications are possible. It is not forcing anything.
You observe the figure and read the respective functionality of those subsystem. 

>> >> Refer requirement document 1.1 IPFlow
>> >>
>> >>    The observation point may be a network interface of a 
>device or an
>> >>    entire router, a probe, or a middlebox with several interfaces.
>> >>    Properties derived from packet treatment include for 
>example the
>> >>    interface at which the packet arrived, the interface the
>> >packet will
>> >>    be forwarded to and potentially some other information.
>> >>
>> >> So observation point is just a probe , for example typically
>> >we may have more than
>> >> one interface through which we would like to monitor the packet.
>> >
>> >In the above example the Observation point (the probe) is an
>> >aggregation
>> >of interfaces. The metering is also done logically at the
>> >probe level which
>> >gets split up into the individual interfaces depending on the
>> >implementation.
>> >But the collector sees the observation point as the metering entity.
>> >I agree that metering process is not very clear in the req spec.
>>
>> It is your view how you view the collector. Any architecture 
>there will be a logical
>> division of functions, Collector may know where the 
>observation points, as far the collector
>> is concerned it is communicating to the exporter not to the 
>observation points.
>
>No, the point I wanted to convey is that observation point 
>should be the logical
>place where the measuring is done as seen by the collector.
>

Observation point is the point of observation it is logical. if you feel that observation point 
and the measurement is to be closely located fine and it is your view and that is why we have 
not defined any interface between Exporter and observation point. You think from generality and from
specific implementation. 

>> >> (5)
>> >> This may be one implementation, but generally exporter does
>> >metering, and reporting functions and
>> >> more detailed in the document.
>> >>
>> >> Regarding configuration, what is said is one implementation.
>> >But collector should be able to
>> >> request (Configure) and get the required Flow information.
>> >
>> >For this the collector needs to understand the  capability and
>> >to some extent the
>> >implementation of an exporter and this is a non-trivial
>> >problem to solve.
>>
>> It is your view, there is no problem in what we described, 
>based on the Flow you will get
>> the statistics or the data to the collector. I think want to 
>put everything in one piece.
>
>It is a bad idea. Exporter configuration should be out of 
>scope to the IPFIX.

I go by Kevin's argument, if you do configuration out-of-band ( as u mentioned earliar) no one stops
that - but is a common mechanism which people may adopt .

Regards
Ramg
��ޖ���[h�f���h���z�ݢ+��+��njwlk/�zZ��y��Ơy��I칻�&ޙ�����j:+v���w���"��"���v�vƲ��칻�&ފ�������,j��܀��b��m����*_�ݢ+��+��n��܆+�