From majordomo@mil.doit.wisc.edu Tue Jun 4 21:49:25 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21985 for ; Tue, 4 Jun 2002 21:49:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FPDc-0005qj-00 for ipfix-list@mil.doit.wisc.edu; Tue, 04 Jun 2002 20:04:08 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17FPDZ-0005q6-00 for ipfix-arch@net.doit.wisc.edu; Tue, 04 Jun 2002 20:04:05 -0500 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.69.25.141]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5513ZPI019219 for ; Tue, 4 Jun 2002 18:03:35 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-26.cisco.com [171.71.137.26]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA21675 for ; Tue, 4 Jun 2002 18:03:34 -0700 (PDT) Message-ID: <3CFD6366.28875A77@cisco.com> Date: Tue, 04 Jun 2002 18:03:34 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Terminology - Control & Data Stream Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello, I was going through the thread on "Control Stream" and "Data Stream" which was discussed about 2 months ago. These are the following suggestions that I see: For defining Control stream, use: * Control Information (Kevin) * Operation stream or operational message (Robert Lowe) * Keep it as Control Stream (Paul, Ganesh) For Data Stream, use: * Flow information (Kevin) * Flow message (? Robert Lowe) * Keep it as Data Stream (Ganesh) Is there any other suggestion or which is the most favoured defintion? Thanks Ganesh -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 4 21:49:39 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21997 for ; Tue, 4 Jun 2002 21:49:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FPDg-0005qw-00 for ipfix-list@mil.doit.wisc.edu; Tue, 04 Jun 2002 20:04:12 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17FPDf-0005qD-00 for ipfix@net.doit.wisc.edu; Tue, 04 Jun 2002 20:04:11 -0500 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.69.25.141]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5513ePI019281; Tue, 4 Jun 2002 18:03:40 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-26.cisco.com [171.71.137.26]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA21681; Tue, 4 Jun 2002 18:03:40 -0700 (PDT) Message-ID: <3CFD636B.30F7843D@cisco.com> Date: Tue, 04 Jun 2002 18:03:40 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft References: <7B802811BE77D51189910002A55CFD2C027BC00D@zsc3c032.us.nortel.com> Content-Type: multipart/alternative; boundary="------------4A5AEA5CFB74174A1ABA52E6" Precedence: bulk Sender: majordomo listserver --------------4A5AEA5CFB74174A1ABA52E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Reinaldo, Reinaldo Penno wrote: > > > Here it goes my comments. Sorry if some of them were already > mentioned, but I finally found time to read through this. > > General: > > My main problem with this draft as it stands today is that it has a > lot of fat that comes from dwelling in certain areas that I do not > think it believes in an architecture document. For example, section > 4.4.2 and 4.4.3 and the whole notion of match and filter functions is > totally an implementation decision that has nothing to do with the > ipfix protocol we will select or the definition of a flow (or should > not have). What is the implementation (or design) specific details you are referring to? These are just 2 broad catgories of flow collection (.i.e field dependent and field independent ways). Regarding IPFIX protocol itself, it is a separate set of sections. This is just another piece in the general architecture. > > > The definition of a flow should stick to what is proposed in the > beggining of section 3. If I'm going to use the "mother of all rule > sets", do it in a stepwise manner (using match or filter functions), > or use complex logical constructs has nothing to do with the > architecture. These examples are used to illustrate the breadth of coverage of the defintion and has been found useful to many other people others in this mailing list to undrestand the flow definition. > > > Other comments: > > Section 3 - Typo - Phrase is repeated twice > > "Each property is defined as the result of applying a function to the > values of. > Each property is defined as the result of applying a function to the > values of:" Ok. > > > Section 3 - Wording > > "Each of the fields from 1., 2. > and 3. are referred to as flow keys." > > Not sure what are these fields you are talking about...Are them the > above mentioned list in the text? Yes. How does this look: "Each of the fields from 1., 2. and 3. mentioned above are referred to as flow keys" > > > Section 3 - Wording > > "Though a flow could match a > general application-level end-to-end stream, its definition is > not restricted to this alone. The above definition covers a > broad > range from a flow containing all packets observed on a set of > observation points to a flow consisting of just a single packet > > between two applications with a specific sequence number > observed > at a single observation point." > > I think we just remove this whole text without loss of generality or > meaning. It seems to me it is repetitive based on the fact that this > is already clear given the "flow keys" (1,2 and 3). Yes. I had the same opinion. But again it is for the clarification for many who mistook the scope of the definition to be restricted to application-to-application. > > > Section 3. - Document structure. > > Not sure about putting flow examples in a terminology section...The > examples use several terms that are only defined later in the text. I > suggest move tall the examples to a new section somewhere after the > terminology. This general feedback is that these examples improve the clarity of the definition. > > > Section 3 - Clarification on the match/filter functions on the > examples > > IMO this "match/filter" function mentioned in example 2 does not > belong in a architecture draft. This is an implementation internal > decision. IMO the only think the architecture document should say is > that Already explained above. > > > Section 3 - Typo > > "Each of the field which belongs to" > > s/field/fields Changed to "Each of the fields which belong to" > > > Section 3 - Terminology > > " * Flow Type: > A function F which would take input as a set of flow keys and > the > output would be one or more flows depending on the combination > of > values for the set of flow keys." > > A set of "common properties", which the real world instantion would be > the so-called fields already defines a flow. As mentioned in the > beggining of secion 3 > > "All packets belonging to > a particular flow have a set of common properties" > > So, the notion of flow type seems redundant. If its purposes in life > is to justify the other text in the draft which talks about > match/filter, is one more reason to remove this definition. I think I responded on this topic sometime back too. Flow Type defines a class of flows. If F(a,b) is the flow type applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or 3 different flows depending on what F does. Where is this useful? This is kind of information is required by the collecting side if it needs to understand fully what is being done on the exporter side. > > > Section 4 - Clarification > > In general I think dwelling in the internal of a device in a IETF > architecture document is not a good practice, but that's MHO. At least > in the "typical ipfix device" picture the functional boxes of the > "selection criteria for flow export" and "metering process" should be > removed. It is not a process that talks to external entities (a.k.a > IETF Ipfix's protocol) and neither has anything to do with defining a > flow. > > Anyway, my opinion is that we only need the first picture in section > 4. Everything else is perfectly described in the text (section 4.1 > onwards). In my opinion with the picture the explanation looks much clearer. > > > Section 4.3 - Wording > > "The typical functions of > an Observation Domain may include:" > > and then > > " * May perform appropriate middle-box functions to translate the > flow information." > > There is already a "may" on the first phrase Ok. > > > Section 4.4.1 - Typo > > " MAY need the > following interpreting the flow records further:" > > suggestion > > "May need the following information to interpret the flow records > further" Ok > > > > Section 4.4.2. - Remove > > IMO this section has no bearing in a architecture draft. It is > completely an implementation decision that not even affect the IPfix > protocol per se. explained above > > > Section 4.4.3. - Remove > > IMO this section has no bearing in a architecture draft. It is > completely an implementation decision that not even affect the IPfix > protocol per se. explained above > > > Section 5.2.1 - Conflicting terms > > " As mentioned in the selection criteria, the control and data > stream > MUST be transported over a congestion-aware transport protocol" Ok. How about changing this to "SHOULD". > > > In the selection criteria, ability to use a congestion-aware protocol > is a SHOULD. Quote follows from section 5.1: > > " The following is the list of criteria that the candidate protocol > SHOULD meet in order to be the..." > > > Section 5.2.1 - Redundancy and possible conflict of terms > > " The data stream MAY be exported over an reliable or unreliable > transport protocol." Reliability & congestion awareness are 2 different aspects. Thanks Ganesh > > > In section 5.1 congestion-aware is SHOULD, later is MUST and now > (section 5.2.1) is MAY. I suggest removing this phrase. Everything > related to which protocol must be used as a transport is already > discussed on the beggining of this section. > > regards, > > Reinaldo > > > > --------------4A5AEA5CFB74174A1ABA52E6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Reinaldo,

Reinaldo Penno wrote:

 

Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this.

General:

My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have).

What is the  implementation (or design) specific details you are referring to?
These are just 2 broad catgories of flow collection (.i.e field dependent and field
independent ways). Regarding IPFIX protocol itself, it is a separate set of sections.
This is just another piece in the general architecture.
 
 

The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture.

These examples are used to illustrate the breadth of coverage of the defintion
and has been found useful to many other people others in this mailing list to
undrestand the flow definition.
 

Other comments:

Section 3 - Typo - Phrase is repeated twice

"Each property is defined as the result of applying a function to the values of.
Each property is defined as the result of applying a function to the values of:"

Ok.
 

Section 3 - Wording

"Each of the fields from 1., 2.
       and 3. are referred to as flow keys."

Not sure what are these fields you are talking about...Are them the above mentioned list in the text?

Yes.  How does this look:  "Each of the fields from 1.,
2. and 3. mentioned above are referred to as flow keys"
 

Section 3 - Wording

"Though a flow could match a
       general application-level end-to-end stream, its definition is
       not restricted to this alone. The above definition covers a broad
       range from a flow containing all packets observed on a set of
       observation points to a flow consisting of just a single packet
       between two applications with a specific sequence number observed
       at a single observation point."

I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3).

Yes. I had the same opinion. But again it is for the clarification for many
who mistook the scope of the definition to be restricted to
application-to-application.
 

Section 3. - Document structure.

Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology.

This general feedback is that these examples improve the clarity of the
definition.
 

Section 3 - Clarification on the match/filter functions on the examples

IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that

Already explained above.
 

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

Changed to "Each of the fields which belong to"
 

Section 3 - Terminology

"   * Flow Type:
       A function F which would take input as a set of flow keys and the
       output would be one or more flows depending on the combination of
       values for the set of flow keys."

A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3

"All packets belonging to
       a particular flow have a set of common properties"

So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition.

I think I responded on this topic sometime back too.
Flow Type defines a class of flows. If F(a,b) is the flow type
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or
3 different flows depending on what F does. Where is this
useful? This is kind of information is required by the collecting
side if it needs to understand fully what is being done on the
exporter side.
 
 

Section 4 - Clarification

In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed.  It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow.

Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards).

In my opinion with the picture the explanation looks much clearer.
 

Section 4.3 - Wording

"The typical functions of
   an Observation Domain may include:"

and then

"    * May perform appropriate middle-box functions to translate the
       flow information."

There is already a "may" on the first phrase

Ok.
 

Section 4.4.1 - Typo

" MAY need the
   following interpreting the flow records further:"

suggestion

"May need the following information to interpret the flow records further"

Ok
 
 

Section 4.4.2. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 4.4.3. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 5.2.1 - Conflicting terms

"   As mentioned in the selection criteria, the control and data stream
   MUST be transported over a congestion-aware transport protocol"

Ok. How about changing this to "SHOULD".
 

In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1:

"   The following is the list of criteria that the candidate protocol
   SHOULD meet in order to be the..."

 

Section 5.2.1 - Redundancy and possible conflict of terms

"   The data stream MAY be exported over an reliable or unreliable
   transport protocol."

Reliability & congestion awareness are 2 different aspects.

Thanks
Ganesh

 

In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section.

regards,

Reinaldo
 
 
 
 

--------------4A5AEA5CFB74174A1ABA52E6-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 4 22:41:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23068 for ; Tue, 4 Jun 2002 22:41:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FQD6-0007G0-00 for ipfix-list@mil.doit.wisc.edu; Tue, 04 Jun 2002 21:07:40 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17FQD2-0007Fh-00 for ipfix@net.doit.wisc.edu; Tue, 04 Jun 2002 21:07:36 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5526v905324; Tue, 4 Jun 2002 19:06:57 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 19:06:55 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C02A1A07F@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: RE: [ipfix] Comments on IPFIX-architecture draft Date: Tue, 4 Jun 2002 19:06:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20C35.A22E3A36" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20C35.A22E3A36 Content-Type: text/plain Hello Ganesh, I disagree with your statement about the examples. If people need examples to understnad the definition of a flow, then is because the definition is not clear. Instead of attacking the root cause of the problem you are putting "paches" around it which makes the drafts full of fat. I would be very, very surprised if this architecture draft pass last call with all the implementation specific details it has justified under the "readability" umbrella. I've never seen an IETF architecture draft saying how many process I should code to realize some task, what they should do, etc, etc, I understand that some people get attached to their drafts but if you rip those sessions of and read the draft again you will see that nothing is lost, and is much more objective and charter compliant. regards, Reinaldo -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Tuesday, June 04, 2002 6:04 PM To: Penno, Reinaldo [SC101:T327:EXCH] Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft Hello Reinaldo, Reinaldo Penno wrote: Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this. General: My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have). What is the implementation (or design) specific details you are referring to? These are just 2 broad catgories of flow collection (.i.e field dependent and field independent ways). Regarding IPFIX protocol itself, it is a separate set of sections. This is just another piece in the general architecture. The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture. These examples are used to illustrate the breadth of coverage of the defintion and has been found useful to many other people others in this mailing list to undrestand the flow definition. Other comments: Section 3 - Typo - Phrase is repeated twice "Each property is defined as the result of applying a function to the values of. Each property is defined as the result of applying a function to the values of:" Ok. Section 3 - Wording "Each of the fields from 1., 2. and 3. are referred to as flow keys." Not sure what are these fields you are talking about...Are them the above mentioned list in the text? Yes. How does this look: "Each of the fields from 1., 2. and 3. mentioned above are referred to as flow keys" Section 3 - Wording "Though a flow could match a general application-level end-to-end stream, its definition is not restricted to this alone. The above definition covers a broad range from a flow containing all packets observed on a set of observation points to a flow consisting of just a single packet between two applications with a specific sequence number observed at a single observation point." I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3). Yes. I had the same opinion. But again it is for the clarification for many who mistook the scope of the definition to be restricted to application-to-application. Section 3. - Document structure. Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology. This general feedback is that these examples improve the clarity of the definition. Section 3 - Clarification on the match/filter functions on the examples IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that Already explained above. Section 3 - Typo "Each of the field which belongs to" s/field/fields Changed to "Each of the fields which belong to" Section 3 - Terminology " * Flow Type: A function F which would take input as a set of flow keys and the output would be one or more flows depending on the combination of values for the set of flow keys." A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3 "All packets belonging to a particular flow have a set of common properties" So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition. I think I responded on this topic sometime back too. Flow Type defines a class of flows. If F(a,b) is the flow type applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or 3 different flows depending on what F does. Where is this useful? This is kind of information is required by the collecting side if it needs to understand fully what is being done on the exporter side. Section 4 - Clarification In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed. It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow. Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards). In my opinion with the picture the explanation looks much clearer. Section 4.3 - Wording "The typical functions of an Observation Domain may include:" and then " * May perform appropriate middle-box functions to translate the flow information." There is already a "may" on the first phrase Ok. Section 4.4.1 - Typo " MAY need the following interpreting the flow records further:" suggestion "May need the following information to interpret the flow records further" Ok Section 4.4.2. - Remove IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se. explained above Section 4.4.3. - Remove IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se. explained above Section 5.2.1 - Conflicting terms " As mentioned in the selection criteria, the control and data stream MUST be transported over a congestion-aware transport protocol" Ok. How about changing this to "SHOULD". In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1: " The following is the list of criteria that the candidate protocol SHOULD meet in order to be the..." Section 5.2.1 - Redundancy and possible conflict of terms " The data stream MAY be exported over an reliable or unreliable transport protocol." Reliability & congestion awareness are 2 different aspects. Thanks Ganesh In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section. regards, Reinaldo ------_=_NextPart_001_01C20C35.A22E3A36 Content-Type: text/html
Hello Ganesh,
 
I disagree with your statement about the examples. If people need examples to understnad the definition of a flow, then is because the definition is not clear. Instead of attacking the root cause of the problem  you are putting "paches" around it which makes the drafts full of fat.
 
I would be very, very surprised if this architecture draft pass last call with all the implementation specific details it has justified under the "readability" umbrella. I've never seen an IETF architecture draft saying how many process I should code to realize some task, what they should do, etc, etc,
 
I understand that some people get attached to their drafts but if you rip those sessions of and read the draft again you will see that nothing is lost, and is much more objective and charter compliant.
 
regards,
 
Reinaldo
 
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 6:04 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: [ipfix] Comments on IPFIX-architecture draft

Hello Reinaldo,

Reinaldo Penno wrote:

 

Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this.

General:

My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have).

What is the  implementation (or design) specific details you are referring to?
These are just 2 broad catgories of flow collection (.i.e field dependent and field
independent ways). Regarding IPFIX protocol itself, it is a separate set of sections.
This is just another piece in the general architecture.
 
 

The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture.

These examples are used to illustrate the breadth of coverage of the defintion
and has been found useful to many other people others in this mailing list to
undrestand the flow definition.
 

Other comments:

Section 3 - Typo - Phrase is repeated twice

"Each property is defined as the result of applying a function to the values of.
Each property is defined as the result of applying a function to the values of:"

Ok.
 

Section 3 - Wording

"Each of the fields from 1., 2.
       and 3. are referred to as flow keys."

Not sure what are these fields you are talking about...Are them the above mentioned list in the text?

Yes.  How does this look:  "Each of the fields from 1.,
2. and 3. mentioned above are referred to as flow keys"
 

Section 3 - Wording

"Though a flow could match a
       general application-level end-to-end stream, its definition is
       not restricted to this alone. The above definition covers a broad
       range from a flow containing all packets observed on a set of
       observation points to a flow consisting of just a single packet
       between two applications with a specific sequence number observed
       at a single observation point."

I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3).

Yes. I had the same opinion. But again it is for the clarification for many
who mistook the scope of the definition to be restricted to
application-to-application.
 

Section 3. - Document structure.

Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology.

This general feedback is that these examples improve the clarity of the
definition.
 

Section 3 - Clarification on the match/filter functions on the examples

IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that

Already explained above.
 

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

Changed to "Each of the fields which belong to"
 

Section 3 - Terminology

"   * Flow Type:
       A function F which would take input as a set of flow keys and the
       output would be one or more flows depending on the combination of
       values for the set of flow keys."

A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3

"All packets belonging to
       a particular flow have a set of common properties"

So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition.

I think I responded on this topic sometime back too.
Flow Type defines a class of flows. If F(a,b) is the flow type
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or
3 different flows depending on what F does. Where is this
useful? This is kind of information is required by the collecting
side if it needs to understand fully what is being done on the
exporter side.
 
 

Section 4 - Clarification

In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed.  It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow.

Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards).

In my opinion with the picture the explanation looks much clearer.
 

Section 4.3 - Wording

"The typical functions of
   an Observation Domain may include:"

and then

"    * May perform appropriate middle-box functions to translate the
       flow information."

There is already a "may" on the first phrase

Ok.
 

Section 4.4.1 - Typo

" MAY need the
   following interpreting the flow records further:"

suggestion

"May need the following information to interpret the flow records further"

Ok

 

Section 4.4.2. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 4.4.3. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 5.2.1 - Conflicting terms

"   As mentioned in the selection criteria, the control and data stream
   MUST be transported over a congestion-aware transport protocol"

Ok. How about changing this to "SHOULD".
 

In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1:

"   The following is the list of criteria that the candidate protocol
   SHOULD meet in order to be the..."

 

Section 5.2.1 - Redundancy and possible conflict of terms

"   The data stream MAY be exported over an reliable or unreliable
   transport protocol."

Reliability & congestion awareness are 2 different aspects.

Thanks
Ganesh

 

In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section.

regards,

Reinaldo
 
 
 
 

------_=_NextPart_001_01C20C35.A22E3A36-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 4 22:48:33 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23367 for ; Tue, 4 Jun 2002 22:48:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FQc9-00001e-00 for ipfix-list@mil.doit.wisc.edu; Tue, 04 Jun 2002 21:33:33 -0500 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17FQc6-00000q-00 for ipfix@net.doit.wisc.edu; Tue, 04 Jun 2002 21:33:30 -0500 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.69.25.141]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g552WxHs005728; Tue, 4 Jun 2002 19:32:59 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-26.cisco.com [171.71.137.26]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA22019; Tue, 4 Jun 2002 19:32:59 -0700 (PDT) Message-ID: <3CFD785A.A7F02A20@cisco.com> Date: Tue, 04 Jun 2002 19:32:58 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft References: <7B802811BE77D51189910002A55CFD2C02A1A07F@zsc3c032.us.nortel.com> Content-Type: multipart/alternative; boundary="------------6BEFD01A62E1836508621E99" Precedence: bulk Sender: majordomo listserver --------------6BEFD01A62E1836508621E99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rienaldo, Not really. If the definition is fairly generic (which is the case here) it is always useful to point out its coverage. That's what thse examples are meant for. There had been a lot doubts raised on flow definition and explicitly putting examples can avoid a lot of mailing list traffic and for future readers. Having said that I am ok removing them out if that is the general consensus - but not because one person asserts multiple times what he does not like about the doc. Reinaldo Penno wrote: > Hello Ganesh,I disagree with your statement about the examples. If > people need examples to understnad the definition of a flow, then is > because the definition is not clear. Instead of attacking the root > cause of the problem you are putting "paches" around it which makes > the drafts full of fat. > I would be very, very surprised if this architecture draft pass last > call with all the implementation specific details it has justified > under the "readability" umbrella. I've never seen an IETF architecture > draft saying how many process I should code to realize some task, what > they should do, etc, etc, And where is all these details of "how many process I should code to realize some task" in the arch. spec? > > > I understand that some people get attached to their drafts but if you > rip those sessions of and read the draft again you will see that > nothing is lost, and is much more objective and charter > compliant.regards,Reinaldo This doc. is not my property it is a effort from a group of contributors. So what goes in would be what is the "rough consensus" & not a single person's opinion. BTW I would appreciate if you can avoid personal references. Thanks Ganesh > > > -----Original Message----- > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > Sent: Tuesday, June 04, 2002 6:04 PM > To: Penno, Reinaldo [SC101:T327:EXCH] > Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com > Subject: Re: [ipfix] Comments on IPFIX-architecture draft > Hello Reinaldo, > > Reinaldo Penno wrote: > > > > > > > Here it goes my comments. Sorry if some of them were > > already mentioned, but I finally found time to read > > through this. > > > > General: > > > > My main problem with this draft as it stands today is that > > it has a lot of fat that comes from dwelling in certain > > areas that I do not think it believes in an architecture > > document. For example, section 4.4.2 and 4.4.3 and the > > whole notion of match and filter functions is totally an > > implementation decision that has nothing to do with the > > ipfix protocol we will select or the definition of a flow > > (or should not have). > > What is the implementation (or design) specific details you > are referring to? > These are just 2 broad catgories of flow collection (.i.e > field dependent and field > independent ways). Regarding IPFIX protocol itself, it is a > separate set of sections. > This is just another piece in the general architecture. > > > > > > > > The definition of a flow should stick to what is proposed > > in the beggining of section 3. If I'm going to use the > > "mother of all rule sets", do it in a stepwise manner > > (using match or filter functions), or use complex logical > > constructs has nothing to do with the architecture. > > These examples are used to illustrate the breadth of > coverage of the defintion > and has been found useful to many other people others in > this mailing list to > undrestand the flow definition. > > > > > > > Other comments: > > > > Section 3 - Typo - Phrase is repeated twice > > > > "Each property is defined as the result of applying a > > function to the values of. > > Each property is defined as the result of applying a > > function to the values of:" > > Ok. > > > > > > > Section 3 - Wording > > > > "Each of the fields from 1., 2. > > and 3. are referred to as flow keys." > > > > Not sure what are these fields you are talking about...Are > > them the above mentioned list in the text? > > Yes. How does this look: "Each of the fields from 1., > 2. and 3. mentioned above are referred to as flow keys" > > > > > > > Section 3 - Wording > > > > "Though a flow could match a > > general application-level end-to-end stream, its > > definition is > > not restricted to this alone. The above definition > > covers a broad > > range from a flow containing all packets observed > > on a set of > > observation points to a flow consisting of just a > > single packet > > between two applications with a specific sequence > > number observed > > at a single observation point." > > > > I think we just remove this whole text without loss of > > generality or meaning. It seems to me it is repetitive > > based on the fact that this is already clear given the > > "flow keys" (1,2 and 3). > > Yes. I had the same opinion. But again it is for the > clarification for many > who mistook the scope of the definition to be restricted to > application-to-application. > > > > > > > Section 3. - Document structure. > > > > Not sure about putting flow examples in a terminology > > section...The examples use several terms that are only > > defined later in the text. I suggest move tall the > > examples to a new section somewhere after the terminology. > > This general feedback is that these examples improve the > clarity of the > definition. > > > > > > > Section 3 - Clarification on the match/filter functions on > > the examples > > > > IMO this "match/filter" function mentioned in example 2 > > does not belong in a architecture draft. This is an > > implementation internal decision. IMO the only think the > > architecture document should say is that > > Already explained above. > > > > > > > Section 3 - Typo > > > > "Each of the field which belongs to" > > > > s/field/fields > > Changed to "Each of the fields which belong to" > > > > > > > Section 3 - Terminology > > > > " * Flow Type: > > A function F which would take input as a set of > > flow keys and the > > output would be one or more flows depending on the > > combination of > > values for the set of flow keys." > > > > A set of "common properties", which the real world > > instantion would be the so-called fields already defines a > > flow. As mentioned in the beggining of secion 3 > > > > "All packets belonging to > > a particular flow have a set of common properties" > > > > So, the notion of flow type seems redundant. If its > > purposes in life is to justify the other text in the draft > > which talks about match/filter, is one more reason to > > remove this definition. > > I think I responded on this topic sometime back too. > Flow Type defines a class of flows. If F(a,b) is the flow > type > applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or > 3 different flows depending on what F does. Where is this > useful? This is kind of information is required by the > collecting > side if it needs to understand fully what is being done on > the > exporter side. > > > > > > > > Section 4 - Clarification > > > > In general I think dwelling in the internal of a device in > > a IETF architecture document is not a good practice, but > > that's MHO. At least in the "typical ipfix device" picture > > the functional boxes of the "selection criteria for flow > > export" and "metering process" should be removed. It is > > not a process that talks to external entities (a.k.a IETF > > Ipfix's protocol) and neither has anything to do with > > defining a flow. > > > > Anyway, my opinion is that we only need the first picture > > in section 4. Everything else is perfectly described in > > the text (section 4.1 onwards). > > In my opinion with the picture the explanation looks much > clearer. > > > > > > > Section 4.3 - Wording > > > > "The typical functions of > > an Observation Domain may include:" > > > > and then > > > > " * May perform appropriate middle-box functions to > > translate the > > flow information." > > > > There is already a "may" on the first phrase > > Ok. > > > > > > > Section 4.4.1 - Typo > > > > " MAY need the > > following interpreting the flow records further:" > > > > suggestion > > > > "May need the following information to interpret the flow > > records further" > > Ok > > > > > > > > > Section 4.4.2. - Remove > > > > IMO this section has no bearing in a architecture draft. > > It is completely an implementation decision that not even > > affect the IPfix protocol per se. > > explained above > > > > > > > Section 4.4.3. - Remove > > > > IMO this section has no bearing in a architecture draft. > > It is completely an implementation decision that not even > > affect the IPfix protocol per se. > > explained above > > > > > > > Section 5.2.1 - Conflicting terms > > > > " As mentioned in the selection criteria, the control > > and data stream > > MUST be transported over a congestion-aware transport > > protocol" > > Ok. How about changing this to "SHOULD". > > > > > > > In the selection criteria, ability to use a > > congestion-aware protocol is a SHOULD. Quote follows from > > section 5.1: > > > > " The following is the list of criteria that the > > candidate protocol > > SHOULD meet in order to be the..." > > > > > > > Section 5.2.1 - Redundancy and possible conflict of terms > > > > " The data stream MAY be exported over an reliable or > > unreliable > > transport protocol." > > Reliability & congestion awareness are 2 different aspects. > > Thanks > Ganesh > > > > > > > In section 5.1 congestion-aware is SHOULD, later is MUST > > and now (section 5.2.1) is MAY. I suggest removing this > > phrase. Everything related to which protocol must be used > > as a transport is already discussed on the beggining of > > this section. > > > > regards, > > > > Reinaldo > > > > > > > > > --------------6BEFD01A62E1836508621E99 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rienaldo,
   Not really. If the definition is fairly generic (which is the case here) it is
   always useful to point out its coverage. That's what  thse examples are meant
   for. There had been a lot doubts raised on flow definition and explicitly putting
   examples can avoid a lot of mailing list traffic and for future readers.
   Having said that I am ok removing them out if that is the general consensus -
   but not because one person asserts multiple times what he does not like about
   the doc.

Reinaldo Penno wrote:

Hello Ganesh,I disagree with your statement about the examples. If people need examples to understnad the definition of a flow, then is because the definition is not clear. Instead of attacking the root cause of the problem  you are putting "paches" around it which makes the drafts full of fat.
I would be very, very surprised if this architecture draft pass last call with all the implementation specific details it has justified under the "readability" umbrella. I've never seen an IETF architecture draft saying how many process I should code to realize some task, what they should do, etc, etc,
And where is all these details of "how many process I should code to realize some task"
in the arch. spec?
 

I understand that some people get attached to their drafts but if you rip those sessions of and read the draft again you will see that nothing is lost, and is much more objective and charter compliant.regards,Reinaldo

This doc. is not my property it is a effort from a group of  contributors. So what goes in
would be what is the "rough consensus" & not a single person's opinion.
BTW I would appreciate if you can avoid personal references.
Thanks
Ganesh
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 6:04 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: [ipfix] Comments on IPFIX-architecture draft
Hello Reinaldo,

Reinaldo Penno wrote:

 

Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this.

General:

My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have).

What is the  implementation (or design) specific details you are referring to?
These are just 2 broad catgories of flow collection (.i.e field dependent and field
independent ways). Regarding IPFIX protocol itself, it is a separate set of sections.
This is just another piece in the general architecture.
 
 

The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture.

These examples are used to illustrate the breadth of coverage of the defintion
and has been found useful to many other people others in this mailing list to
undrestand the flow definition.
 

Other comments:

Section 3 - Typo - Phrase is repeated twice

"Each property is defined as the result of applying a function to the values of.
Each property is defined as the result of applying a function to the values of:"

Ok.
 

Section 3 - Wording

"Each of the fields from 1., 2.
       and 3. are referred to as flow keys."

Not sure what are these fields you are talking about...Are them the above mentioned list in the text?

Yes.  How does this look:  "Each of the fields from 1.,
2. and 3. mentioned above are referred to as flow keys"
 

Section 3 - Wording

"Though a flow could match a
       general application-level end-to-end stream, its definition is
       not restricted to this alone. The above definition covers a broad
       range from a flow containing all packets observed on a set of
       observation points to a flow consisting of just a single packet
       between two applications with a specific sequence number observed
       at a single observation point."

I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3).

Yes. I had the same opinion. But again it is for the clarification for many
who mistook the scope of the definition to be restricted to
application-to-application.
 

Section 3. - Document structure.

Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology.

This general feedback is that these examples improve the clarity of the
definition.
 

Section 3 - Clarification on the match/filter functions on the examples

IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that

Already explained above.
 

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

Changed to "Each of the fields which belong to"
 

Section 3 - Terminology

"   * Flow Type:
       A function F which would take input as a set of flow keys and the
       output would be one or more flows depending on the combination of
       values for the set of flow keys."

A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3

"All packets belonging to
       a particular flow have a set of common properties"

So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition.

I think I responded on this topic sometime back too.
Flow Type defines a class of flows. If F(a,b) is the flow type
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or
3 different flows depending on what F does. Where is this
useful? This is kind of information is required by the collecting
side if it needs to understand fully what is being done on the
exporter side.
 
 

Section 4 - Clarification

In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed.  It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow.

Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards).

In my opinion with the picture the explanation looks much clearer.
 

Section 4.3 - Wording

"The typical functions of
   an Observation Domain may include:"

and then

"    * May perform appropriate middle-box functions to translate the
       flow information."

There is already a "may" on the first phrase

Ok.
 

Section 4.4.1 - Typo

" MAY need the
   following interpreting the flow records further:"

suggestion

"May need the following information to interpret the flow records further"

Ok
 
 

Section 4.4.2. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 4.4.3. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 5.2.1 - Conflicting terms

"   As mentioned in the selection criteria, the control and data stream
   MUST be transported over a congestion-aware transport protocol"

Ok. How about changing this to "SHOULD".
 

In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1:

"   The following is the list of criteria that the candidate protocol
   SHOULD meet in order to be the..."

 

Section 5.2.1 - Redundancy and possible conflict of terms

"   The data stream MAY be exported over an reliable or unreliable
   transport protocol."

Reliability & congestion awareness are 2 different aspects.

Thanks
Ganesh

 

In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section.

regards,

Reinaldo
 
 
 
 

--------------6BEFD01A62E1836508621E99-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 4 22:56:55 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23462 for ; Tue, 4 Jun 2002 22:56:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FQhK-00005W-00 for ipfix-list@mil.doit.wisc.edu; Tue, 04 Jun 2002 21:38:54 -0500 Received: from h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17FQhJ-00005J-00 for ipfix@net.doit.wisc.edu; Tue, 04 Jun 2002 21:38:53 -0500 Received: (cpmta 27489 invoked from network); 4 Jun 2002 19:38:15 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.115) with SMTP; 4 Jun 2002 19:38:15 -0700 X-Sent: 5 Jun 2002 02:38:15 GMT Message-ID: <005001c20c3a$27ca48c0$850f880a@kcn> From: "K.C. Norseth" To: "Reinaldo Penno" Cc: "Ganesh Sadasivan" , "IPFIX" References: <7B802811BE77D51189910002A55CFD2C02A1A07F@zsc3c032.us.nortel.com> Subject: Re: [ipfix] Comments on IPFIX-architecture draft Date: Tue, 4 Jun 2002 20:39:01 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C20C07.DC33C580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C20C07.DC33C580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Reinaldo, ----- Original Message -----=20 From: Reinaldo Penno=20 To: Ganesh Sadasivan=20 Cc: ipfix@net.doit.wisc.edu ; kcn@norseth.com=20 Sent: Tuesday, June 04, 2002 8:06 PM Subject: RE: [ipfix] Comments on IPFIX-architecture draft Hello Ganesh, I disagree with your statement about the examples. If people need = examples to understnad the definition of a flow, then is because the = definition is not clear. Instead of attacking the root cause of the = problem you are putting "paches" around it which makes the drafts full = of fat. Which examples are you discussing 4.4.2 and 4.4.3 ? I do think we need = that there so it can help explain. I don't think these are patches. I would be very, very surprised if this architecture draft pass last = call with all the implementation specific details it has justified under = the "readability" umbrella. I've never seen an IETF architecture draft = saying how many process I should code to realize some task, what they = should do, etc, etc, This draft will not hit last call in this format. The protocol selected = will influence greatly the document. What we are trying to do is define = the selection criteria. We don't want a document where things are not = spelled out clearly. Trying to find the happy medium is the trick. I understand that some people get attached to their drafts but if you = rip those sessions of and read the draft again you will see that nothing = is lost, and is much more objective and charter compliant. regards, Reinaldo -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Tuesday, June 04, 2002 6:04 PM To: Penno, Reinaldo [SC101:T327:EXCH] Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft Hello Reinaldo,=20 Reinaldo Penno wrote:=20 =20 Here it goes my comments. Sorry if some of them were already = mentioned, but I finally found time to read through this.=20 General:=20 My main problem with this draft as it stands today is that it has = a lot of fat that comes from dwelling in certain areas that I do not = think it believes in an architecture document. For example, section = 4.4.2 and 4.4.3 and the whole notion of match and filter functions is = totally an implementation decision that has nothing to do with the ipfix = protocol we will select or the definition of a flow (or should not = have). What is the implementation (or design) specific details you are = referring to?=20 These are just 2 broad catgories of flow collection (.i.e field = dependent and field=20 independent ways). Regarding IPFIX protocol itself, it is a separate = set of sections.=20 This is just another piece in the general architecture.=20 =20 =20 The definition of a flow should stick to what is proposed in the = beggining of section 3. If I'm going to use the "mother of all rule = sets", do it in a stepwise manner (using match or filter functions), or = use complex logical constructs has nothing to do with the architecture. These examples are used to illustrate the breadth of coverage of the = defintion=20 and has been found useful to many other people others in this = mailing list to=20 undrestand the flow definition.=20 =20 Other comments:=20 Section 3 - Typo - Phrase is repeated twice=20 "Each property is defined as the result of applying a function to = the values of.=20 Each property is defined as the result of applying a function to = the values of:" Ok.=20 =20 Section 3 - Wording=20 "Each of the fields from 1., 2.=20 and 3. are referred to as flow keys."=20 Not sure what are these fields you are talking about...Are them = the above mentioned list in the text? Yes. How does this look: "Each of the fields from 1.,=20 2. and 3. mentioned above are referred to as flow keys"=20 =20 Section 3 - Wording=20 "Though a flow could match a=20 general application-level end-to-end stream, its definition = is=20 not restricted to this alone. The above definition covers a = broad=20 range from a flow containing all packets observed on a set = of=20 observation points to a flow consisting of just a single = packet=20 between two applications with a specific sequence number = observed=20 at a single observation point."=20 I think we just remove this whole text without loss of generality = or meaning. It seems to me it is repetitive based on the fact that this = is already clear given the "flow keys" (1,2 and 3). Yes. I had the same opinion. But again it is for the clarification = for many=20 who mistook the scope of the definition to be restricted to=20 application-to-application.=20 =20 Section 3. - Document structure.=20 Not sure about putting flow examples in a terminology = section...The examples use several terms that are only defined later in = the text. I suggest move tall the examples to a new section somewhere = after the terminology. This general feedback is that these examples improve the clarity of = the=20 definition.=20 =20 Section 3 - Clarification on the match/filter functions on the = examples=20 IMO this "match/filter" function mentioned in example 2 does not = belong in a architecture draft. This is an implementation internal = decision. IMO the only think the architecture document should say is = that Already explained above.=20 =20 Section 3 - Typo=20 "Each of the field which belongs to"=20 s/field/fields Changed to "Each of the fields which belong to"=20 =20 Section 3 - Terminology=20 " * Flow Type:=20 A function F which would take input as a set of flow keys = and the=20 output would be one or more flows depending on the = combination of=20 values for the set of flow keys."=20 A set of "common properties", which the real world instantion = would be the so-called fields already defines a flow. As mentioned in = the beggining of secion 3=20 "All packets belonging to=20 a particular flow have a set of common properties"=20 So, the notion of flow type seems redundant. If its purposes in = life is to justify the other text in the draft which talks about = match/filter, is one more reason to remove this definition. I think I responded on this topic sometime back too.=20 Flow Type defines a class of flows. If F(a,b) is the flow type=20 applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or=20 3 different flows depending on what F does. Where is this=20 useful? This is kind of information is required by the collecting=20 side if it needs to understand fully what is being done on the=20 exporter side.=20 =20 =20 Section 4 - Clarification=20 In general I think dwelling in the internal of a device in a IETF = architecture document is not a good practice, but that's MHO. At least = in the "typical ipfix device" picture the functional boxes of the = "selection criteria for flow export" and "metering process" should be = removed. It is not a process that talks to external entities (a.k.a = IETF Ipfix's protocol) and neither has anything to do with defining a = flow.=20 Anyway, my opinion is that we only need the first picture in = section 4. Everything else is perfectly described in the text (section = 4.1 onwards). In my opinion with the picture the explanation looks much clearer.=20 =20 Section 4.3 - Wording=20 "The typical functions of=20 an Observation Domain may include:"=20 and then=20 " * May perform appropriate middle-box functions to translate = the=20 flow information."=20 There is already a "may" on the first phrase Ok.=20 =20 Section 4.4.1 - Typo=20 " MAY need the=20 following interpreting the flow records further:"=20 suggestion=20 "May need the following information to interpret the flow records = further" Ok=20 =20 Section 4.4.2. - Remove=20 IMO this section has no bearing in a architecture draft. It is = completely an implementation decision that not even affect the IPfix = protocol per se. explained above=20 =20 Section 4.4.3. - Remove=20 IMO this section has no bearing in a architecture draft. It is = completely an implementation decision that not even affect the IPfix = protocol per se. explained above=20 =20 Section 5.2.1 - Conflicting terms=20 " As mentioned in the selection criteria, the control and data = stream=20 MUST be transported over a congestion-aware transport protocol" Ok. How about changing this to "SHOULD".=20 =20 In the selection criteria, ability to use a congestion-aware = protocol is a SHOULD. Quote follows from section 5.1:=20 " The following is the list of criteria that the candidate = protocol=20 SHOULD meet in order to be the..." =20 Section 5.2.1 - Redundancy and possible conflict of terms=20 " The data stream MAY be exported over an reliable or unreliable = transport protocol." Reliability & congestion awareness are 2 different aspects.=20 Thanks=20 Ganesh=20 =20 In section 5.1 congestion-aware is SHOULD, later is MUST and now = (section 5.2.1) is MAY. I suggest removing this phrase. Everything = related to which protocol must be used as a transport is already = discussed on the beggining of this section.=20 regards,=20 Reinaldo=20 =20 =20 =20 =20 ------=_NextPart_000_004D_01C20C07.DC33C580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Reinaldo,
 
 
----- Original Message -----
From:=20 Reinaldo Penno =
Cc: ipfix@net.doit.wisc.edu ; = kcn@norseth.com
Sent: Tuesday, June 04, 2002 = 8:06=20 PM
Subject: RE: [ipfix] Comments = on=20 IPFIX-architecture draft

Hello Ganesh,
 
I=20 disagree with your statement about the examples. If people need = examples to=20 understnad the definition of a flow, then is because the definition is = not=20 clear. Instead of attacking the root cause of the problem  you = are=20 putting "paches" around it which makes the drafts full of=20 fat.
Which=20 examples are you discussing  4.4.2 and=20 4.4.3 ? I do think we need that there so it = can help=20 explain.  I don't think these are = patches.
 
I=20 would be very, very surprised if this architecture draft pass = last call=20 with all the implementation specific details it has = justified under the=20 "readability" umbrella. I've never seen an IETF architecture draft = saying how=20 many process I should code to realize some task, what they should do, = etc,=20 etc,
This draft=20 will not hit last call in this format.  The protocol selected will=20 influence greatly the document.  What we are trying to do is define = the=20 selection criteria.  We don't want a document where things are not = spelled=20 out clearly.  Trying to find the happy medium is the=20 trick.
 
I=20 understand that some people get attached to their drafts but if you = rip those=20 sessions of and read the draft again you will see that nothing is = lost, and is=20 much more objective and charter compliant.
 
regards,
 
Reinaldo
 
 
-----Original Message-----
From: Ganesh Sadasivan = [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 = 6:04=20 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc:=20 ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: = [ipfix]=20 Comments on IPFIX-architecture draft

Hello = Reinaldo,=20

Reinaldo Penno wrote:=20

 =20

Here it goes my comments. Sorry if some of them = were=20 already mentioned, but I finally found time to read through = this.=20

General:=20

My main problem with this draft as it stands = today is=20 that it has a lot of fat that comes from dwelling in certain areas = that I=20 do not think it believes in an architecture document. For example, = section=20 4.4.2 and 4.4.3 and the whole notion of match and filter functions = is=20 totally an implementation decision that has nothing to do with the = ipfix=20 protocol we will select or the definition of a flow (or should not = have).

What is the  implementation (or = design)=20 specific details you are referring to?
These are just 2 broad = catgories=20 of flow collection (.i.e field dependent and field
independent = ways).=20 Regarding IPFIX protocol itself, it is a separate set of sections. =
This=20 is just another piece in the general architecture.
 =20
 =20

The definition of a flow should stick to what = is proposed=20 in the beggining of section 3. If I'm going to use the "mother of = all rule=20 sets", do it in a stepwise manner (using match or filter = functions), or=20 use complex logical constructs has nothing to do with the=20 architecture.

These examples are used to = illustrate=20 the breadth of coverage of the defintion
and has been found = useful to=20 many other people others in this mailing list to
undrestand the = flow=20 definition.=20
 =20

Other comments:=20

Section 3 - Typo - Phrase is repeated = twice=20

"Each property is defined as the result of = applying a=20 function to the values of.
Each = property is=20 defined as the result of applying a function to the values=20 of:"

Ok.=20
 =20

Section 3 - Wording=20

"Each of the fields from 1., 2. =
       and 3. are referred = to as=20 flow keys."=20

Not sure what are these fields you are talking=20 about...Are them the above mentioned list in the=20 text?

Yes.  How does this look:  = "Each of=20 the fields from 1.,
2. and 3. mentioned above are referred to as = flow=20 keys"=20
 =20

Section 3 - Wording=20

"Though a flow could match a
       general = application-level=20 end-to-end stream, its definition is
       not restricted to = this alone.=20 The above definition covers a broad
       range from a flow = containing=20 all packets observed on a set of
       observation points = to a flow=20 consisting of just a single packet
       between two = applications with=20 a specific sequence number observed
       at a single = observation=20 point."=20

I think we just remove this whole text without = loss of=20 generality or meaning. It seems to me it is repetitive based on = the fact=20 that this is already clear given the "flow keys" (1,2 and=20 3).

Yes. I had the same opinion. But again it = is for=20 the clarification for many
who mistook the scope of the = definition to be=20 restricted to
application-to-application.=20
 =20

Section 3. - Document structure.=20

Not sure about putting flow examples in a = terminology=20 section...The examples use several terms that are only defined = later in=20 the text. I suggest move tall the examples to a new section = somewhere=20 after the terminology.

This general = feedback is that=20 these examples improve the clarity of the
definition.=20
 =20

Section 3 - Clarification on the match/filter = functions=20 on the examples=20

IMO this "match/filter" function mentioned in = example 2=20 does not belong in a architecture draft. This is an implementation = internal decision. IMO the only think the architecture document = should say=20 is that

Already explained above.=20
 =20

Section 3 - Typo=20

"Each of the field which belongs to"=20

s/field/fields

Changed = to "Each of the fields which belong to"=20
 =20

Section 3 - Terminology=20

"   * Flow Type:
       A function F which = would take=20 input as a set of flow keys and the
       output would be one = or more=20 flows depending on the combination of
       values for the set = of flow=20 keys."=20

A set of "common properties", which the real = world=20 instantion would be the so-called fields already defines a flow. = As=20 mentioned in the beggining of secion 3=20

"All packets belonging to
       a particular flow = have a set=20 of common properties"=20

So, the notion of flow type seems redundant. If = its=20 purposes in life is to justify the other text in the draft which = talks=20 about match/filter, is one more reason to remove this=20 definition.

I think I responded on this = topic=20 sometime back too.
Flow Type defines a class of flows. If F(a,b) = is the=20 flow type
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, = 2 or=20
3 different flows depending on what F does. Where is this =
useful?=20 This is kind of information is required by the collecting
side = if it=20 needs to understand fully what is being done on the
exporter = side.=20
 =20
 =20

Section 4 - Clarification=20

In general I think dwelling in the internal of = a device=20 in a IETF architecture document is not a good practice, but that's = MHO. At=20 least in the "typical ipfix device" picture the functional boxes = of the=20 "selection criteria for flow export" and "metering process" should = be=20 removed.  It is not a process that talks to external entities = (a.k.a=20 IETF Ipfix's protocol) and neither has anything to do with = defining a=20 flow.=20

Anyway, my opinion is that we only need the = first picture=20 in section 4. Everything else is perfectly described in the text = (section=20 4.1 onwards).

In my opinion with the = picture the=20 explanation looks much clearer.=20
 =20

Section 4.3 - Wording=20

"The typical functions of
   an Observation Domain may include:"=20

and then=20

"    * May perform appropriate = middle-box=20 functions to translate the
       flow = information."=20

There is already a "may" on the first=20 phrase

Ok.=20
 =20

Section 4.4.1 - Typo=20

" MAY need the
  =20 following interpreting the flow records further:"=20

suggestion=20

"May need the following information to = interpret the flow=20 records further"

Ok=20

 =20

Section 4.4.2. - Remove=20

IMO this section has no bearing in a = architecture draft.=20 It is completely an implementation decision that not even affect = the IPfix=20 protocol per se.

explained above=20
 =20

Section 4.4.3. - Remove=20

IMO this section has no bearing in a = architecture draft.=20 It is completely an implementation decision that not even affect = the IPfix=20 protocol per se.

explained above=20
 =20

Section 5.2.1 - Conflicting terms=20

"   As mentioned in the selection = criteria, the=20 control and data stream
   = MUST be=20 transported over a congestion-aware transport=20 protocol"

Ok. How about changing this to = "SHOULD".=20
 =20

In the selection criteria, ability to use a=20 congestion-aware protocol is a SHOULD. Quote follows from section=20 5.1:=20

"   The following is the list of = criteria that=20 the candidate protocol
   = SHOULD meet=20 in order to be the..."

 =20

Section 5.2.1 - Redundancy and possible = conflict of=20 terms=20

"   The data stream MAY be exported = over an=20 reliable or unreliable
   = transport=20 protocol."

Reliability & congestion = awareness are=20 2 different aspects.=20

Thanks
Ganesh=20

 =20

In section 5.1 congestion-aware is SHOULD, = later is MUST=20 and now (section 5.2.1) is MAY. I suggest removing this phrase. = Everything=20 related to which protocol must be used as a transport is already = discussed=20 on the beggining of this section.=20

regards,=20

Reinaldo
 
  =
 =20 =
 

------=_NextPart_000_004D_01C20C07.DC33C580-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jun 5 02:49:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21524 for ; Wed, 5 Jun 2002 02:49:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FUKE-00059d-00 for ipfix-list@mil.doit.wisc.edu; Wed, 05 Jun 2002 01:31:18 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112] helo=zrc2s0jx.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17FUKB-00058y-00 for ipfix@net.doit.wisc.edu; Wed, 05 Jun 2002 01:31:15 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g556Uol27777; Wed, 5 Jun 2002 01:30:50 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 23:30:33 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C02A1A0CF@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: RE: [ipfix] Comments on IPFIX-architecture draft Date: Tue, 4 Jun 2002 23:30:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20C5A.78282BE6" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20C5A.78282BE6 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Tuesday, June 04, 2002 7:33 PM To: Penno, Reinaldo [SC101:T327:EXCH] Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft Hi Rienaldo, Not really. If the definition is fairly generic (which is the case here) it is always useful to point out its coverage. That's what thse examples are meant for. There had been a lot doubts raised on flow definition and explicitly putting examples can avoid a lot of mailing list traffic and for future readers. Having said that I am ok removing them out if that is the general consensus - but not because one person asserts multiple times what he does not like about the doc. Reinaldo Penno wrote: Hello Ganesh,I disagree with your statement about the examples. If people need examples to understnad the definition of a flow, then is because the definition is not clear. Instead of attacking the root cause of the problem you are putting "paches" around it which makes the drafts full of fat. I would be very, very surprised if this architecture draft pass last call with all the implementation specific details it has justified under the "readability" umbrella. I've never seen an IETF architecture draft saying how many process I should code to realize some task, what they should do, etc, etc, And where is all these details of "how many process I should code to realize some task" in the arch. spec? In the part where you say what the meter should do, the exported should do, and how is the internal organization of a exporter. I believe this is implementaion specific, isn't it? I understand that some people get attached to their drafts but if you rip those sessions of and read the draft again you will see that nothing is lost, and is much more objective and charter compliant.regards,Reinaldo This doc. is not my property it is a effort from a group of contributors. So what goes in would be what is the "rough consensus" & not a single person's opinion. BTW I would appreciate if you can avoid personal references. Ganesh, don't be so sensitive. I meant "you" generally. Besides I wonder why you ask me that if you said previously "but not because one person asserts multiple times". But that's okay... -Reinaldo Thanks Ganesh -----Original Message----- From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com ] Sent: Tuesday, June 04, 2002 6:04 PM To: Penno, Reinaldo [SC101:T327:EXCH] Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft Hello Reinaldo, Reinaldo Penno wrote: Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this. General: My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have). What is the implementation (or design) specific details you are referring to? These are just 2 broad catgories of flow collection (.i.e field dependent and field independent ways). Regarding IPFIX protocol itself, it is a separate set of sections. This is just another piece in the general architecture. The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture. These examples are used to illustrate the breadth of coverage of the defintion and has been found useful to many other people others in this mailing list to undrestand the flow definition. Other comments: Section 3 - Typo - Phrase is repeated twice "Each property is defined as the result of applying a function to the values of. Each property is defined as the result of applying a function to the values of:" Ok. Section 3 - Wording "Each of the fields from 1., 2. and 3. are referred to as flow keys." Not sure what are these fields you are talking about...Are them the above mentioned list in the text? Yes. How does this look: "Each of the fields from 1., 2. and 3. mentioned above are referred to as flow keys" Section 3 - Wording "Though a flow could match a general application-level end-to-end stream, its definition is not restricted to this alone. The above definition covers a broad range from a flow containing all packets observed on a set of observation points to a flow consisting of just a single packet between two applications with a specific sequence number observed at a single observation point." I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3). Yes. I had the same opinion. But again it is for the clarification for many who mistook the scope of the definition to be restricted to application-to-application. Section 3. - Document structure. Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology. This general feedback is that these examples improve the clarity of the definition. Section 3 - Clarification on the match/filter functions on the examples IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that Already explained above. Section 3 - Typo "Each of the field which belongs to" s/field/fields Changed to "Each of the fields which belong to" Section 3 - Terminology " * Flow Type: A function F which would take input as a set of flow keys and the output would be one or more flows depending on the combination of values for the set of flow keys." A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3 "All packets belonging to a particular flow have a set of common properties" So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition. I think I responded on this topic sometime back too. Flow Type defines a class of flows. If F(a,b) is the flow type applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or 3 different flows depending on what F does. Where is this useful? This is kind of information is required by the collecting side if it needs to understand fully what is being done on the exporter side. Section 4 - Clarification In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed. It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow. Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards). In my opinion with the picture the explanation looks much clearer. Section 4.3 - Wording "The typical functions of an Observation Domain may include:" and then " * May perform appropriate middle-box functions to translate the flow information." There is already a "may" on the first phrase Ok. Section 4.4.1 - Typo " MAY need the following interpreting the flow records further:" suggestion "May need the following information to interpret the flow records further" Ok Section 4.4.2. - Remove IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se. explained above Section 4.4.3. - Remove IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se. explained above Section 5.2.1 - Conflicting terms " As mentioned in the selection criteria, the control and data stream MUST be transported over a congestion-aware transport protocol" Ok. How about changing this to "SHOULD". In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1: " The following is the list of criteria that the candidate protocol SHOULD meet in order to be the..." Section 5.2.1 - Redundancy and possible conflict of terms " The data stream MAY be exported over an reliable or unreliable transport protocol." Reliability & congestion awareness are 2 different aspects. Thanks Ganesh In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section. regards, Reinaldo ------_=_NextPart_001_01C20C5A.78282BE6 Content-Type: text/html; charset="iso-8859-1"
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 7:33 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: [ipfix] Comments on IPFIX-architecture draft

Hi Rienaldo,
   Not really. If the definition is fairly generic (which is the case here) it is
   always useful to point out its coverage. That's what  thse examples are meant
   for. There had been a lot doubts raised on flow definition and explicitly putting
   examples can avoid a lot of mailing list traffic and for future readers.
   Having said that I am ok removing them out if that is the general consensus -
   but not because one person asserts multiple times what he does not like about
   the doc.

Reinaldo Penno wrote:

Hello Ganesh,I disagree with your statement about the examples. If people need examples to understnad the definition of a flow, then is because the definition is not clear. Instead of attacking the root cause of the problem  you are putting "paches" around it which makes the drafts full of fat.
I would be very, very surprised if this architecture draft pass last call with all the implementation specific details it has justified under the "readability" umbrella. I've never seen an IETF architecture draft saying how many process I should code to realize some task, what they should do, etc, etc,
And where is all these details of "how many process I should code to realize some task"
in the arch. spec?  
 
In the part where you say what the meter should do, the exported should do, and how is the internal organization of a exporter. I believe this is implementaion specific, isn't it? 
 

I understand that some people get attached to their drafts but if you rip those sessions of and read the draft again you will see that nothing is lost, and is much more objective and charter compliant.regards,Reinaldo

This doc. is not my property it is a effort from a group of  contributors. So what goes in
would be what is the "rough consensus" & not a single person's opinion.
BTW I would appreciate if you can avoid personal references.  
 
 
Ganesh, 
 
don't be so sensitive.  I meant "you" generally. Besides I wonder why you ask me that if you said previously "but not because one person asserts multiple times". But that's okay...
 
-Reinaldo
 
Thanks
Ganesh
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 6:04 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: [ipfix] Comments on IPFIX-architecture draft
Hello Reinaldo,

Reinaldo Penno wrote:

 

Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this.

General:

My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have).

What is the  implementation (or design) specific details you are referring to?
These are just 2 broad catgories of flow collection (.i.e field dependent and field
independent ways). Regarding IPFIX protocol itself, it is a separate set of sections.
This is just another piece in the general architecture.
 
 

The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture.

These examples are used to illustrate the breadth of coverage of the defintion
and has been found useful to many other people others in this mailing list to
undrestand the flow definition.
 

Other comments:

Section 3 - Typo - Phrase is repeated twice

"Each property is defined as the result of applying a function to the values of.
Each property is defined as the result of applying a function to the values of:"

Ok.
 

Section 3 - Wording

"Each of the fields from 1., 2.
       and 3. are referred to as flow keys."

Not sure what are these fields you are talking about...Are them the above mentioned list in the text?

Yes.  How does this look:  "Each of the fields from 1.,
2. and 3. mentioned above are referred to as flow keys"
 

Section 3 - Wording

"Though a flow could match a
       general application-level end-to-end stream, its definition is
       not restricted to this alone. The above definition covers a broad
       range from a flow containing all packets observed on a set of
       observation points to a flow consisting of just a single packet
       between two applications with a specific sequence number observed
       at a single observation point."

I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3).

Yes. I had the same opinion. But again it is for the clarification for many
who mistook the scope of the definition to be restricted to
application-to-application.
 

Section 3. - Document structure.

Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology.

This general feedback is that these examples improve the clarity of the
definition.
 

Section 3 - Clarification on the match/filter functions on the examples

IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that

Already explained above.
 

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

Changed to "Each of the fields which belong to"
 

Section 3 - Terminology

"   * Flow Type:
       A function F which would take input as a set of flow keys and the
       output would be one or more flows depending on the combination of
       values for the set of flow keys."

A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3

"All packets belonging to
       a particular flow have a set of common properties"

So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition.

I think I responded on this topic sometime back too.
Flow Type defines a class of flows. If F(a,b) is the flow type
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or
3 different flows depending on what F does. Where is this
useful? This is kind of information is required by the collecting
side if it needs to understand fully what is being done on the
exporter side.
 
 

Section 4 - Clarification

In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed.  It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow.

Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards).

In my opinion with the picture the explanation looks much clearer.
 

Section 4.3 - Wording

"The typical functions of
   an Observation Domain may include:"

and then

"    * May perform appropriate middle-box functions to translate the
       flow information."

There is already a "may" on the first phrase

Ok.
 

Section 4.4.1 - Typo

" MAY need the
   following interpreting the flow records further:"

suggestion

"May need the following information to interpret the flow records further"

Ok

 

Section 4.4.2. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 4.4.3. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 5.2.1 - Conflicting terms

"   As mentioned in the selection criteria, the control and data stream
   MUST be transported over a congestion-aware transport protocol"

Ok. How about changing this to "SHOULD".
 

In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1:

"   The following is the list of criteria that the candidate protocol
   SHOULD meet in order to be the..."

 

Section 5.2.1 - Redundancy and possible conflict of terms

"   The data stream MAY be exported over an reliable or unreliable
   transport protocol."

Reliability & congestion awareness are 2 different aspects.

Thanks
Ganesh

 

In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section.

regards,

Reinaldo
 
 
 
 

------_=_NextPart_001_01C20C5A.78282BE6-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jun 5 22:04:21 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06479 for ; Wed, 5 Jun 2002 22:04:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FmK2-0002Wv-00 for ipfix-list@mil.doit.wisc.edu; Wed, 05 Jun 2002 20:44:18 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17FmK1-0002Wk-00 for ipfix@net.doit.wisc.edu; Wed, 05 Jun 2002 20:44:17 -0500 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.69.25.141]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g561hgPI029190; Wed, 5 Jun 2002 18:43:42 -0700 (PDT) Received: from cisco.com (sjc-vpn3-283.cisco.com [10.21.65.27]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA23882; Wed, 5 Jun 2002 18:43:42 -0700 (PDT) Message-ID: <3CFEBE4D.60D398F@cisco.com> Date: Wed, 05 Jun 2002 18:43:41 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: n.brownlee@auckland.ac.nz CC: ipfix@net.doit.wisc.edu Subject: [ipfix] architecture draft References: <200206051903.AEB04477@mailhost-mp.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Nevil, n.brownlee@auckland.ac.nz wrote: > Hello Ganesh: > > > > > I've read the list messages about the Architecture draft. By and large > I agree with you, at this stage extra illustrative material is helpful. > Once we've selected a protocol, I expect that we'll want to rework the > architecture draft to be sure it covers the chosen protocol; that will > be the right time to think about which parts - if any - are superfluous. Agreed. > > > Wrt one of your comments, section 5.2.1 is correct when it says IPFIX > control and data streams MUST be transported over a congestion-aware > protocol. That's an IETF consensus, which the IESG reminded us about by > putting it into the IPFIX charter. After re-reading the text, the confusion is because in section 5.1, it is stated that "The following is the list of criteria that the candidate protocol SHOULD meet in order to be the qualified into the IPFIX architecture" which is true because we did not find an exact match of what we want and are in the process of choosing the one which matches the most. So "SHOULD" is applicable to the total of all the selection criteria. So I'll leave the text as it is. > > > Also, I was re-reading the Minneapolis minutes; in the discussion there > 'Control Stream' was considered to be confusing, there was consensus for > 'Data Description' instead. > "Data description" does not fully convey all the control information. There could be messages like "Keepalives" which is part of the control and has nothing to do with "Data Description". Thanks Ganesh > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jun 5 22:10:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06828 for ; Wed, 5 Jun 2002 22:10:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17Fm9Q-0002L9-00 for ipfix-list@mil.doit.wisc.edu; Wed, 05 Jun 2002 20:33:20 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17Fm9M-0002KB-00 for ipfix@net.doit.wisc.edu; Wed, 05 Jun 2002 20:33:16 -0500 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.69.25.141]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g561WjPI025048; Wed, 5 Jun 2002 18:32:45 -0700 (PDT) Received: from cisco.com (sjc-vpn3-283.cisco.com [10.21.65.27]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA23878; Wed, 5 Jun 2002 18:32:43 -0700 (PDT) Message-ID: <3CFEBBB9.D2B90D60@cisco.com> Date: Wed, 05 Jun 2002 18:32:43 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft References: <7B802811BE77D51189910002A55CFD2C02A1A0CF@zsc3c032.us.nortel.com> Content-Type: multipart/alternative; boundary="------------770791BDE7558980ED100FFD" Precedence: bulk Sender: majordomo listserver --------------770791BDE7558980ED100FFD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rienaldo, * The text tells that it is a "typical IPFIX device" * The diagram has blocks defined by the terminology section with a skeletal model of the flow collection & export path. I don't think this has any specific implementationd details. Ganesh Reinaldo Penno wrote: > > > -----Original Message----- > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > Sent: Tuesday, June 04, 2002 7:33 PM > To: Penno, Reinaldo [SC101:T327:EXCH] > Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com > Subject: Re: [ipfix] Comments on IPFIX-architecture draft > Hi Rienaldo, > Not really. If the definition is fairly generic (which is > the case here) it is > always useful to point out its coverage. That's what > thse examples are meant > for. There had been a lot doubts raised on flow > definition and explicitly putting > examples can avoid a lot of mailing list traffic and for > future readers. > Having said that I am ok removing them out if that is the > general consensus - > but not because one person asserts multiple times what he > does not like about > the doc. > > Reinaldo Penno wrote: > > > Hello Ganesh,I disagree with your statement about the > > examples. If people need examples to understnad the > > definition of a flow, then is because the definition is > > not clear. Instead of attacking the root cause of the > > problem you are putting "paches" around it which makes > > the drafts full of fat. > > > I would be very, very surprised if this architecture draft > > pass last call with all the implementation specific > > details it has justified under the "readability" umbrella. > > I've never seen an IETF architecture draft saying how many > > process I should code to realize some task, what they > > should do, etc, etc, > > And where is all these details of "how many process I should > code to realize some task" > in the arch. spec? In the part where you say what the meter > should do, the exported should do, and how is the internal > organization of a exporter. I believe this is implementaion > specific, isn't it? > > > > > > > > > I understand that some people get attached to their drafts > > but if you rip those sessions of and read the draft again > > you will see that nothing is lost, and is much more > > objective and charter compliant.regards,Reinaldo > > This doc. is not my property it is a effort from a group of > contributors. So what goes in > would be what is the "rough consensus" & not a single > person's opinion. > BTW I would appreciate if you can avoid personal > references. Ganesh, don't be so sensitive. I meant "you" > generally. Besides I wonder why you ask me that if you > said previously "but not because one person asserts multiple > times". But that's okay...-Reinaldo > > > > Thanks > Ganesh > > > > > > > -----Original Message----- > > From: Ganesh Sadasivan > > [mailto:gsadasiv@cisco.com] > > Sent: Tuesday, June 04, 2002 6:04 PM > > To: Penno, Reinaldo [SC101:T327:EXCH] > > Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com > > Subject: Re: [ipfix] Comments on > > IPFIX-architecture draft > > Hello Reinaldo, > > > > Reinaldo Penno wrote: > > > > > > > > > > > Here it goes my comments. Sorry if some of them > > > were already mentioned, but I finally found > > > time to read through this. > > > > > > General: > > > > > > My main problem with this draft as it stands > > > today is that it has a lot of fat that comes > > > from dwelling in certain areas that I do not > > > think it believes in an architecture document. > > > For example, section 4.4.2 and 4.4.3 and the > > > whole notion of match and filter functions is > > > totally an implementation decision that has > > > nothing to do with the ipfix protocol we will > > > select or the definition of a flow (or should > > > not have). > > > > What is the implementation (or design) specific > > details you are referring to? > > These are just 2 broad catgories of flow > > collection (.i.e field dependent and field > > independent ways). Regarding IPFIX protocol > > itself, it is a separate set of sections. > > This is just another piece in the general > > architecture. > > > > > > > > > > > > > The definition of a flow should stick to what > > > is proposed in the beggining of section 3. If > > > I'm going to use the "mother of all rule sets", > > > do it in a stepwise manner (using match or > > > filter functions), or use complex logical > > > constructs has nothing to do with the > > > architecture. > > > > These examples are used to illustrate the > > breadth of coverage of the defintion > > and has been found useful to many other people > > others in this mailing list to > > undrestand the flow definition. > > > > > > > > > > > Other comments: > > > > > > Section 3 - Typo - Phrase is repeated twice > > > > > > "Each property is defined as the result of > > > applying a function to the values of. > > > Each property is defined as the result of > > > applying a function to the values of:" > > > > Ok. > > > > > > > > > > > Section 3 - Wording > > > > > > "Each of the fields from 1., 2. > > > and 3. are referred to as flow keys." > > > > > > Not sure what are these fields you are talking > > > about...Are them the above mentioned list in > > > the text? > > > > Yes. How does this look: "Each of the fields > > from 1., > > 2. and 3. mentioned above are referred to as > > flow keys" > > > > > > > > > > > Section 3 - Wording > > > > > > "Though a flow could match a > > > general application-level end-to-end > > > stream, its definition is > > > not restricted to this alone. The above > > > definition covers a broad > > > range from a flow containing all packets > > > observed on a set of > > > observation points to a flow consisting > > > of just a single packet > > > between two applications with a specific > > > sequence number observed > > > at a single observation point." > > > > > > I think we just remove this whole text without > > > loss of generality or meaning. It seems to me > > > it is repetitive based on the fact that this is > > > already clear given the "flow keys" (1,2 and > > > 3). > > > > Yes. I had the same opinion. But again it is for > > the clarification for many > > who mistook the scope of the definition to be > > restricted to > > application-to-application. > > > > > > > > > > > Section 3. - Document structure. > > > > > > Not sure about putting flow examples in a > > > terminology section...The examples use several > > > terms that are only defined later in the text. > > > I suggest move tall the examples to a new > > > section somewhere after the terminology. > > > > This general feedback is that these examples > > improve the clarity of the > > definition. > > > > > > > > > > > Section 3 - Clarification on the match/filter > > > functions on the examples > > > > > > IMO this "match/filter" function mentioned in > > > example 2 does not belong in a architecture > > > draft. This is an implementation internal > > > decision. IMO the only think the architecture > > > document should say is that > > > > Already explained above. > > > > > > > > > > > Section 3 - Typo > > > > > > "Each of the field which belongs to" > > > > > > s/field/fields > > > > Changed to "Each of the fields which belong to" > > > > > > > > > > > Section 3 - Terminology > > > > > > " * Flow Type: > > > A function F which would take input as a > > > set of flow keys and the > > > output would be one or more flows > > > depending on the combination of > > > values for the set of flow keys." > > > > > > A set of "common properties", which the real > > > world instantion would be the so-called fields > > > already defines a flow. As mentioned in the > > > beggining of secion 3 > > > > > > "All packets belonging to > > > a particular flow have a set of common > > > properties" > > > > > > So, the notion of flow type seems redundant. If > > > its purposes in life is to justify the other > > > text in the draft which talks about > > > match/filter, is one more reason to remove this > > > definition. > > > > I think I responded on this topic sometime back > > too. > > Flow Type defines a class of flows. If F(a,b) is > > the flow type > > applying (a1,b1); (a2,b2); (a3,b3) could result > > in 1, 2 or > > 3 different flows depending on what F does. > > Where is this > > useful? This is kind of information is required > > by the collecting > > side if it needs to understand fully what is > > being done on the > > exporter side. > > > > > > > > > > > > > Section 4 - Clarification > > > > > > In general I think dwelling in the internal of > > > a device in a IETF architecture document is not > > > a good practice, but that's MHO. At least in > > > the "typical ipfix device" picture the > > > functional boxes of the "selection criteria for > > > flow export" and "metering process" should be > > > removed. It is not a process that talks to > > > external entities (a.k.a IETF Ipfix's protocol) > > > and neither has anything to do with defining a > > > flow. > > > > > > Anyway, my opinion is that we only need the > > > first picture in section 4. Everything else is > > > perfectly described in the text (section 4.1 > > > onwards). > > > > In my opinion with the picture the explanation > > looks much clearer. > > > > > > > > > > > Section 4.3 - Wording > > > > > > "The typical functions of > > > an Observation Domain may include:" > > > > > > and then > > > > > > " * May perform appropriate middle-box > > > functions to translate the > > > flow information." > > > > > > There is already a "may" on the first phrase > > > > Ok. > > > > > > > > > > > Section 4.4.1 - Typo > > > > > > " MAY need the > > > following interpreting the flow records > > > further:" > > > > > > suggestion > > > > > > "May need the following information to > > > interpret the flow records further" > > > > Ok > > > > > > > > > > > > > > Section 4.4.2. - Remove > > > > > > IMO this section has no bearing in a > > > architecture draft. It is completely an > > > implementation decision that not even affect > > > the IPfix protocol per se. > > > > explained above > > > > > > > > > > > Section 4.4.3. - Remove > > > > > > IMO this section has no bearing in a > > > architecture draft. It is completely an > > > implementation decision that not even affect > > > the IPfix protocol per se. > > > > explained above > > > > > > > > > > > Section 5.2.1 - Conflicting terms > > > > > > " As mentioned in the selection criteria, the > > > control and data stream > > > MUST be transported over a congestion-aware > > > transport protocol" > > > > Ok. How about changing this to "SHOULD". > > > > > > > > > > > In the selection criteria, ability to use a > > > congestion-aware protocol is a SHOULD. Quote > > > follows from section 5.1: > > > > > > " The following is the list of criteria that > > > the candidate protocol > > > SHOULD meet in order to be the..." > > > > > > > > > > > Section 5.2.1 - Redundancy and possible > > > conflict of terms > > > > > > " The data stream MAY be exported over an > > > reliable or unreliable > > > transport protocol." > > > > Reliability & congestion awareness are 2 > > different aspects. > > > > Thanks > > Ganesh > > > > > > > > > > > In section 5.1 congestion-aware is SHOULD, > > > later is MUST and now (section 5.2.1) is MAY. I > > > suggest removing this phrase. Everything > > > related to which protocol must be used as a > > > transport is already discussed on the beggining > > > of this section. > > > > > > regards, > > > > > > Reinaldo > > > > > > > > > > > > > > --------------770791BDE7558980ED100FFD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rienaldo,
* The text tells that it is a "typical IPFIX device"
* The diagram has blocks defined by the terminology section
   with a skeletal model of the flow collection & export path.
   I don't think this has any specific implementationd details.
Ganesh
Reinaldo Penno wrote:
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 7:33 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: [ipfix] Comments on IPFIX-architecture draft
Hi Rienaldo,
   Not really. If the definition is fairly generic (which is the case here) it is
   always useful to point out its coverage. That's what  thse examples are meant
   for. There had been a lot doubts raised on flow definition and explicitly putting
   examples can avoid a lot of mailing list traffic and for future readers.
   Having said that I am ok removing them out if that is the general consensus -
   but not because one person asserts multiple times what he does not like about
   the doc.

Reinaldo Penno wrote:

Hello Ganesh,I disagree with your statement about the examples. If people need examples to understnad the definition of a flow, then is because the definition is not clear. Instead of attacking the root cause of the problem  you are putting "paches" around it which makes the drafts full of fat.
I would be very, very surprised if this architecture draft pass last call with all the implementation specific details it has justified under the "readability" umbrella. I've never seen an IETF architecture draft saying how many process I should code to realize some task, what they should do, etc, etc,
And where is all these details of "how many process I should code to realize some task"
in the arch. spec? In the part where you say what the meter should do, the exported should do, and how is the internal organization of a exporter. I believe this is implementaion specific, isn't it?
 
 
 

I understand that some people get attached to their drafts but if you rip those sessions of and read the draft again you will see that nothing is lost, and is much more objective and charter compliant.regards,Reinaldo

This doc. is not my property it is a effort from a group of  contributors. So what goes in
would be what is the "rough consensus" & not a single person's opinion.
BTW I would appreciate if you can avoid personal references. Ganesh, don't be so sensitive.  I meant "you" generally. Besides I wonder why you ask me that if you said previously "but not because one person asserts multiple times". But that's okay...-Reinaldo
 

Thanks
Ganesh

 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, June 04, 2002 6:04 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: ipfix@net.doit.wisc.edu; kcn@norseth.com
Subject: Re: [ipfix] Comments on IPFIX-architecture draft
Hello Reinaldo,

Reinaldo Penno wrote:

 

Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this.

General:

My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have).

What is the  implementation (or design) specific details you are referring to?
These are just 2 broad catgories of flow collection (.i.e field dependent and field
independent ways). Regarding IPFIX protocol itself, it is a separate set of sections.
This is just another piece in the general architecture.
 
 

The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture.

These examples are used to illustrate the breadth of coverage of the defintion
and has been found useful to many other people others in this mailing list to
undrestand the flow definition.
 

Other comments:

Section 3 - Typo - Phrase is repeated twice

"Each property is defined as the result of applying a function to the values of.
Each property is defined as the result of applying a function to the values of:"

Ok.
 

Section 3 - Wording

"Each of the fields from 1., 2.
       and 3. are referred to as flow keys."

Not sure what are these fields you are talking about...Are them the above mentioned list in the text?

Yes.  How does this look:  "Each of the fields from 1.,
2. and 3. mentioned above are referred to as flow keys"
 

Section 3 - Wording

"Though a flow could match a
       general application-level end-to-end stream, its definition is
       not restricted to this alone. The above definition covers a broad
       range from a flow containing all packets observed on a set of
       observation points to a flow consisting of just a single packet
       between two applications with a specific sequence number observed
       at a single observation point."

I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3).

Yes. I had the same opinion. But again it is for the clarification for many
who mistook the scope of the definition to be restricted to
application-to-application.
 

Section 3. - Document structure.

Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology.

This general feedback is that these examples improve the clarity of the
definition.
 

Section 3 - Clarification on the match/filter functions on the examples

IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that

Already explained above.
 

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

Changed to "Each of the fields which belong to"
 

Section 3 - Terminology

"   * Flow Type:
       A function F which would take input as a set of flow keys and the
       output would be one or more flows depending on the combination of
       values for the set of flow keys."

A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3

"All packets belonging to
       a particular flow have a set of common properties"

So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition.

I think I responded on this topic sometime back too.
Flow Type defines a class of flows. If F(a,b) is the flow type
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or
3 different flows depending on what F does. Where is this
useful? This is kind of information is required by the collecting
side if it needs to understand fully what is being done on the
exporter side.
 
 

Section 4 - Clarification

In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed.  It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow.

Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards).

In my opinion with the picture the explanation looks much clearer.
 

Section 4.3 - Wording

"The typical functions of
   an Observation Domain may include:"

and then

"    * May perform appropriate middle-box functions to translate the
       flow information."

There is already a "may" on the first phrase

Ok.
 

Section 4.4.1 - Typo

" MAY need the
   following interpreting the flow records further:"

suggestion

"May need the following information to interpret the flow records further"

Ok
 
 

Section 4.4.2. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 4.4.3. - Remove

IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se.

explained above
 

Section 5.2.1 - Conflicting terms

"   As mentioned in the selection criteria, the control and data stream
   MUST be transported over a congestion-aware transport protocol"

Ok. How about changing this to "SHOULD".
 

In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1:

"   The following is the list of criteria that the candidate protocol
   SHOULD meet in order to be the..."

 

Section 5.2.1 - Redundancy and possible conflict of terms

"   The data stream MAY be exported over an reliable or unreliable
   transport protocol."

Reliability & congestion awareness are 2 different aspects.

Thanks
Ganesh

 

In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section.

regards,

Reinaldo
 
 
 
 

--------------770791BDE7558980ED100FFD-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jun 6 02:41:49 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29953 for ; Thu, 6 Jun 2002 02:41:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17FqeC-0000he-00 for ipfix-list@mil.doit.wisc.edu; Thu, 06 Jun 2002 01:21:24 -0500 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17FqeA-0000gT-00 for ipfix@net.doit.wisc.edu; Thu, 06 Jun 2002 01:21:22 -0500 Received: (qmail 15264 invoked from network); 6 Jun 2002 06:20:47 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 6 Jun 2002 06:20:47 -0000 Received: from Kevinz (slip-32-102-142-8.md.us.prserv.net [32.102.142.8]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g566Ls407006; Wed, 5 Jun 2002 23:21:54 -0700 Reply-To: From: "kevin.zhang" To: "Ganesh Sadasivan" , Cc: Subject: RE: [ipfix] architecture draft Date: Thu, 6 Jun 2002 02:22:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CFEBE4D.60D398F@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA29953 Hi Ganesh, Please see my comments below. Thanks, Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Ganesh Sadasivan > Sent: Wednesday, June 05, 2002 9:44 PM > To: n.brownlee@auckland.ac.nz > Cc: ipfix@net.doit.wisc.edu > Subject: [ipfix] architecture draft > > > Hi Nevil, > > n.brownlee@auckland.ac.nz wrote: > > > Hello Ganesh: > > > > > > > > > > > > > I've read the list messages about the Architecture draft. By and large > > I agree with you, at this stage extra illustrative material is helpful. > > Once we've selected a protocol, I expect that we'll want to rework the > > architecture draft to be sure it covers the chosen protocol; that will > > be the right time to think about which parts - if any - are superfluous. > > Agreed. > > > > > > > Wrt one of your comments, section 5.2.1 is correct when it says IPFIX > > control and data streams MUST be transported over a congestion-aware > > protocol. That's an IETF consensus, which the IESG reminded us about by > > putting it into the IPFIX charter. > > After re-reading the text, the confusion is because in section 5.1, it is > stated that "The following is the list of criteria that the > candidate protocol > SHOULD meet in order to be the qualified into the IPFIX architecture" > which is true because we did not find an exact match of what we want > and are in the process of choosing the one which matches the most. > So "SHOULD" is applicable to the total of all the selection criteria. So > I'll leave the text as it is. If everything is optional as indicated by "SHOULD". What are the criteria we are talking about. The core of the architecture draft should provide a high level guidance of the design of the IPFIX system, primarily the IPFIX protocol. I believe now is a good time to separte hard boundaries (MUST) from soft ones (SHOULD). As lengthy debate about the transport protocol has taken place, and a decision was made in Minn., Let's make congestion-aware protocol a MUST. > > > > > > > Also, I was re-reading the Minneapolis minutes; in the discussion there > > 'Control Stream' was considered to be confusing, there was consensus for > > 'Data Description' instead. > > > > "Data description" does not fully convey all the control > information. There > could be messages like "Keepalives" which is part of the control and > has nothing to do with "Data Description". Can we settle for "Control Information" for now as the term is generic enough to meet our needs. We can later enumerate what consists of control information, e.g. keepalives, data descriptions, capability indications, etc. > > Thanks > Ganesh > > > > > Cheers, Nevil > > > > ----------------------------------------------------------------------- > > Nevil Brownlee Director, Technology Development > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Mon Jun 10 10:52:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06880 for ; Mon, 10 Jun 2002 10:51:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HQ5a-00026k-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Jun 2002 09:24:10 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HQ5Y-00026C-00 for ipfix@net.doit.wisc.edu; Mon, 10 Jun 2002 09:24:08 -0500 Received: from riverstonenet.com ([134.141.180.77]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 07:23:35 -0700 Message-ID: <3D04B61C.1432F9C2@riverstonenet.com> Date: Mon, 10 Jun 2002 10:22:20 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Reinaldo Penno , ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft References: <7B802811BE77D51189910002A55CFD2C02A1A07F@zsc3c032.us.nortel.com> <3CFD785A.A7F02A20@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2002 14:23:36.0221 (UTC) FILETIME=[685C5CD0:01C2108A] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I for one think examples lend to clarity in a way that pure textual description cannot. See RFC 3031, the MPLS architecture document as one RFC that does this. Also look at RFC 826 the ARP protocol. They give pseudocode in their description. My 2 cents, Paul -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jun 10 15:01:05 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19507 for ; Mon, 10 Jun 2002 15:01:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HTpg-0007Mq-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Jun 2002 13:24:00 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112] helo=zrc2s0jx.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HTpe-0007Ly-00 for ipfix@net.doit.wisc.edu; Mon, 10 Jun 2002 13:23:58 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AIJlc03215; Mon, 10 Jun 2002 13:19:47 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 11:19:31 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C02AE838D@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Ganesh Sadasivan Cc: ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: RE: [ipfix] Comments on IPFIX-architecture draft Date: Mon, 10 Jun 2002 11:19:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210AB.5D4FFB50" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210AB.5D4FFB50 Content-Type: text/plain; charset="ISO-8859-1" well, there also tons other of RFCs that are objective and clean. Not to mention that I haven't seen many RFCs with pseudo code. Pseudo code (or actually code) is typical of ITU-T. Anyway, consensus & last call will decide. -Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Monday, June 10, 2002 7:22 AM >To: Ganesh Sadasivan >Cc: Penno, Reinaldo [SC101:T327:EXCH]; ipfix@net.doit.wisc.edu; >kcn@norseth.com >Subject: Re: [ipfix] Comments on IPFIX-architecture draft > > > >I for one think examples lend to clarity in a way that pure >textual description cannot. See RFC 3031, the MPLS architecture >document as one RFC that does this. Also look at RFC 826 >the ARP protocol. They give pseudocode in their description. > >My 2 cents, > >Paul > ------_=_NextPart_001_01C210AB.5D4FFB50 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Comments on IPFIX-architecture draft

well,

there also tons other of RFCs that are objective and = clean. Not to mention that I haven't seen many RFCs with pseudo code. = Pseudo code (or actually code) is typical of ITU-T.

Anyway, consensus & last call will decide.

-Reinaldo



>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Monday, June 10, 2002 7:22 AM
>To: Ganesh Sadasivan
>Cc: Penno, Reinaldo [SC101:T327:EXCH]; = ipfix@net.doit.wisc.edu;
>kcn@norseth.com
>Subject: Re: [ipfix] Comments on = IPFIX-architecture draft
>
>
>
>I for one think examples lend to clarity in a = way that pure
>textual description cannot. See RFC 3031, the = MPLS architecture
>document as one RFC that does this. Also look at = RFC 826
>the ARP protocol. They give pseudocode in their = description.
>
>My 2 cents,
>
>Paul
>

------_=_NextPart_001_01C210AB.5D4FFB50-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 09:30:01 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23073 for ; Tue, 11 Jun 2002 09:30:00 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HlD7-000262-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 07:57:21 -0500 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HlD5-000257-00 for ipfix@net.doit.wisc.edu; Tue, 11 Jun 2002 07:57:19 -0500 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.11.6+Sun/CA/950118) id g5BCuYn25448; Tue, 11 Jun 2002 14:56:34 +0200 (CEST) Date: Tue, 11 Jun 2002 14:56:34 +0200 (CEST) From: Benoit Claise Message-Id: <200206111256.g5BCuYn25448@bru-cse-222.cisco.com> To: calato@riverstonenet.com, gsadasiv@cisco.com, reinaldo_penno@nortelnetworks.com Subject: RE: [ipfix] Comments on IPFIX-architecture draft Cc: ipfix@net.doit.wisc.edu, kcn@norseth.com X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver > > well, > > there also tons other of RFCs that are objective and clean. Not to mention > that I haven't seen many RFCs with pseudo code. Pseudo code (or actually > code) is typical of ITU-T. > > Anyway, consensus & last call will decide. If you're doing a poll about those examples, I'm convinced that they help. Regarding references to the code, well ... they are only examples after all! Regards, Benoit. > > -Reinaldo > > > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Monday, June 10, 2002 7:22 AM > >To: Ganesh Sadasivan > >Cc: Penno, Reinaldo [SC101:T327:EXCH]; ipfix@net.doit.wisc.edu; > >kcn@norseth.com > >Subject: Re: [ipfix] Comments on IPFIX-architecture draft > > > > > > > >I for one think examples lend to clarity in a way that pure > >textual description cannot. See RFC 3031, the MPLS architecture > >document as one RFC that does this. Also look at RFC 826 > >the ARP protocol. They give pseudocode in their description. > > > >My 2 cents, > > > >Paul > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 10:49:34 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27309 for ; Tue, 11 Jun 2002 10:49:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HmfQ-0004Qw-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 09:30:40 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HmfO-0004QL-00 for ipfix@net.doit.wisc.edu; Tue, 11 Jun 2002 09:30:38 -0500 Received: from riverstonenet.com ([134.141.180.87]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 07:30:04 -0700 Message-ID: <3D060921.3328E266@riverstonenet.com> Date: Tue, 11 Jun 2002 10:28:49 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: IPFIX Subject: Re: [ipfix] draft-ietf-ipfix-data-01.txt References: <022301c2085a$01f66900$850f880a@kcn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2002 14:30:04.0895 (UTC) FILETIME=[7A710EF0:01C21154] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > 5.1. Flow Classification > > The collector MUST be able to map the flow to the corresponding > property types defined by the flow type. This can be done only if > the collector has a mapping from flow type identifier (carried in > each flow record) to its actual structure. More details of how > this can be achieved are described in section 5.??? > > > In addition the collector, when it receives the flow records, MAY > need the following to interpret the flow records further: > > A. Observation Point. > B. Selection Criteria of Packets > > As mentioned in section 2.1, a flow record can be better analyzed > if the Observation Point from which it is measured is known. As > such it is recommended that the flow record carry the Observation > Point information along with the flow records when exported. In > cases where there is a single observation point or where the > observation point information is not relevant, the exporter MAY > choose not to add this to the flow records. > I don't understand this section. What is flow classification? Also, A flow should be able to be interpreted regardless of knowing the observation point. A single observation point may map flows in 2 or more different ways. The fact that different observation points map flows based on different criteria is irrelevant. All the information needed to interpret the flow must be passed up. > 5.2.1. Function on properties that determines a flow type (Fi) > > Packets that satisfy a function on the fields defined by the > packet header fields or fields obtained while doing the packet > processing or the properties of the packet itself. > > Example: > > Mask/Match of the fields that define a filter. The filter may be > defined as {Protocol == TCP, Destination Port between 80 and 120}. > > > could be used in any sequence to select > packets. > I think it would it be better to say "Multiple such functions" instead of filters? > 5.3. Selection Criteria for flows for export > > The measurement device MAY define additional rules so that only > certain flows records are picked up for export. This MAY be done > by either of the two types of methods defined in 5.2.1 and > 5.2.2 or a combination of them. > > Example: > > Only the flow records which meet the following selection criteria > are exported. > > 1 All flow records whose destination IP address matches > {20.3.1.5}. > 2 Every other (.i.e. sampling rate 1 in 2) flow record whose > destination IP address matches {160.0.1.30}. > I'm not sure I agree with this. I think you have defined 2 flows in #1 and #2. Given that, both flows are exported. I think maybe the "Selection Criteria" is really part of the Flow Type. > * Packet Counter > * Dropped Packet Counter > * Byte Counter > * Dropped Byte Counter > * Timestamp of the First Packet Observed > * Timestamp of the Last Packet Observed Generally the last time stamp is the time at which the flow has expired (as described earlier). The last packet observed is not available unless each packet is processed in software. So either we need another field or a different definition. > > * Unique ID of the Observation Point > * Unique ID of the Measuring Device As stated above, I disagree that these are part of flow definition. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 10:49:34 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27310 for ; Tue, 11 Jun 2002 10:49:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HmbW-0004Hr-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 09:26:38 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HmbU-0004Gx-00 for ipfix@net.doit.wisc.edu; Tue, 11 Jun 2002 09:26:36 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5BEQ5829460 for ; Tue, 11 Jun 2002 16:26:05 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA26149 for ; Tue, 11 Jun 2002 16:21:53 +0200 Date: Tue, 11 Jun 2002 16:21:53 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] new requirements I-D draft-ietf-ipfix-reqs-03.txt Message-ID: <29806098.1023812513@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I just submitted a new version of the requirements I-D to the IETF I-D repository. You can preview it at http://www.ccrle.nec.de/draft-ietf-ipfix-reqs-03.txt All authors are rather content with the current state, but please do not hesitate to comment on it. Minor issues left are - Should the appendix be deleted? - Shall we call it "export process" or "exporting process"? - The current definition of "observation point" says that coarse-granular observation points may include fine-granular observation points. Is this view agreed? - ... Please feel free to add to this list. Best regards, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 11:48:38 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29906 for ; Tue, 11 Jun 2002 11:48:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17Hnal-0005lY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 10:29:55 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17Hnaj-0005kg-00 for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 10:29:53 -0500 Received: from riverstonenet.com ([134.141.180.87]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 08:28:14 -0700 Message-ID: <3D0616C3.EF28D231@riverstonenet.com> Date: Tue, 11 Jun 2002 11:26:59 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tanja Zseby CC: req Subject: Re: [ipfix-req] security considerations - resend References: <3CE517B7.4020104@fokus.fhg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2002 15:28:14.0665 (UTC) FILETIME=[9A81B390:01C2115C] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja Zseby wrote: > > Hi Benoit, > > here comes the new security considerations section. I integrated > comments from Sebastian and Carter. > > Regards > Tanja > > 9. Security considerations > > The future IPFIX protocol must be capable to transport data over the > public Internet. Therefore it cannot be excluded that an attacker > captures or modifies exchanged packets or inserts additional packets. > This document describes requirements for IP Flow Information Export > (IPFIX). It therefore also states the required security features for a > future IPFIX protocol. Like other requirements, the security > requirements differ for the considered applications. The incentive to > modify collected data for accounting or intrusion detection for instance > is usually higher than the incentive to change data collected for > traffic profiling. Therefore the required security features in this > document are listed per application in the appendix. > The suggestion of concrete solutions for achieving the required security > properties will be part of the IPFIX architecture and protocol > description and is out of scope of this document. Furthermore, methods > for remote configuration of the IPFIX processes are out of scope for > IPFIX. Therefore, threads that are caused by data exchange for remote > configuration are not considered here. > > The following potential security hazards for an IPFIX protocol can be > identified: > > - Disclosure of IP flow information data > The content of data exchanged by the IPFIX protocol (e.g. IPFIX flow > records) should be kept confidential between the involved parties > (exporting process and colleting process). Observation of IPFIX flow > records gives an attacker information about the active flows in the > network, communication endpoints and traffic patterns. This information > cannot only be used to spy out user behavior but also to plan and > conceal future attacks. Therefore the requirements document recommends > to ensure the confidentiality of the transferred data. This can be > achieved for instance by encryption. > > - Forgery of IPFIX flow records > Because of the potential uses of IPFIX flow records in accounting and > security applications, there are strong incentives to forge exported > IPFIX flow records (e.g. to save money or prevent the detection of an > attack). This can be done either by altering flow records on the path or > by injecting forged flow records that pretend to be originated by the > original exporting process. In order to make the IPFIX protocol > resistant against such attacks this document requires to ensure > authenticity and integrity for the IPFIX data transfer. > Special caution is required if security applications rely on IPFIX data. > With forged flow records it is possible to trick on security > applications. It is for instance possible to pretend that a DoS attack > happens without even launching a real attack. > > - Denial of Service (DoS) attacks > DoS attacks on routers or other middleboxes that have the IPFIX protocol > implemented would also affect the IPFIX protocol and impair the sending > of IPFIX records. Nevertheless, since such hazards are not induced > specifically by the IPFIX protocol the prevention of such attacks is out > of scope of this document. > Nevertheless IPFIX itself also causes potential hazards for DoS attacks. > All processes that expect the reception of traffic can be target of a > DoS attack. With the IPFIX exporting process this is only the case if it > supports the pull mode (which can be an optional feature of the future > IPFIX protocol according to this document). The collecting process > always expects data and therefore can be flooded by forged flow records. > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > 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) > -------------------------------------------------------------------------------------- > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 13:29:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04240 for ; Tue, 11 Jun 2002 13:29:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HpG8-0000HB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 12:16:44 -0500 Received: from smtp.slac.stanford.edu ([134.79.18.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HpG6-0000H4-00 for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 12:16:42 -0500 Received: from CONVERSION-DAEMON.smtp.slac.stanford.edu by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) id <0GXJ00401XBS1P@smtp.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 10:16:40 -0700 (PDT) Received: from smtpserv1.SLAC.Stanford.EDU (SMTPSERV1.SLAC.Stanford.EDU [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) with ESMTP id <0GXJ001DJXBSXF@smtp.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 10:16:40 -0700 (PDT) Received: from ATREUS.slac.stanford.edu ([134.79.18.84]) by smtpserv1.slac.stanford.edu (PMDF V6.1 #37665) with ESMTP id <0GXJ00MDFXBSHB@smtpserv1.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 10:16:40 -0700 (PDT) Received: by ATREUS.slac.stanford.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 10:16:39 -0700 Content-return: allowed Date: Tue, 11 Jun 2002 10:16:38 -0700 From: "Cottrell, Les" Subject: [ipfix-req] Ipfix features To: req Cc: "Logg, Connie A." Message-id: <2846497B437BF84BAD1A4CC407418D260148DA7E@exchange1.slac.stanford.edu> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT I hope this is not too off-subject, but in future realeases of ipfix ttols such as Netflow, I would like to see: Max window size reported Correct handling of fragmented packets -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 13:44:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04862 for ; Tue, 11 Jun 2002 13:44:06 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17HpVf-0000dI-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 12:32:47 -0500 Received: from h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17HpVd-0000ch-00 for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 12:32:45 -0500 Received: (cpmta 23107 invoked from network); 11 Jun 2002 10:32:13 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.114) with SMTP; 11 Jun 2002 10:32:13 -0700 X-Sent: 11 Jun 2002 17:32:13 GMT Message-ID: <00aa01c2116e$0da977c0$850f880a@kcn> From: "K.C. Norseth" To: "Cottrell, Les" , "req" Cc: "Logg, Connie A." References: <2846497B437BF84BAD1A4CC407418D260148DA7E@exchange1.slac.stanford.edu> Subject: Re: [ipfix-req] Ipfix features Date: Tue, 11 Jun 2002 11:33:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Discusssion is healthy. Please elaborate on what you mean. K.C. ----- Original Message ----- From: "Cottrell, Les" To: "req" Cc: "Logg, Connie A." Sent: Tuesday, June 11, 2002 11:16 AM Subject: [ipfix-req] Ipfix features | I hope this is not too off-subject, but in future realeases of ipfix ttols such as Netflow, I would like to see: | | Max window size reported | Correct handling of fragmented packets | | -- | Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say | "unsubscribe ipfix" in message body | Archive http://ipfix.doit.wisc.edu/archive/ | -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 15:18:33 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08812 for ; Tue, 11 Jun 2002 15:18:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17Hqya-0002fR-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 14:06:44 -0500 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com ident=exim) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17HqyZ-0002fK-00 for ipfix@net.doit.wisc.edu; Tue, 11 Jun 2002 14:06:43 -0500 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HqyU-0002is-00; Tue, 11 Jun 2002 12:06:38 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Benoit Claise Cc: calato@riverstonenet.com, gsadasiv@cisco.com, reinaldo_penno@nortelnetworks.com, ipfix@net.doit.wisc.edu, kcn@norseth.com Subject: RE: [ipfix] Comments on IPFIX-architecture draft References: <200206111256.g5BCuYn25448@bru-cse-222.cisco.com> Message-Id: Date: Tue, 11 Jun 2002 12:06:38 -0700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Regarding references to the code, well ... they are only examples after all! http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt randy -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 18:23:36 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15020 for ; Tue, 11 Jun 2002 18:23:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17Htfi-0006PY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 16:59:26 -0500 Received: from smtp.slac.stanford.edu ([134.79.18.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17Htff-0006PP-00 for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 16:59:23 -0500 Received: from CONVERSION-DAEMON.smtp.slac.stanford.edu by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) id <0GXK00M01AEXTC@smtp.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 14:59:22 -0700 (PDT) Received: from smtpserv1.SLAC.Stanford.EDU (SMTPSERV1.SLAC.Stanford.EDU [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) with ESMTP id <0GXK00JKBAEXTE@smtp.slac.stanford.edu>; Tue, 11 Jun 2002 14:59:21 -0700 (PDT) Received: from ATREUS.slac.stanford.edu ([134.79.18.84]) by smtpserv1.slac.stanford.edu (PMDF V6.1 #37665) with ESMTP id <0GXK00EPHAEX9H@smtpserv1.slac.stanford.edu>; Tue, 11 Jun 2002 14:59:21 -0700 (PDT) Received: by ATREUS.slac.stanford.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 14:59:19 -0700 Content-return: allowed Date: Tue, 11 Jun 2002 14:59:19 -0700 From: "Cottrell, Les" Subject: RE: [ipfix-req] Ipfix features To: "'K.C. Norseth'" , req Cc: "Logg, Connie A." Message-id: <2846497B437BF84BAD1A4CC407418D260148DA7F@exchange1.slac.stanford.edu> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT I would guess the closest I will get to max window size would be to report the window scaling option factor and window size specified in the SYN and SYN/ACK when a TCP flow is opened. NETFLOW appears to look at each packet seprately, thus if a packet is not the first of a fragmentation set, then Netflow reports spurious port numbers etc. For applications such as AFS which uses UDP with big block sizes this makes it hard to identify the amount of AFS traffic. > -----Original Message----- > From: K.C. Norseth [mailto:kcn@norseth.com] > Sent: Tuesday, June 11, 2002 10:33 AM > To: Cottrell, Les; req > Cc: Logg, Connie A. > Subject: Re: [ipfix-req] Ipfix features > > > Discusssion is healthy. Please elaborate on what you mean. > > K.C. > ----- Original Message ----- > From: "Cottrell, Les" > To: "req" > Cc: "Logg, Connie A." > Sent: Tuesday, June 11, 2002 11:16 AM > Subject: [ipfix-req] Ipfix features > > > | I hope this is not too off-subject, but in future realeases > of ipfix > | ttols > such as Netflow, I would like to see: > | > | Max window size reported > | Correct handling of fragmented packets > | > | -- > | Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message > body > | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > | ipfix" in message body > | Archive http://ipfix.doit.wisc.edu/archive/ > | > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 11 18:26:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15086 for ; Tue, 11 Jun 2002 18:26:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17Hth7-0006UV-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Jun 2002 17:00:53 -0500 Received: from smtp.slac.stanford.edu ([134.79.18.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17Hth5-0006UL-00 for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 17:00:51 -0500 Received: from CONVERSION-DAEMON.smtp.slac.stanford.edu by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) id <0GXK00M01AHDXC@smtp.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Tue, 11 Jun 2002 15:00:50 -0700 (PDT) Received: from smtpserv1.SLAC.Stanford.EDU (SMTPSERV1.SLAC.Stanford.EDU [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) with ESMTP id <0GXK00JKVAHDTI@smtp.slac.stanford.edu>; Tue, 11 Jun 2002 15:00:49 -0700 (PDT) Received: from ATREUS.slac.stanford.edu ([134.79.18.84]) by smtpserv1.slac.stanford.edu (PMDF V6.1 #37665) with ESMTP id <0GXK00G0TAHDPD@smtpserv1.slac.stanford.edu>; Tue, 11 Jun 2002 15:00:49 -0700 (PDT) Received: by ATREUS.slac.stanford.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 15:00:47 -0700 Content-return: allowed Date: Tue, 11 Jun 2002 15:00:47 -0700 From: "Cottrell, Les" Subject: RE: [ipfix-req] Ipfix features To: "'K.C. Norseth'" , req Cc: "Logg, Connie A." Message-id: <2846497B437BF84BAD1A4CC407418D260148DA80@exchange1.slac.stanford.edu> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT As an example of IP fragmentation see: http://www.slac.stanford.edu/comp/net/netflow/afsexample.html > -----Original Message----- > From: K.C. Norseth [mailto:kcn@norseth.com] > Sent: Tuesday, June 11, 2002 10:33 AM > To: Cottrell, Les; req > Cc: Logg, Connie A. > Subject: Re: [ipfix-req] Ipfix features > > > Discusssion is healthy. Please elaborate on what you mean. > > K.C. > ----- Original Message ----- > From: "Cottrell, Les" > To: "req" > Cc: "Logg, Connie A." > Sent: Tuesday, June 11, 2002 11:16 AM > Subject: [ipfix-req] Ipfix features > > > | I hope this is not too off-subject, but in future realeases > of ipfix > | ttols > such as Netflow, I would like to see: > | > | Max window size reported > | Correct handling of fragmented packets > | > | -- > | Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message > body > | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > | ipfix" in message body > | Archive http://ipfix.doit.wisc.edu/archive/ > | > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jun 12 12:55:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04649 for ; Wed, 12 Jun 2002 12:55:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17IAxW-0000oc-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Jun 2002 11:26:58 -0500 Received: from login.caida.org ([192.172.226.78]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17IAxU-0000oX-00 for ipfix-req@net.doit.wisc.edu; Wed, 12 Jun 2002 11:26:56 -0500 Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.1/8.12.1) with ESMTP id g5CGQtrx079448 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 12 Jun 2002 09:26:55 -0700 (PDT) Received: (from dmoore@localhost) by login.caida.org (8.12.1/8.12.1/Submit) id g5CGQtbO079447 for ipfix-req@net.doit.wisc.edu; Wed, 12 Jun 2002 09:26:55 -0700 (PDT) Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.1/8.12.1) with ESMTP id g5CGCArx079142 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jun 2002 09:12:10 -0700 (PDT) Received: (from dmoore@localhost) by login.caida.org (8.12.1/8.12.1/Submit) id g5CGCA6D079141; Wed, 12 Jun 2002 09:12:10 -0700 (PDT) Date: Wed, 12 Jun 2002 09:12:10 -0700 From: David Moore To: "Cottrell, Les" Cc: "'K.C. Norseth'" , req , "Logg, Connie A." , colleen , dm Subject: Re: [cottrell@SLAC.Stanford.EDU: RE: [ipfix-req] Ipfix features] Message-ID: <20020612091210.W84415@login.caida.org> References: <20020611233538.A71948@caida.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020611233538.A71948@caida.org> User-Agent: Mutt/1.3.23i X-Spam-Status: No, hits=-5.0 required=8.0 tests=IN_REP_TO version=2.11 Precedence: bulk Sender: majordomo listserver This may be difficult to get "correct". I assume correct means something roughly like: 1. maintain state to determine what ports apply for a non-first fragmented packet. 2. once a fragmented packet's ports are determined, add it into the flow it would have gone into if it had ports. A few comments: A separate fragment/ipid timer would be needed to decide when to expire the state. RFC 791 recommends 15 seconds, which also seems to match reasonably well with caida network measurements. Fragments may come in any order (in particular linux sends them from the back of the original packet backwards towards the front). This means that you may see a fragment w/o port information before you see the corresponding port information. So you can't determine which flow the fragment belongs to until a later point. VPN and tunnel's cause a lot of fragmented traffic, which may occur at high-speed depending on the endpoints, which may result in a lot of state being needed. A good garbage collection scheme may be needed for this (as well as DoS attacks with fragmented packets). Personally, I'd also like a flow field saying whether the packet was fragmented or not. So fragmented packets to/from host/port & proto would be counted as a separate flow from non-fragmented packets to/from host/port & proto. This would be in addition to any attempts to correctly assign ports to fragments. -- david ----- Forwarded message from "Cottrell, Les" ----- Date: Tue, 11 Jun 2002 15:00:47 -0700 From: "Cottrell, Les" Subject: RE: [ipfix-req] Ipfix features To: "'K.C. Norseth'" , req Cc: "Logg, Connie A." X-Mailer: Internet Mail Service (5.5.2653.19) As an example of IP fragmentation see: http://www.slac.stanford.edu/comp/net/netflow/afsexample.html > -----Original Message----- > From: K.C. Norseth [mailto:kcn@norseth.com] > Sent: Tuesday, June 11, 2002 10:33 AM > To: Cottrell, Les; req > Cc: Logg, Connie A. > Subject: Re: [ipfix-req] Ipfix features > > > Discusssion is healthy. Please elaborate on what you mean. > > K.C. > ----- Original Message ----- > From: "Cottrell, Les" > To: "req" > Cc: "Logg, Connie A." > Sent: Tuesday, June 11, 2002 11:16 AM > Subject: [ipfix-req] Ipfix features > > > | I hope this is not too off-subject, but in future realeases > of ipfix > | ttols > such as Netflow, I would like to see: > | > | Max window size reported > | Correct handling of fragmented packets > | > | -- > | Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message > body > | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > | ipfix" in message body > | Archive http://ipfix.doit.wisc.edu/archive/ > | > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ ----- End forwarded message ----- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jun 12 12:56:23 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04679 for ; Wed, 12 Jun 2002 12:56:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17IAtM-0000k4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Jun 2002 11:22:40 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17IAtI-0000jy-00 for ipfix-req@net.doit.wisc.edu; Wed, 12 Jun 2002 11:22:37 -0500 Received: from fokus.fhg.de (dhcp227 [195.37.78.227]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g5CGMYh05696; Wed, 12 Jun 2002 18:22:34 +0200 (MEST) Message-ID: <3D077505.4000002@fokus.fhg.de> Date: Wed, 12 Jun 2002 18:21:25 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=FCrgen?= Quittek CC: IPFIX Requirements <" ipfix-req"@net.doit.wisc.edu> Subject: [ipfix-req] [Fwd: Re: version 3 of IPFIX requirements] Content-Type: multipart/mixed; boundary="------------090501090709020308030708" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------090501090709020308030708 Content-Type: multipart/alternative; boundary="------------050800060908020708090607" --------------050800060908020708090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id g5CGMYh05696 Content-Transfer-Encoding: quoted-printable Hi J=FCrgen, it seems that something went wrong when I did send my comments to the=20 requirements draft :-(=20 (maybe because I did sent it from at home... I did not get an error from=20 my mailtool, but it might have been caused by an unlucky combination of=20 my virus scanner and zone alarm... ) I had a lot of comments to the version. So I attached it again to this ma= il. Maybe we can make further version and also include the comments that=20 were send on the list during the last days ? Also if there are further comments from others they would have a last=20 chance to contribute and send comments.=20 Regards Tanja -------- Original Message -------- Message-ID: <3CFFCE4E.4010008@fokus.fhg.de> Date: Thu, 06 Jun 2002 23:04:14 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)=20 Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , Tanja Zseby =20 , Sebastian Zander , Georg Carle=20 , "K.C. Norseth" ,=20 n.brownlee@auckland.ac.nz , plonka@doit.wisc.edu Subject: Re: version 3 of IPFIX requirements References: <2900931.1019814195@[192.168.102.164]>=20 <4782386.1023358227@[192.168.102.164]> Content-Type: multipart/mixed;=20 boundary=3D"------------090503030107020006050100" Dear J=FCrgen, I read through the requirements draft and inserted my commnents in the=20 document (marked with //TZS: ). It is mainly minor rephrasing and some typos. I attached the edited=20 document. One major point is that I still have problems with the beginning of=20 section 6.3. (data transfer). I know we already discussed this several=20 times... Please have a look at the extendended comment and proposed=20 changes for this section in the document. Furthermore it would be good if somebody reads the security=20 considerations. Until now I only got some minor comments from Carter and=20 Sebastian ... Regards Tanja P.S.: I really like the new section. with the pictures.. Juergen Quittek wrote: > Dear all, > > Attached please find a new version of the IPFIX requirements > draft based on our discussion on May 17. Please have a look > at it and send comments until Saturday. > > I plan to submit the new version to the IETF on Monday, if we > can agree on the draft until then. > > I have not yet read carefully the new security considerations. > Also, the appendix with the application requirements table > is still missing. I will include it over the weekend. > > Tanja or Sebastian, can one of you send me the source file > of draft version 2? > > Cheers, > > Juergen > > --=20 Dipl.-Ing. Tanja Zseby =09 FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de=09 Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------= -------------=20 "Living on earth is expensive but it includes a free trip around the sun.= " (Anonymous) -------------------------------------------------------------------------= ------------- --------------050800060908020708090607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jürgen,

 it seems that something went wrong when I did send my comments to the requirements draft :-( 
(maybe because I did sent it from at home... I did not get an error from my mailtool, but it might have been caused by an unlucky combination of my virus scanner and zone alarm... )

I had a lot of comments to the version. So I attached it again to this mail.
Maybe we can make further version and also include the comments that were send on the list during the last days ?
Also if there are further comments from others they would have a last chance to contribute and send comments. 

Regards
Tanja

-------- Original Message --------
Message-ID: <3CFFCE4E.4010008@fokus.fhg.de>
Date: Thu, 06 Jun 2002 23:04:14 +0200
From: Tanja Zseby <zseby@fokus.fhg.de>
Organization: FhI FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Juergen Quittek <quittek@ccrle.nec.de>
CC: Benoit Claise <bclaise@cisco.com> , Tanja Zseby <zseby@fokus.gmd.de> , Sebastian Zander <zander@fokus.gmd.de> , Georg Carle <carle@fokus.gmd.de> , "K.C. Norseth" <kcn@norseth.com> , n.brownlee@auckland.ac.nz , plonka@doit.wisc.edu
Subject: Re: version 3 of IPFIX requirements
References: <2900931.1019814195@[192.168.102.164]> <4782386.1023358227@[192.168.102.164]>
Content-Type: multipart/mixed; boundary="------------090503030107020006050100"


Dear Jürgen,

I read through the requirements draft and inserted my commnents in the document (marked with //TZS: ).
It is mainly minor rephrasing and some typos. I attached the edited document.
One major point is that I still  have problems with the beginning  of section 6.3. (data transfer). I know we already discussed this several times... Please have a look at the extendended comment and proposed changes for this section in the document.
Furthermore it would be good if somebody reads the security considerations. Until now I only got some minor comments from Carter and Sebastian ...

Regards
Tanja
P.S.: I really like the new section. with the pictures..

Juergen Quittek wrote:
Dear all,

Attached please find a new version of the IPFIX requirements
draft based on our discussion on May 17. Please have a look
at it and send comments until Saturday.

I plan to submit the new version to the IETF on Monday, if we
can agree on the draft until then.

I have not yet read carefully the new security considerations.
Also, the appendix with the application requirements table
is still missing. I will include it over the weekend.

Tanja or Sebastian, can one of you send me the source file
of draft version 2?

Cheers,

   Juergen 


  

  
-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
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)
--------------------------------------------------------------------------------------


  

  

  
  

--------------050800060908020708090607--

--------------090501090709020308030708
Content-Type: text/plain;
 name="draft-ietf-ipfix-reqs-03-comments-tzs.txt"
Content-Disposition: inline;
 filename="draft-ietf-ipfix-reqs-03-comments-tzs.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id g5CGMYh05696
Content-Transfer-Encoding: quoted-printable


Internet Draft                                                J. Quittek
Document: draft-ietf-ipfix-reqs-03.txt                   NEC Europe Ltd.
Expires: November 2002                                          T. Zseby
                                                               FhI FOKUS
                                                               B. Claise
                                                           Cisco Systems
                                                               S. Zander
                                                                G. Carle
                                                               FhI FOKUS
                                                            K.C. Norseth
                                                              Consultant

                                                                May 2002

              Requirements for IP Flow Information Export

                     

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC 2026]. 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

   Distribution of this document is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.


Abstract

   This memo defines requirements for the export of measured IP flow
   information out of routers, traffic measurement probes and
   middleboxes.



Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 1]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


Table of Contents

   1 Introduction .................................................    2
   2 Terminology ..................................................    2
   2.1 IP Traffic Flow ............................................    2
   2.2 Observation Point ..........................................    3
   2.3 Metering Process ...........................................    3
   2.4 Flow Record ................................................    4
   2.5 Export Process .............................................    4
   2.6 Collecting Process .........................................    4
   3 Applications Requiring IP Flow Information Export ............    4
   3.1 Usage-based Accounting .....................................    5
   3.2 Traffic Profiling ..........................................    5
   3.3 Attack/Intrusion Detection .................................    6
   3.4 QoS Monitoring .............................................    6
   4 Distinguishing Flows .........................................    7
   4.1 Interfaces .................................................    7
   4.2 IP Header Fields ...........................................    7
   4.3 Transport Header Fields ....................................    8
   4.4 MPLS Label .................................................    8
   4.5 DiffServ Code Point ........................................    8
   4.6 Header Compression and Encryption ..........................    8
   5 Metering Process .............................................    8
   5.1 Reliability ................................................    8
   5.2 Sampling ...................................................    9
   5.3 Overload Behavior ..........................................    9
   5.4 Timestamps .................................................   10
   5.5 Time Synchronization .......................................   10
   5.6 Timeout ....................................................   10
   5.7 Ignore Port Copy ...........................................   10
   6 Data Export ..................................................   11
   6.1 Information Model ..........................................   11
   6.2 Data Model .................................................   12
   6.3 Data Transfer ..............................................   13
   6.3.1 Congestion Awareness .....................................   13
   6.3.2 Reliability ..............................................   13
   6.3.3 Security .................................................   13
   6.4 Push and Pull Mode Reporting ...............................   14
   6.5 Regular Reporting Interval .................................   14
   6.6 Notification on Specific Events ............................   14
   6.7 Anonymization ..............................................   14
   7 Configuration ................................................   14
   8 General Requirements .........................................   15
   8.1 Openness ...................................................   15
   8.2 Scalability Concerning the Number of Export Processes ......   15
   8.3 Several Collectors .........................................   15
   9 Special Device Considerations ................................   15
   10 Security Considerations .....................................   17
   10.1 Disclosure of Flow Information Data .......................   18
   10.2 Forgery of Flow Records ...................................   18


Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 2]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   10.3 Denial of Service (DoS) Attacks ...........................   18
   11 Acknowledgments .............................................   19
   12 References ..................................................   19
   13 Authors' Addresses ..........................................   20
   14 Full Copyright Statement ....................................   21


1.  Introduction

   There are several applications that require flow-based IP traffic
   measurements. Such measurements could be performed by a router while
   forwarding the traffic, by a middlebox [RFC3234], or by a traffic
   measurement probe attached to a line or a monitored port. This memo
   defines requirements for exporting traffic flow information out of
   these boxes for further processing by applications located on other
   devices. In section 2 a selection of such applications is presented.
   The following sections list requirements derived from these
   applications.

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


2.  Terminology

   The following terminology is used within this document:

2.1.  IP Traffic Flow

   There are several definitions of the term 'flow' being used by the
   Internet community. Within this document we use the following one:

   A flow is defined as a set of IP packets passing an observation point
   in the network during a certain time interval. All packets belonging
   to a particular flow have a set of common properties. Each property
   is defined as the result of applying a function to the values of:

      1. one or more of packet header fields (e.g. destination IP
         address)

//TZS: I would remove the "of"
=20
      2. one or more properties of the packet itself (e.g. packet
         length)

      3. one or more of fields derived from packet treatment (e.g. AS
         number)

   A packet is defined to belong to a flow if it completely satisfies
   all the defined properties of the flow.



Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 3]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   This definition covers the range from a flow containing all packets
   observed at a network interface to a flow consisting of just a single
   packet between two applications with a specific sequence number.
   Please note that the flow definition does not match a general
   application-level end-to-end stream. However, an application may
   derive properties of application-level streams by processing measured
   flow data.

2.2.  Observation Point

   The observation point is a location in the network where IP packets
   can be observed. Examples are a line to which a probe is attached, a
   shared medium, such as an Ethernet-based LAN, a single port of a
   router, or a set of interfaces (physical or logical) of a router.

   Please note that a coarse-grined observation point of one flow, for

//TZS: "grained"

   example a line card with several ports, may be the superset of
   several more fine-grained observation points of some other flows, for
   example the individual ports of the line card.

//TZS: "coarse-grained" observation point sounds a little bit strange for=
 me.=20
I propose to edit the last paragraph to:

   Please note that multiple observation points can exist at the same dev=
ice=20
   for the same physical location simultaneously. One observation point c=
an=20
   for instance represents the line card with all ports. Further observat=
ion=20
   points on the same device can represent the individual ports of the li=
ne=20
   card.=20
=20

2.3.  Metering Process

   The metering process generates flow records. Input to the process are
   IP packet headers observed at an observation point. The metering
   process consists of a set of functions that includes packet header
   capturing, timestamping, sampling, classifying, and maintaining flow
   records.

   The maintenance of flow records may include creating new records,
   updating existing ones, computing flow statistics, deriving further
   flow properties, detecting flow expiration, passing flows record to
   the export process, and deleting flow records.

   The sampling function and the classifying function may be applied
   more than once with different parameters. Figure 1 shows the sequence
   in which the functions are applied. Sampling is not illustrated in
   the figure, it may be applied before any other function.

//TZS: Isnt this also true for classification. I think we discussed this=20
in Minneapolis. But I dont remember the outcome  :-(













Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 4]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


                           packet header capturing
                                     |
                                timestamping
                                     |
                                     v
                              +----->+
                              |      |
                              | classifying
                              |      |
                              +------+
                                     |
                          maintaining flow records
                                     |
                                     v


                 Figure 1: Functions of the metering process


2.4.  Flow Record

   A flow record contains information about a specific flow that was
   metered at an observation point. A flow record contains measured
   properties of the flow (e.g. the total number of bytes of all packets
   of the flow) and usually also characteristic properties of the flow
   (e.g. source IP address).

2.5.  Export Process

//TZS: As far as I remember we decided to use the term "exporting process=
" ?
(in the last teleconference) Then this has to be changed throughout the=20
whole document.

   The export process sends flow records to one or more collectors.  The
   flow records are generated by one or more metering processes.

2.6.  Collecting Process

   The collecting process receives flow records from one or more export
   processes. The collecting process might store received flow record or
   further process them, but these actions are out of the scope of this
   document.


3.  Applications Requiring IP Flow Information Export

   The following list contains a selection of applications requiring IP
   flow information export. Because requirements for flow export listed
   in further sections below are derived from these applications, their
   selection is crucial. The goal of this requirements document is not
   to cover all possible applications with all their flow export
   requirements, but to cover applications which are considered to be of
   significant importance in today's or future IP networks, and for
   which requirements can be met with reasonable technical effort.


Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 5]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   Please note, that the described applications can have a large number
   of differing implementations. Requirement details or the weighting of
   requirements could differ for specific implementations. Therefore we
   derive the requirements from the general functionality of the
   selected applications. Furthermore, the list of applications should
   lead to a better understanding of the requirements which is
   particularly important when designing or implementing a traffic flow
   measuring device.

3.1.  Usage-based Accounting

   Several new business models for selling IP service and IP-based
   services are currently under investigation. Beyond flat rate services
   which do not need accounting, accounting for these models can be
   based on time or volume. Accounting data can serve as input for
   billing systems. Accounting can be performed per user or per user
   group, it can be performed just for basic IP service or individually
   per high-level service and/or per content type delivered. For
   advanced/future services, accounting may also be performed per class
   of service, per application, per time of day, per used (label
   switched) path, etc.

3.2.  Traffic Profiling

   Traffic profiling is a process of characterizing IP flows and flow

//TZS: "the" instead of "a" process

   aggregates by using a model that represents key parameters of the
   flow such as flow duration, volume, time and burstiness. It is a
   prerequisite for network planning, network dimensioning, trend
   analysis, developing business models, and other activities. It
   heavily depends on the particular traffic profiling objective(s) what
   statistics and accuracy are required from the measurements. Typical
   information needed for traffic profiling are the distribution of used
   services and protocols in the network, the amount of packets of a
   specific type (e.g. percentage of IPv6 packets) and specific flow
   profiles.

   Since objectives for traffic profiling can vary, this application
   requires a high flexibility of the measurement infrastructure,
   especially regarding the options for measurement configuration and
   packet classification.

   Traffic Engineering (TE) comprises methods for measurement, modeling,
   characterization and control of a network. The goal of TE is the
   optimization of network resource utilization and traffic performance
   [RFC2702]. Since control and administrative reaction to measurement
   results requires access to the involved network nodes, TE mechanisms
   and the required measurement function usually are performed within
   one administrative domain. Typical parameters required for TE are
   link utilization, load between specific network nodes, number, size
   and entry/exit points of the active flows and routing information.


Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 6]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


3.3.  Attack/Intrusion Detection

   Capturing of flow information plays an important role for network
   security, both for detection of security violation, and for
   subsequent defense. In case of a Denial of Service (DOS) attack, flow
   monitoring can allow detection of unusual load situations or
   suspicious flows. In a second step, flow analysis can be performed in
   order to gather information about the attacking flows, and for
   deriving a defense strategy.

   Intrusion detection is a potentially more demanding application which
   would not only look at specific characteristics of flows, but that
   may also use a stateful packet flow analysis for detecting specific,
   suspicious activities, or unusually frequent activities. Such
   activities may be characterized by specific communication patterns,
   detectable by characteristic sequences of certain packet types.

3.4.  QoS Monitoring

   QoS monitoring is the non-intrusive (passive) measurement of quality
   parameters for single flows or traffic aggregates. In contrast to
   intrusive (active) measurements, non-intrusive measurements utilize
   the existing traffic in the network for QoS analysis. Since no test
   traffic is sent, non-intrusive measurements can only be applied in
   situations where the traffic of interest is already present in the
   network. One example application is the validation of QoS parameters
   negotiated in a service level specification (SLS).

   Non-intrusive measurements cannot provide the kind of controllable
   experiments that can be achieved with active measurements. On the
   other hand non-intrusive measurements do not suffer from undesired
   side effects caused by sending test traffic (e.g. additional load,
   potential differences in treatment of test traffic and real customer
   traffic)

   QoS monitoring often requires the correlation of data from multiple
   measurement instances  (e.g. for measuring one-way metrics). This
   requires proper clock synchronization of the involved measurement
   instances. For some measurements packet events at the different
   measurement points must be correlated. For this, the provisioning of
   post-processing functions (e.g. the generation of packet IDs) at the
   measurement instances would be useful. Furthermore, QoS monitoring
   can lead to a huge amount of measurement result data. Therefore it
   would highly benefit from mechanisms to reduce the measurement data,
   like aggregation of results and flow sampling.

//TZS: "sampling" instead of "flow sampling"





Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 7]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


4.  Distinguishing Flows

   Packets are mapped to flows by evaluating their properties. Packets
   with common properties are considered to belong to the same flow. A
   packet showing at least one difference in the set of properties is
   considered to belong to a different flow.

   The following subsections list a set of properties which a metering
   process MUST, SHOULD, or MAY be able to evaluate for mapping packets
   to flows. Please note that requiring the ability to evaluate a
   certain property does not imply that this property must be evaluated
   for each packet.

   In other words, meeting the IPFIX requirements means that the
   metering process in general must be able, via its configuration, to
   somehow support to distinguish flows via all the MUST fields, even if
   in certain circumstance/for certain applications, only a subset of
   the MUST fields is needed and only a subset of the MUST fields is
   effectively used to distinguish flows.

   Which combination of properties is used for distinguishing a flow in
   a particular measurement and how these properties are evaluated
   depends on the configuration of the metering process. The configured
   choice of evaluated properties strongly depends on the environment
   and purpose of the measurement and on the information required by the
   collector.

   For specific deployments, only a subset of the REQUIRED properties
   listed below can be used to distinguish flows, for example in order
   to aggregate the flow records and reduce the number of flow records
   exported. On the other hand, some other deployments will require
   distinguishing flows by some extra parameters, like for example the
   TTL field of the IP header or the BGP Autonomous Systems.

4.1.  Interfaces

   The metering process MUST be able to separate flows by the incoming
   interface or by the outgoing interface or by both of them.

4.2.  IP Header Fields

   The metering process MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated.

      1. source IP address (MUST)

      2. destination IP address (MUST)

      3. protocol type (TCP,UDP,ICMP,...) (MUST)



Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 8]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


      4. IP version number (SHOULD)
         This requirement only applies if the the observation point is
         located at a device is supporting more than one version of IP.

//TZS: "that supports" instead of "is supporting "


   For source address and destination address, separating by full match
   MUST be supported as well as separation by a partial match (for
   example subnet masking).

4.3.  Transport Header Fields

   The metering process MUST be able to separate flows by the port
   numbers of the transport header in case of TCP or UDP being used as
   transport protocol. Both, source and destination port number MUST be
   supported for distinguishing flows, individually as well as in
   combination.

4.4.  MPLS Label

   If the observation point is located at a device supporting
   Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering
   process MUST be able to separate flows by the MPLS label.

4.5.  DiffServ Code Point

   If the observation point is located at a device supporting
   Differentiated Services (DiffServ) then the metering process MUST be
   able to separate flows by the DiffServ Code Point (DSCP, see
   [RFC2474]).

4.6.  Header Compression and Encryption

   If header compression or encryption is used, the metering process
   might not be able to access all header fields. For packets with
   compressed or encrypted headers, the requirements stated in this
   section 4 MUST be met for observation points at end points of header
   compression or of packet encryption, but they do not need to be met
   for observation points between the end points.


5.  Metering Process

   The following are requirements for the metering process. All
   measurements MUST be conducted from the point of view of the
   observation point.

//TZS: What does the last sentence mean ?


5.1.  Reliability

   The metering process MUST either be reliable or missing reliability
   MUST be known and indicated. The metering process is reliable, if
   each packet passing the observation point is measured according to


Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 9]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   the configuration of the metering process. If, e.g. due to some
   overload, not all passing packets can be included into the metering
   process, then the metering process MUST be able to detect this
   failure and to report about it.

5.2.  Sampling

   Sampling describes the systematic or random selection of a subset of
   elements (the sample) out of a set of elements (the parent
   population). Usually the purpose of applying sampling techniques is
   to estimate a parameter of the parent population by using only the
   elements of the subset. Sampling techniques can be applied for
   instance to select a subset of packets out of all packets of a flow
   or to select a subset of flows out of all flows on a link.  Sampling
   methods differ in their sampling strategy (e.g. systematic or random)
   and in the event that triggers the selection of an element. The
   selection of one packet can for instance be triggered by its arrival
   time (time-based sampling), by its position in the flow (count-based
   sampling) or by the packet content (content-based sampling).

   The metering process MAY support measuring traffic by packet
   sampling. If sampling is supported the sampling configuration MUST be
   well defined. The sampling configuration includes the samplng method
   and all its parameters.

   If the sampling configuration is changed during operation, the new
   sampling configuration with its parameters MUST be indicated to all
   collectors receiving the affected flow records.

//TZS: add sentence: "This includes the case when sampling is applied for=
=20
the first time (configuration changed from "no sampling" to a sampling sc=
heme)"
Alternatively: modify first sentence to "If sampling is applied or the sa=
mpling configuration is changed .."

   In case of any change in the sampling configuration, all flow records
   metered by the previous sampling configuration MUST be terminated and
   exported according to the export configuration. The metering process
   MUST not merge the flow records generated with the new sampling
   configuration with the flow records generated with the previous
   sampling configuration.

5.3.  Overload Behavior

   In case of an overload, for example lack of memory or processing
   power, the metering process MAY change in order to cope with the lack

//TZS: "may change its behavior"

   of resources. Possible reactions include:

      -  Reduce the number of flow accounts. This can be achieved by
         more coarse grained flow measurement or by a restriction of the
         flow accounts to a subset of the set of original ones.

      -  Switch to sampling packets before they are processed by the
         metering process or - if sampling is already performed - reduce
         the sampling rate.



Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 10]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


      -  Stop metering.

      -  Reducing the resource usage of competing processes on the same
         device.  Example: reducing the packet forwarding throughput

   Overload behavior is not restricted to the four options listed above.
   But in case the overload behavior has an impact on the metering
   process or the export process, the overload behavior MUST be clearly
   defined and the collector MUST be able to distinguish the flow
   records exported before and after the metering process behavior
   change: In case of any change of the meter's behavior, all flow
   records metered by the previous behavior MUST be terminated and
   exported according to the export configuration. The metering process
   MUST not merge the flow records generated with the new behavior with
   the flow records generated with the previous behavior.

5.4.  Timestamps

   The metering process MUST be able to generate timestamps for the
   first and the last observed packet of a flow. The timestamp
   accuricaty MUST be at least the one of the sysUpTime [RFC1213], which

//TZS: "accuracy" instead of "accuricaty"

   is one centisecond.

5.5.  Time Synchronization

   Metering processes and collectors SHOULD be time-synchronized with
   each other. Using NTP or GPS are possible ways of achieving this.
   However selecting a method for time synchronization is not in the
   scope of this document.

5.6.  Timeout

   The metering process MUST be able to detect flow timeout. A flow is

//TZS: "timeouts" instead of "timeout" ?

   considered to be timed out if no packet of this flow has been
   observed for a given timeout interval. The metering process MAY
   support means for detecting the end of a flow before a time out

//TZS: "timeout" instead of "time=B4out" ?

   occurs, for example by detecting the FIN or RST bits in a TCP
   connection. The procedure for detecting a flow timeout MUST be
   clearly defined.

5.7.  Ignore Port Copy

   The metering process MAY be able to ignore packets which are
   generated by a port copy function acting at the device where the
   observation point of a flow is located.







Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 11]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


6.  Data Export

   The following are requirements for exporting measured flow data out
   of the exporter. Beside requirements on the data transfer, we
   separate requirements concerning the information model from
   requirements concerning the data model. Furthermore, we list
   requirements on reporting times and events and on anonymization of
   records.

6.1.  Information Model

   The information model for the flow information export is the list of
   attributes of a flow to be contained in the report (including the
   semantics of the attributes).

   This section lists attributes an export process MUST or MAY be able
   to report. This does not imply that each exported flow records MUST
   contain all REQUIRED attributes, but that it MUST be possible to
   configure the device in a way that all of the REQUIRED attributes are
   transmitted from the export process to the colleting process for each
   measured flow.

   In other words, meeting the IPFIX requirements means that the export
   process in general must be able, via its configuration, to somehow
   support to report all the MUST fields, even if in certain
   circumstance or for certain applications, only a subset of the MUST
   fields is needed and only a subset of the MUST fields is effectively
   reported.

   Beyond that, the device might offer to report also further attributes

//TZS; remove "also"

   not mentioned here. A particular flow record may contain some of the
   "REQUIRED" attributes as well as some additional ones, for example
   covering future technologies.

   This document does not impose that the following attributes would

//TZS: "are" or "would be" instead of "would"

   reported for every single flow records, especially for repetitif

//TZS: "record" instead of "records"
//TZS: "repetitiv" instead of "repetitif"

   attributes. For example, if the observation point is the incoming
   packet stream at IP interface with the ifIndex value 3, then this

//TZS: "at the IP interface" or "at an IP interface"


   observstion point does not have to be exported as part of every

//TZS: "observation"

   single flow record. Exporting it just once might give sufficient
   information to the collecting process.

   The measuring device MUST be able to report the following attributes
   for each measured flow:

      1. IP version number
         This requirement only applies if the observation point is
         located at a device supporting more than one version of IP.
      2. source IP address
      3. destination IP address


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 12]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


      4. IP protocol type (TCP,UDP,ICMP,...)
      5. source TCP/UDP port number
      6. destination TCP/UDP port number
      7. input interface (ifIndex)
         This requirement does not apply if the observation point is
         located at a probe device.
      8. output interface (ifIndex)
         This requirement does not apply if the observation point is
         located at a probe device. This requirement does not apply in
         case of multicast flow records.
      9. packet counter
         If a packet is fragmented, each fragment is counted as an
         individual packet.
     10. byte counter
         Which bytes of a packet are counted MUST be defined exactly.
     11. in case of IPv4: Type of Service
     10. in case of IPv6: Flow Label
     11. if BGP is supported at the observation point: BGP AS#
     12. if MPLS is supported at the observation point: MPLS label
     13. if DiffServ is supported at the observation point: DSCP
     14. timestamp of the first packet of the flow
     15. timestamp of the last packet of the flow
     16. if sampling is used: sampling configuration
     17. unique identifier of the observation point
     18. unique identifier of the export process

   The metering process MAY be able to report the following attributes
   for each measured flow:

     20. Time To Live
     21. IP header flags
     22. TCP header flags
     23. dropped packet counter at the observation point
         If a packet is fragmented, each fragment MUST be counted as an
         individual packet.
     24. fragmented packet counter
         counter of all packets for which the fragmented bit is set in
         the IP header
     25. multicast replication factor
         the number of outgoing packets originating from a single
         incoming multicast packet

//TZS: for MC maybe also all the outgoing IFs ?

6.2.  Data Model

   The data model describes how information is represented in flow
   records.

   The data model MUST be extensible for future attributes to be added.
   Even if a set of attributes is fixed in the flow record, the data
   model MUST provide a way of extending the record by configuration or


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 13]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   for certain implementations.

   The data model used for exporting flow information MAY be flexible
   concerning the flow attributes contained in flow records. A flexible
   record format would offer the possibility of defining records in a
   flexible (customizable) way regarding the number and type of
   contained attributes.

   The Data Model SHOULD be independent of the underlying transport
   protocol, i.e. the data transfer.

6.3.  Data Transfer

   Requirements for the data transfer include reliability and security
   requirements. These requirements do not apply to the measuring device
   alone, but also to the transport network. Consequently, the export
   process does not necessarily have to guarantee that all requirements
   are met. Particularly if the security requirements are already
   guaranteed by the network used for data transfer, then these
   requirements do not have to be considered anymore by the export
   process. Therefore, these requirements are OPTIONAL for the export
   process, although they may be REQUIRED for the data transfer as
   specified in the appendix.

//TZS: We already had a lot of discussions regarding this. But I still=20
have problems with this formulation. What does this mean ? The requiremen=
ts=20
for an IPFIX protocol applied in a LAN or in an environment with IPsec di=
ffer
from the requirements for an IPFIX protocol in an environment without the=
se
capabilities ? So we could get two different protocol specifications ? or=
 optional
security features that can switch an IPFIX implementation from "standard-=
conformant"
to "not standard-conformant" if disabled in the wrong environment ?
I propose to remove everthing after the "Consequently,"  and substitute i=
t by

"The exporting process can utilize existing security features provided by=
 the transport=20
network or by the exporting device  "

With this formulation we allow the utilization of existing capabilities b=
ut leave the=20
responsibilities with the IPFIX implementor. This could mean for instance=
 IPFIX encryption=20
capabilities can be only switched off or left out if e.g. replaced by a c=
onnection to an=20
IPsec implementation.


6.3.1.  Congestion Awareness

   For the data transfer, a congestion aware protocol MUST be supported.

6.3.2.  Reliability

   Absence of reliability, for example caused by export packet loss or
   export packet reordering, of the data transfer MUST be indicated.

   Please note that if an unreliable transport protocol is used,
   reliability can be provided by higher layers. In such a case only
   lack of overall reliability MUST be indicated. For example reordering
   could be dealt with by adding a sequence number to each packet.

6.3.3.  Security

   Confidentiality of flow specific data transferred from an export
   process to a collecting process SHOULD be ensured.

   Integrity of flow specific data transferred from an export process to
   a collecting process MUST be ensured.

   Authenticity of flow specific data transferred from an export process
   to a collecting process MUST be ensured.

   See more about Security in the "Security Considerations" section 10,


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 14]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   from which the 3 requirements above are deducted.

// TZS: substitute last sentence by "The security threats from which thes=
e 3 requirements are deducted=20
are explained in the "Security Considerations" section 10,.

6.4.  Push and Pull Mode Reporting

   In general, there are two ways of deciding on reporting times: push
   mode and pull mode. In push mode, the export process decides without
   an external trigger on when to send a report on measured flows. In

//TZS: without the first "on" ?=20

   pull mode, sending a report is triggered by an explicit request from
   a collector. The measuring device MUST support push mode reporting,
   it MAY support pull mode reporting.

6.5.  Regular Reporting Interval

   The export process SHOULD be capable of reporting measured traffic
   data regularly according to a given interval length.

6.6.  Notification on Specific Events

   The export process MAY be capable of sending notifications to a
   collecting process, if a specific event occurs. Such an event can be

//TZS: add "for instance"

   the arrival of the first packet of a new flow, or the termination of
   a flow after flow timeout.

6.7.  Anonymization

   The export process MAY be capable of anonymizing source and
   destination IP addresses in flow data before exporting them. It MAY
   support anonymization of port numbers and other fields. Please note
   that anonymization is not originally an application requirement, but
   derived from general requirements for treatment of traffic within a
   network.


7.  Configuration

   The metering process MUST provide a way of configuring traffic
   measurement. The following parameters of the metering process SHOULD
   be configurable:

      1. specification of the observation point, e.g. an interface or
         a list of interfaces to be monitored.
      2. specifications of flows to be metered
      3. flow timeouts

   The following parameters MAY be configurable:

      4. sampling method and parameters, if feature is supported
      5. overload behavior

   The export process MUST provide a way of configuring the data export.


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 15]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   The following parameters of the export process SHOULD be
   configurable:

      1. reporting data format
         Specifying the reporting data format SHOULD include a selection
         of attributes to be reported for each flow.
      2. the collecting process (or list of collecting processes) to
         which flows are reported 2. notifications to be sent to the
         collecting process(es) 3. flow anonymization, if the export
         process supports it

//TZS: numbering under 2. ?=20



   If configuration is done remotely, security of the configuration

//TZS: "security for the transfer of configuration data"

   SHOULD be supported including confidentiality, integrity and
   authenticity. The means used for remote configuration are out of the
   scope of this document.


8.  General Requirements

8.1.  Openness

   IPFIX specifications SHOULD be open to future technologies. This
   includes extensibility of configuration of measurement and reporting.

   Openness is also required concerning the extensibility of the data
   model, as stated in section 6.2.

8.2.  Scalability Concerning the Number of Export Processes

   Data collection from hundreds of different export processes MUST be
   supported. The collecting process MUST be able to distinguish several
   hundred export processes by their identifiers.

8.3.  Several Collectors

   The export process MAY be able to export flow information to more
   than one collecting process.


9.  Special Device Considerations

   This document is intended to avoid constraining the architecture of

//TZS: "intends to"

   probes, routers, and other devices hosting observation points,
   metering processes, export processes, or collecting processes.  It

//TZS: "and/or"

   can be expected that typically observation point, metering process,
   and export process are co-located at a single device.  However, the
   requirements defined in this document do not exclude devices that
   derive from this configureation. Figure 2 shows some examples.

//TZS: "configuration"



Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 16]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


            +---+     +-----+     +---------+       +---------+
            | E-+->   |  E--+->   |    E----+->   <-+--E   E--+->
            | | |     |  |  |     |   /    |       |  |   |  |
            | M |     |  M  |     |  M   M  |       |  M   M  |
            | | |     | /| |     | /| /| |       | /| /| |
            | O |     | OOO |     | OOO OOO |       | OOO OOO |
            +---+     +-----+     +---------+       +---------+
            Probe      Basic        Complex          Multiple
                       Router       Router           Exporters

//TZS: I love these figures :-) Nevertheless, some elements in row 3 and =
4 appear=20
displaced in my editor


          +---+     +---+     +---+
          | E-+->   | E-+->   | E-+------------->---+
          | | |     | | |     | | | +---+         +-+-----+
          +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
            |       | | |     | | | | | | +---+   +-+-----+
          +-+-+     +-+-+     | O | | M | | E-+->---+
          | | |       |       +---+ | | | | | |
          | M |     +-+-+           | O | | M |
          | | |     | | |           +---+ | | |           +-----+
          | O |     | O |                 | O |        ->-+-C-E-+->
          +---+     +---+                 +---+           +-----+

         Protocol   Remote             Concentrator        Proxy
         Converter  Observation

                      Figure X: IPFIX-related Devices

   All examples are composed of one or more of the following elements:
   observation point (O), full or partial metering process (M), export
   process (E), collecting process (C).

   A very simple device is a probe. It contains on a single observation
   point, a single metering process, and a single export process.  For
   this device the observation domain contains a single observation
   point only.

   A basic router extends this structure by multiple observation point.
   Here an exported flow record may still have an observation domain
   containing a single observation point. But also Observation domains
   containing all observation points of the routers are possible.

//TZS: hmm... we avoided the term "observation domain" in the terminology=
=20
section. I would prefer to avoid "observation domain" here, too...

   A more complex router may host more than one metering process, for
   example one per line card. Please note that an observation domain is
   restricted to the observation points connected to a single metering
   process. An observation domain containing all observation points of
   this router is not possible with this structure.

//TZS: only if I connect all observation points to one metering process ?


   Alternatively, a complex router may use different export processes
   for flow records generated by different metering processes.


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 17]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   A protocol converter makes use of a metering process that can be
   accessed only by another protocol than the one defined for IPFIX, for
   example the SNMP and the Meter MIB module [RFC2720]. Then the
   exporter receives flow record from a remote metering process and
   exports these records using the IPFIX protocol.

//TZS: " The other protocol together with the record conversion is then=20
seen as the metering process that serves the exporting process"
Is this the correct interpretation ?


   Another choice is remote packet observation. Packet header captured
   at an observation point may be exported as raw data to a device
   hosting metering process and exproting process.

//TZS "exporting" aahh... here you use "exporting" So I remembered our
decision correctly (see comment at 2.5)

//TZS:  maybe add "In this case the whole device which exports the raw=20
header data is considered as the observation point for the metering proce=
ss"
Correct interpretation ?

   An intermediate structure between protocol converter and remote
   observation (not shown in the Figure) would be a split metering

//TZS:  "splitted" ?=20

   process, for example performing timestaping and sampling at the
   device hosting the observation point and performing packet
   classification at another device hosting the export process.

   A concentrator receives flow records via the IPFIX protocol, merges
   them into higher aggregated flows and exports the resulting flows
   again using the IPFIX protocol. Please note that for the final flow
   records the observation domain potentially contains observation
   points at all first level devices. The metering process of the final
   flow records is composed by the (partial) metering processes at the
   first level devices and the partial metering process at the
   concentrator.

   Finally, a very simple IPFIX-related device is a proxy. It just
   receives flow records using the IPFIX protocol and sends them further
   using the same protocol. A proxy might be useful for traversing
   firewalls or other gateways.


10.  Security Considerations

   The future IPFIX protocol must be capable to transport data over the
   public Internet. Therefore it cannot be excluded that an attacker
   captures or modifies exchanged packets or inserts additional packets.

   This section describes security requirements for IPFIX.  It therefore
   also states the required security features for a future IPFIX
   protocol.=20

//TZS: Ssubstitute first 2 sentences by "This document contains the the=20
required security features for a future IPFIX protocol."=20

   Like other requirements, the security requirements differ
   for the considered applications. The incentive to modify collected
   data for accounting or intrusion detection for instance is usually
   higher than the incentive to change data collected for traffic
   profiling. Therefore the required security features in this document
   are listed per application in the appendix.  The suggestion of
   concrete solutions for achieving the required security properties
   will be part of the IPFIX architecture and protocol description and
   is out of scope of this document. Furthermore, methods for remote
   configuration of the IPFIX processes are out of scope for IPFIX.
   Therefore, threads that are caused by data exchange for remote

//TZS: "threats" :-)


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 18]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   configuration are not considered here.

   The following potential security hazards for an IPFIX protocol can be
   identified: disclosure of IP flow information, forgery of flow
   records, and Denial of Service (DoS) attacks.

10.1.  Disclosure of Flow Information Data

   The content of data exchanged by the IPFIX protocol (e.g. IPFIX flow
   records) should be kept confidential between the involved parties
   (export process and colleting process). Observation of IPFIX flow
   records gives an attacker information about the active flows in the
   network, communication endpoints and traffic patterns. This
   information cannot only be used to spy out user behavior but also to
   plan and conceal future attacks. Therefore the requirements document
   recommends to ensure the confidentiality of the transferred data.
   This can be achieved for instance by encryption.

10.2.  Forgery of Flow Records

   Because of the potential uses of IPFIX flow records in accounting and
   security applications, there are strong incentives to forge exported
   IPFIX  flow records (e.g. to save money or prevent the detection of
   an attack). This can be done either by altering flow records on the
   path or by injecting forged flow records that pretend to be
   originated by the original export process. In order to make the IPFIX
   protocol resistant against such attacks this document requires to
   ensure authenticity and integrity for the IPFIX data transfer.

   Special caution is required if security applications rely on IPFIX
   data. With forged flow records it is possible to trick on security
   applications. It is for instance possible to pretend that a DoS
   attack happens without even launching a real attack.

   IPFIX flow records are used in accounting and security applications.
   This leads to strong incentives for attackers to forge exported IPFIX
   flow records (for example to save money or to prevent the detection
   of an attack). In order to make the IPFIX protocol resistant against
   such attacks, source authentication and integrity assurance must be
   provided for IPFIX data. These requirements are covered in the
   security requirements section of this document.

//TZS: substitute all 3 paragraphs by the following 3:=20

   IPFIX flow records are used in accounting and security applications.
   This leads to strong incentives for attackers to forge exported IPFIX
   flow records (for example to save money or to prevent the detection
   of an attack). This can be done either by altering flow records on the
   path or by injecting forged flow records that pretend to be originated=
=20
   by the original export process.=20

   Special caution is required if security applications rely on IPFIX
   data. With forged flow records it is possible to trick on security
   applications. It is for instance possible to pretend that a DoS
   attack happens without even launching a real attack.

   In order to make the IPFIX protocol resistant against such attacks,=20
   source authentication and integrity assurance must be provided for=20
   IPFIX data. These requirements are covered in the security requirement=
s=20
   section (6.3.3) of this document.



10.3.  Denial of Service (DoS) Attacks

   DoS attacks on routers or other middleboxes that have the IPFIX
   protocol implemented would also affect the IPFIX protocol and impair
   the sending of IPFIX records. Nevertheless, since such hazards are
   not induced specifically by the IPFIX protocol the prevention of such
   attacks is out of scope of this document.



Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 19]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


   Nevertheless IPFIX itself also causes potential hazards for DoS
   attacks.  All processes that expect the reception of traffic can be
   target of a DoS attack. With the IPFIX export process this is only
   the case if it supports the pull mode (which can be an optional
   feature of the future IPFIX protocol according to this document). The
   collecting process always expects data and therefore can be flooded
   by forged flow records.


11.  Acknowledgments

   We like to thank all the people contributing to the requirements
   discussion on the mailing list for a lot of valuable comments.


12.  References

[RFC2026]   S. Bradner, "The Internet Standards Process -- Revision 3",
            RFC 2026, October 1996.

[RFC3234]   B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234,
            February 2002.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

[RFC2702]   D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
            "Requirements for Traffic Engineering Over MPLS", RFC 2702,
            September 1999.

[RFC3031]   E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
            Switching Architecture", RFC 3031, January 2001.

[RFC2474]   K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
            Differentiated Services Field (DS Field) in the IPv4 and
            IPv6 Headers", RFC 2474, December 1998.

[RFC1213]   K. McCloghrie, M. Rose. "Management Information Base for
            Network Management of TCP/IP-based internets: MIB-II", RFC
            1213, March 1991.












Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 20]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


13.  Authors' Addresses

     Juergen Quittek
     NEC Europe Ltd., Network Laboratories
     Adenauerplatz 6
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-15
     EMail: quittek@ccrle.nec.de


     Tanja Zseby
     Fraunhofer Institute for Open Communication Systems (FOKUS)
     Kaiserin-Augusta-Allee 31
     10589 Berlin
     Germany

     Phone: +49 30 3463 7153
     Email: zseby@fokus.fhg.de


     Benoit Claise
     Cisco Systems
     De Kleetlaan 6a b1
     1831 Diegem
     Belgium

     Phone: +32 2 704 5622
     Email: bclaise@cisco.com


     Sebastian Zander
     Fraunhofer Institute for Open Communication Systems (FOKUS)
     Kaiserin-Augusta-Allee 31
     10589 Berlin
     Germany

     Phone: +49 30 3463 7287
     Email: zander@fokus.fhg.de


     Georg Carle
     Fraunhofer Institute for Open Communication Systems (FOKUS)
     Kaiserin-Augusta-Allee 31
     10589 Berlin
     Germany

     Phone: +49 30 3463 7149
     Email: carle@fokus.fhg.de


Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 21]
=0C
Internet-Draft             IPFIX Requirements                   May 2002


     K.C. Norseth
     Consultant
     934 S. Palos Verdes Dr.
     Kaysville, Utah 84037 USA

     Phone: 801.546.3316
     Email: kcn@norseth.com


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2001). 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 languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 22]





--------------090501090709020308030708--



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jun 14 09:39:09 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29106
	for ; Fri, 14 Jun 2002 09:39:09 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17IquX-0000MT-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Jun 2002 08:14:41 -0500
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17IquU-0000MM-00
	for ipfix-req@net.doit.wisc.edu; Fri, 14 Jun 2002 08:14:38 -0500
Date: Fri, 14 Jun 2002 08:14:37 -0500
From: Dave Plonka 
To: ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] I-D ACTION:draft-ietf-ipfix-reqs-03.txt
Message-ID: <20020614081437.A942@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Organization: UW-Madison, DoIT, Network Services
X-VMS-Error: %SYSTEM-E-ILLRSDM, operation not allowed on resource domain
X-Shakespearean-Insult: Thou infectious rude-growing malt-worm
Precedence: bulk
Sender: majordomo listserver 


Below please find the announcement regarding the availability of the
updated requirements draft.

The following links to it now appear in the IPFIX web site index:

   http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-03.txt
   http://ipfix.doit.wisc.edu/req/draft-ietf-ipfix-reqs-03.txt

Dave

----- Forwarded message from owner-ipfix@net.doit.wisc.edu -----

To: IETF-Announce: ;
Cc: ipfix@net.doit.wisc.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipfix-reqs-03.txt
Date: Wed, 12 Jun 2002 07:12:55 -0400
Sender: nsyracus@cnri.reston.va.us

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.

	Title		: Requirements for IP Flow Information Export
	Author(s)	: J. Quittek et al.
	Filename	: draft-ietf-ipfix-reqs-03.txt
	Pages		: 27
	Date		: 11-Jun-02
	
This memo defines requirements for the export of measured IP flow
information out of routers, traffic measurement probes and
middleboxes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipfix-reqs-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipfix-reqs-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020611122659.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipfix-reqs-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-reqs-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020611122659.I-D@ietf.org>

--OtherAccess--

--NextPart--

----- End forwarded message -----

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jun 14 13:39:03 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07602
	for ; Fri, 14 Jun 2002 13:39:02 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17IuiB-0005Yv-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Jun 2002 12:18:11 -0500
Received: from web12307.mail.yahoo.com ([216.136.173.105])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 17Iui8-0005Yn-00
	for ipfix-data@net.doit.wisc.edu; Fri, 14 Jun 2002 12:18:08 -0500
Message-ID: <20020614171757.63072.qmail@web12307.mail.yahoo.com>
Received: from [203.200.151.121] by web12307.mail.yahoo.com via HTTP; Fri, 14 Jun 2002 10:17:57 PDT
Date: Fri, 14 Jun 2002 10:17:57 -0700 (PDT)
From: Ganesh Sadasivan 
Subject: [ipfix-data] Re: [ipfix] draft-ietf-ipfix-data-01.txt 
To: ipfix-data@net.doit.wisc.edu, calato@riverstonenet.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

> Paul,
> See my response in line starting with [G].
> Thanks
> Ganesh
> 
> > 5.1. Flow Classification
> > 
> >    The collector MUST be able to map the flow to
the
> corresponding 
> >    property types defined by the flow type. This
can
> be done only if 
> >    the collector has a mapping from flow type
> identifier (carried in 
> >    each flow record) to its actual structure. More
> details of how 
> >    this can be achieved are described in section
> 5.???
> > 
> > 
> >    In addition the collector, when it receives the
> flow records, MAY 
> >    need the following to interpret the flow
records
> further:
> > 
> >       A. Observation Point.
> >       B. Selection Criteria of Packets
> > 
> >    As mentioned in section 2.1, a flow record can
be
> better analyzed 
> 
> [G] Notice that it mentioned that the flow
> can be "better analysed" and it is not a
> MUST. Eg. If 2 observation 
> point A,B are measuring in flows in 2 different
> ways say A is sampling 1 in 5 and B is sampling
> 1 in 25. The collector can better analyse the 
> information, if along with the flow information,
> the observation point is also specified.This is
> not something mandatory but is useful for a 
> detailed analysis.
> 
> >    if the Observation Point from which it is
> measured is known. As 
> >    such it is recommended that the flow record
carry
> the Observation 
> >    Point information along with the flow records
> when exported. In 
> >    cases where there is a single observation point
> or where the 
> >    observation point information is not relevant,
> the exporter MAY 
> >    choose not to add this to the flow records.
> > 
> 
> 	I don't understand this section. What is flow
> classification?
> 
> 	Also, A flow should be able to be interpreted
> regardless of 
> 	knowing the observation point. A single observation
> point may
> 	map flows in 2 or more different ways. The fact
that
> different 
> 	observation points map flows based on different
> criteria 
> 	is irrelevant. All the information needed to
> interpret the flow
> 	must be passed up. 
> 
> 
> > 5.2.1. Function on properties that determines a
flow
> type (Fi)
> > 
> >    Packets that satisfy a function on the fields
> defined by the 
> >    packet header fields or fields obtained while
> doing the packet 
> >    processing or the properties of the packet
> itself.
> > 
> >    Example:
> > 
> >    Mask/Match of the fields that define a filter.
> The filter may be 
> >    defined as {Protocol == TCP, Destination Port
> between 80 and 120}. 
> > 
> > 
> >    could be used in any sequence to select 
> >    packets.
> > 
> 
> 	I think it would it be better to say "Multiple such
> functions" 
> 	instead of filters?
> 
> > 5.3. Selection Criteria for flows for export
> > 
> >    The measurement device MAY define additional
> rules so that only 
> >    certain flows records are picked up for export.
> This MAY be done 
> >    by either of the two types of methods defined
in
> 5.2.1 and 
> >    5.2.2 or a combination of them.
> > 
> >    Example:
> > 
> >    Only the flow records which meet the following
> selection criteria 
> >    are exported.
> > 
> >       1 All flow records whose destination IP
> address matches
> >         {20.3.1.5}.
> >       2 Every other (.i.e. sampling rate 1 in 2)
> flow record whose
> >         destination IP address matches
{160.0.1.30}.
> > 
> 
> 
> 	I'm not sure I agree with this. I think you have
> defined
> 	2 flows in #1 and #2. 
> 
> [G] That is true.
> 
> Given that, both flows are exported.
> 	I think maybe the "Selection Criteria" is really
part
> of
> 	the Flow Type.
> 
> [G] It could be a post-flow-measurement criteria 
> also. So need not be fixed to flow-type.
> 
> >       * Packet Counter 
> >       * Dropped Packet Counter 
> >       * Byte Counter 
> >       * Dropped Byte Counter
> >       * Timestamp of the First Packet Observed 
> >       * Timestamp of the Last Packet Observed 
> 
> 	Generally the last time stamp is the time at which
> he flow has expired (as described earlier). 
> 
> The last
> 	packet observed is not available unless each packet
> 	is processed in software. So either we need another
> 	field or a different definition.
> 
> [G] Just curious. Why do we need a last-packet
>  observed field?
> 
> 
> > 
> >       * Unique ID of the Observation Point 
> >       * Unique ID of the Measuring Device 
> 
> 	As stated above, I disagree that these are part of
> flow definition.
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jun 17 09:22:18 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01430
	for ; Mon, 17 Jun 2002 09:22:17 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17JwAK-0000p6-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Jun 2002 08:03:28 -0500
Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 17JwAH-0000nz-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Jun 2002 08:03:25 -0500
Received: (cpmta 17993 invoked from network); 17 Jun 2002 06:02:53 -0700
Received: from 24.221.253.53 (HELO kcn)
  by smtp.register-admin.com (209.228.32.119) with SMTP; 17 Jun 2002 06:02:53 -0700
X-Sent: 17 Jun 2002 13:02:53 GMT
Message-ID: <003c01c215ff$7084a460$850f880a@kcn>
From: "K.C. Norseth" 
To: "IPFIX" 
Subject: [ipfix] draft-ietf-ipfix-architecture-02.txt
Date: Mon, 17 Jun 2002 07:03:53 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hello folks.

Here is the next draft to release - Comments?

http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-02.txt

K.C.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 10:17:50 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18697
	for ; Tue, 18 Jun 2002 10:17:50 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KJVO-0002uh-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 08:58:46 -0500
Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KJVM-0002tz-00
	for ipfix-req@net.doit.wisc.edu; Tue, 18 Jun 2002 08:58:44 -0500
Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 18 Jun 2002 06:58:11 -0700
Message-ID: <3D0F3C25.A60651D8@riverstonenet.com>
Date: Tue, 18 Jun 2002 09:56:53 -0400
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Moore 
CC: "Cottrell, Les" ,
        "'K.C. Norseth'" , req ,
        "Logg, Connie A." ,
        colleen 
Subject: Re: [cottrell@SLAC.Stanford.EDU: RE: [ipfix-req] Ipfix features]
References: <20020611233538.A71948@caida.org> <20020612091210.W84415@login.caida.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jun 2002 13:58:12.0495 (UTC) FILETIME=[2F7439F0:01C216D0]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


Does reporting the fragment ID help? There is still an
issue with reusing the fragment ID but given the same
src/dst and a reasonably close time stamp might be
good enough to figure it out after the fact (i.e. 
combining a fragment flow and a full flow at the collector).

Paul

David Moore wrote:
> 
> This may be difficult to get "correct".  I assume correct means
> something roughly like:
> 1. maintain state to determine what ports apply for a non-first fragmented
> packet.
> 2. once a fragmented packet's ports are determined, add it into the
> flow it would have gone into if it had ports.
> 
> A few comments:
> 
> A separate fragment/ipid timer would be needed to decide when to expire
> the state.  RFC 791 recommends 15 seconds, which also seems to match
> reasonably well with caida network measurements.
> 
> Fragments may come in any order (in particular linux sends them
> from the back of the original packet backwards towards the front).
> This means that you may see a fragment w/o port information before
> you see the corresponding port information.  So you can't determine
> which flow the fragment belongs to until a later point.
> 
> VPN and tunnel's cause a lot of fragmented traffic, which may occur
> at high-speed depending on the endpoints, which may result in a
> lot of state being needed.  A good garbage collection scheme may
> be needed for this (as well as DoS attacks with fragmented packets).
> 
> Personally, I'd also like a flow field saying whether the packet
> was fragmented or not.  So fragmented packets to/from host/port &
> proto would be counted as a separate flow from non-fragmented
> packets to/from host/port & proto.  This would be in addition to
> any attempts to correctly assign ports to fragments.
> 
> -- david
> 
> ----- Forwarded message from "Cottrell, Les"  -----
> 
>   Date: Tue, 11 Jun 2002 15:00:47 -0700
>   From: "Cottrell, Les" 
>   Subject: RE: [ipfix-req] Ipfix features
>   To: "'K.C. Norseth'" , req 
>   Cc: "Logg, Connie A." 
>   X-Mailer: Internet Mail Service (5.5.2653.19)
> 
>   As an example of IP fragmentation see:
> 
>   http://www.slac.stanford.edu/comp/net/netflow/afsexample.html
> 
>   > -----Original Message-----
>   > From: K.C. Norseth [mailto:kcn@norseth.com]
>   > Sent: Tuesday, June 11, 2002 10:33 AM
>   > To: Cottrell, Les; req
>   > Cc: Logg, Connie A.
>   > Subject: Re: [ipfix-req] Ipfix features
>   >
>   >
>   > Discusssion is healthy. Please elaborate on what you mean.
>   >
>   > K.C.
>   > ----- Original Message -----
>   > From: "Cottrell, Les" 
>   > To: "req" 
>   > Cc: "Logg, Connie A." 
>   > Sent: Tuesday, June 11, 2002 11:16 AM
>   > Subject: [ipfix-req] Ipfix features
>   >
>   >
>   > | I hope this is not too off-subject, but in future realeases
>   > of ipfix
>   > | ttols
>   > such as Netflow, I would like to see:
>   > |
>   > | Max window size reported
>   > | Correct handling of fragmented packets
>   > |
>   > | --
>   > | Help        mailto:majordomo@net.doit.wisc.edu and say
>   > "help" in message
>   > body
>   > | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe
>   > | ipfix" in message body
>   > | Archive     http://ipfix.doit.wisc.edu/archive/
>   > |
>   >
> 
>   --
>   Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>   Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>   "unsubscribe ipfix" in message body
>   Archive     http://ipfix.doit.wisc.edu/archive/
> 
> ----- End forwarded message -----
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 10:44:17 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20108
	for ; Tue, 18 Jun 2002 10:44:17 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KJm4-0003I7-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 09:16:00 -0500
Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KJm1-0003HP-00
	for ipfix-arch@net.doit.wisc.edu; Tue, 18 Jun 2002 09:15:57 -0500
Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 18 Jun 2002 07:15:24 -0700
Message-ID: <3D0F402E.E64F83A5@riverstonenet.com>
Date: Tue, 18 Jun 2002 10:14:06 -0400
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ganesh Sadasivan 
CC: ipfix-arch@net.doit.wisc.edu
Subject: [ipfix-arch] Re: 
References: <20020613065259.83808.qmail@web12305.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jun 2002 14:15:25.0000 (UTC) FILETIME=[96DFFC80:01C216D2]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Ganesh Sadasivan wrote:
> 
> Paul,
> 
> > 5.1. Flow Classification
> >
> >    The collector MUST be able to map the flow to the
> corresponding
> >    property types defined by the flow type. This can
> be done only if
> >    the collector has a mapping from flow type
> identifier (carried in
> >    each flow record) to its actual structure. More
> details of how
> >    this can be achieved are described in section
> 5.???
> >
> >
> >    In addition the collector, when it receives the
> flow records, MAY
> >    need the following to interpret the flow records
> further:
> >
> >       A. Observation Point.
> >       B. Selection Criteria of Packets
> >
> >    As mentioned in section 2.1, a flow record can be
> better analyzed
> 
> [G] Notice that it mentioned that the flow
> can be "better analysed" and it is not a
> MUST. Eg. If 2 observation
> point A,B are measuring in flows in 2 different
> ways say A is sampling 1 in 5 and B is sampling
> 1 in 25. The collector can better analyse the
> information, if along with the flow information,
> the observation point is also specified.This is
> not something mandatory but is useful for a
> detailed analysis.

	Since the sampling rate needs to be reported with
	(or can be correlated to) the flow, why do I need
	the observation point. All the information needed
	is in front of me. 

	If you are saying the sampling rate is not correlated
	to the flow then how would an application interpret
	the flow information to begin with?

> 
> >    if the Observation Point from which it is
> measured is known. As
> >    such it is recommended that the flow record carry
> the Observation
> >    Point information along with the flow records
> when exported. In
> >    cases where there is a single observation point
> or where the
> >    observation point information is not relevant,
> the exporter MAY
> >    choose not to add this to the flow records.
> >
> 
>         I don't understand this section. What is flow
> classification?
> 
>         Also, A flow should be able to be interpreted
> regardless of
>         knowing the observation point. A single observation
> point may
>         map flows in 2 or more different ways. The fact that
> different
>         observation points map flows based on different
> criteria
>         is irrelevant. All the information needed to
> interpret the flow
>         must be passed up.
> 
> > 5.2.1. Function on properties that determines a flow
> type (Fi)
> >
> >    Packets that satisfy a function on the fields
> defined by the
> >    packet header fields or fields obtained while
> doing the packet
> >    processing or the properties of the packet
> itself.
> >
> >    Example:
> >
> >    Mask/Match of the fields that define a filter.
> The filter may be
> >    defined as {Protocol == TCP, Destination Port
> between 80 and 120}.
> >
> >
> >    could be used in any sequence to select
> >    packets.
> >
> 
>         I think it would it be better to say "Multiple such
> functions"
>         instead of filters?


	Agreed.

> 
> > 5.3. Selection Criteria for flows for export
> >
> >    The measurement device MAY define additional
> rules so that only
> >    certain flows records are picked up for export.
> This MAY be done
> >    by either of the two types of methods defined in
> 5.2.1 and
> >    5.2.2 or a combination of them.
> >
> >    Example:
> >
> >    Only the flow records which meet the following
> selection criteria
> >    are exported.
> >
> >       1 All flow records whose destination IP
> address matches
> >         {20.3.1.5}.
> >       2 Every other (.i.e. sampling rate 1 in 2)
> flow record whose
> >         destination IP address matches {160.0.1.30}.
> >
> 
>         I'm not sure I agree with this. I think you have
> defined
>         2 flows in #1 and #2.
> 
> [G] That is true.
> 
> Given that, both flows are exported.
>         I think maybe the "Selection Criteria" is really part
> of
>         the Flow Type.
> 
> [G] It could be a post-flow-measurement criteria
> also. So need not be fixed to flow-type.

	At a conceptual level I don't like having to different
	way of defining the same thing. At an implementation
	level, I can see the need to do it at different spots.
	
	In order to combine the 2, I think I would allow for 
	Flow-type to be applied in more than one place on the
	device. So the measuring device could apply flow-type 1 
	and then the post-flow-measurement to apply another 
	flow-type definition.
	
> 
> >       * Packet Counter
> >       * Dropped Packet Counter
> >       * Byte Counter
> >       * Dropped Byte Counter
> >       * Timestamp of the First Packet Observed
> >       * Timestamp of the Last Packet Observed
> 
>         Generally the last time stamp is the time at which
> he flow has expired (as described earlier).
> 
> The last
>         packet observed is not available unless each packet
>         is processed in software. So either we need another
>         field or a different definition.
> 
> [G] Just curious. Why do we need a last-packet
>  observed field?

	You need something that denotes the end of the
	flow. There are several ways to do it, start-time
	and duration, end-time and duration, start-time
	and end-time. My only point was the if end-time
	is defined as "last packet observed" the info
	will not be available unless the packets are
	processed in software.

> 
> >
> >       * Unique ID of the Observation Point
> >       * Unique ID of the Measuring Device
> 
>         As stated above, I disagree that these are part of
> flow definition.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 12:33:15 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25890
	for ; Tue, 18 Jun 2002 12:33:15 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KLiI-0005wL-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 11:20:14 -0500
Received: from login.caida.org ([192.172.226.78])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KLiG-0005wG-00
	for ipfix-arch@net.doit.wisc.edu; Tue, 18 Jun 2002 11:20:12 -0500
Received: from login.caida.org (localhost [127.0.0.1])
	by login.caida.org (8.12.1/8.12.1) with ESMTP id g5IGKBrx091210
	(version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 18 Jun 2002 09:20:11 -0700 (PDT)
Received: (from dmoore@localhost)
	by login.caida.org (8.12.1/8.12.1/Submit) id g5IGKBkv091209;
	Tue, 18 Jun 2002 09:20:11 -0700 (PDT)
Date: Tue, 18 Jun 2002 09:20:11 -0700
From: David Moore 
To: calato@riverstonenet.com
Cc: Ganesh Sadasivan , ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] Re:
Message-ID: <20020618092011.M84415@login.caida.org>
References: <20020613065259.83808.qmail@web12305.mail.yahoo.com> <3D0F402E.E64F83A5@riverstonenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D0F402E.E64F83A5@riverstonenet.com>
User-Agent: Mutt/1.3.23i
Precedence: bulk
Sender: majordomo listserver 

> > >       * Timestamp of the First Packet Observed
> > >       * Timestamp of the Last Packet Observed
> > 
> >         Generally the last time stamp is the time at which
> > he flow has expired (as described earlier).
> > 
> > The last
> >         packet observed is not available unless each packet
> >         is processed in software. So either we need another
> >         field or a different definition.
> > 
> > [G] Just curious. Why do we need a last-packet
> >  observed field?
> 
> 	You need something that denotes the end of the
> 	flow. There are several ways to do it, start-time
> 	and duration, end-time and duration, start-time
> 	and end-time. My only point was the if end-time
> 	is defined as "last packet observed" the info
> 	will not be available unless the packets are
> 	processed in software.

Why will the info not be available unless the packets are processed in
software?


The architecture document
(http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-02.txt)
and ipfix requirements document
(http://www.ccrle.nec.de/draft-ietf-ipfix-reqs-03.txt) both have
this picture.  Well the reqs document doesn't have sampling and
and says that can go other places, but otherwise the same.


                       packet header capturing
                                 |
                            timestamping
                                 |
                                 v
                          +----->+
                          |      |
                          |   sampling Si (1:1 in case of no sampling)
                          |      |
                          | classifying Fi (NULL when No criteria)
                          |      |
                          +------+
                                 |
                                 |
                                 v
                               Flows



Which suggest that one would be getting the timestamps in hardware, since it
places timestamping ahead of classifying, presumably to minimize the overhead
of variable length computation in the jittering the timestamps.

The ipfix reqs document also says in 5.4:
5.4.  Timestamps

   The metering process MUST be able to generate timestamps for the
   first and the last observed packet of a flow. The timestamp
   resolution MUST be at least the one of the sysUpTime [RFC1213], which
   is one centisecond.


So if you really think last observed packet timestamps are difficult
somehow, you should probably explain why, since all of the docs
are currently suggesting they be there.  And assuming that you are
getting timestamps as close to the packet reception as possible
(ie, before classifying), I don't see why it's difficult to have
this information.  But I'm guessing that is the problem, namely you
don't want to do timestamps on the card, just do it on the first
packet via a special case?

-- david

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 12:37:01 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25942
	for ; Tue, 18 Jun 2002 12:37:01 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KLoE-00061t-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 11:26:22 -0500
Received: from login.caida.org ([192.172.226.78])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KLoB-00061l-00
	for ipfix-req@net.doit.wisc.edu; Tue, 18 Jun 2002 11:26:19 -0500
Received: from login.caida.org (localhost [127.0.0.1])
	by login.caida.org (8.12.1/8.12.1) with ESMTP id g5IGQDrx091309
	(version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 18 Jun 2002 09:26:13 -0700 (PDT)
Received: (from dmoore@localhost)
	by login.caida.org (8.12.1/8.12.1/Submit) id g5IGQDMF091308;
	Tue, 18 Jun 2002 09:26:13 -0700 (PDT)
Date: Tue, 18 Jun 2002 09:26:13 -0700
From: David Moore 
To: calato@riverstonenet.com
Cc: David Moore ,
        "Cottrell, Les" ,
        "'K.C. Norseth'" , req ,
        "Logg, Connie A." ,
        colleen 
Subject: Re: [cottrell@SLAC.Stanford.EDU: RE: [ipfix-req] Ipfix features]
Message-ID: <20020618092613.N84415@login.caida.org>
References: <20020611233538.A71948@caida.org> <20020612091210.W84415@login.caida.org> <3D0F3C25.A60651D8@riverstonenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D0F3C25.A60651D8@riverstonenet.com>
User-Agent: Mutt/1.3.23i
Precedence: bulk
Sender: majordomo listserver 

On Tue, Jun 18, 2002 at 09:56:53AM -0400, calato@riverstonenet.com wrote:
> 
> Does reporting the fragment ID help? There is still an
> issue with reusing the fragment ID but given the same
> src/dst and a reasonably close time stamp might be
> good enough to figure it out after the fact (i.e. 
> combining a fragment flow and a full flow at the collector).

Well, if you report the ipid on packets w/ MF set or offset != 0,
that would be sufficient, however it will also create an awful lot
of exported flows.  A typical tunneling situation with each original
packet turning into 2 fragments at 1500 bytes and 20 bytes, using
the ipid will result in one export record for each original packet.
Which could readily result in hundreds to thousands of new flows
per second for tunneled traffic of only a couple Mbit/sec.

> 
> Paul
> 
> David Moore wrote:
> > 
> > This may be difficult to get "correct".  I assume correct means
> > something roughly like:
> > 1. maintain state to determine what ports apply for a non-first fragmented
> > packet.
> > 2. once a fragmented packet's ports are determined, add it into the
> > flow it would have gone into if it had ports.
> > 
> > A few comments:
> > 
> > A separate fragment/ipid timer would be needed to decide when to expire
> > the state.  RFC 791 recommends 15 seconds, which also seems to match
> > reasonably well with caida network measurements.
> > 
> > Fragments may come in any order (in particular linux sends them
> > from the back of the original packet backwards towards the front).
> > This means that you may see a fragment w/o port information before
> > you see the corresponding port information.  So you can't determine
> > which flow the fragment belongs to until a later point.
> > 
> > VPN and tunnel's cause a lot of fragmented traffic, which may occur
> > at high-speed depending on the endpoints, which may result in a
> > lot of state being needed.  A good garbage collection scheme may
> > be needed for this (as well as DoS attacks with fragmented packets).
> > 
> > Personally, I'd also like a flow field saying whether the packet
> > was fragmented or not.  So fragmented packets to/from host/port &
> > proto would be counted as a separate flow from non-fragmented
> > packets to/from host/port & proto.  This would be in addition to
> > any attempts to correctly assign ports to fragments.
> > 
> > -- david
> > 
> > ----- Forwarded message from "Cottrell, Les"  -----
> > 
> >   Date: Tue, 11 Jun 2002 15:00:47 -0700
> >   From: "Cottrell, Les" 
> >   Subject: RE: [ipfix-req] Ipfix features
> >   To: "'K.C. Norseth'" , req 
> >   Cc: "Logg, Connie A." 
> >   X-Mailer: Internet Mail Service (5.5.2653.19)
> > 
> >   As an example of IP fragmentation see:
> > 
> >   http://www.slac.stanford.edu/comp/net/netflow/afsexample.html
> > 
> >   > -----Original Message-----
> >   > From: K.C. Norseth [mailto:kcn@norseth.com]
> >   > Sent: Tuesday, June 11, 2002 10:33 AM
> >   > To: Cottrell, Les; req
> >   > Cc: Logg, Connie A.
> >   > Subject: Re: [ipfix-req] Ipfix features
> >   >
> >   >
> >   > Discusssion is healthy. Please elaborate on what you mean.
> >   >
> >   > K.C.
> >   > ----- Original Message -----
> >   > From: "Cottrell, Les" 
> >   > To: "req" 
> >   > Cc: "Logg, Connie A." 
> >   > Sent: Tuesday, June 11, 2002 11:16 AM
> >   > Subject: [ipfix-req] Ipfix features
> >   >
> >   >
> >   > | I hope this is not too off-subject, but in future realeases
> >   > of ipfix
> >   > | ttols
> >   > such as Netflow, I would like to see:
> >   > |
> >   > | Max window size reported
> >   > | Correct handling of fragmented packets
> >   > |
> >   > | --
> >   > | Help        mailto:majordomo@net.doit.wisc.edu and say
> >   > "help" in message
> >   > body
> >   > | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe
> >   > | ipfix" in message body
> >   > | Archive     http://ipfix.doit.wisc.edu/archive/
> >   > |
> >   >
> > 
> >   --
> >   Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> >   Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> >   "unsubscribe ipfix" in message body
> >   Archive     http://ipfix.doit.wisc.edu/archive/
> > 
> > ----- End forwarded message -----
> > 
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 13:03:15 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26633
	for ; Tue, 18 Jun 2002 13:03:14 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KMEA-0006cv-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 11:53:10 -0500
Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KME7-0006cC-00
	for ipfix-arch@net.doit.wisc.edu; Tue, 18 Jun 2002 11:53:07 -0500
Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 18 Jun 2002 09:52:35 -0700
Message-ID: <3D0F6506.9BC789F1@riverstonenet.com>
Date: Tue, 18 Jun 2002 12:51:18 -0400
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Moore 
CC: Ganesh Sadasivan , ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] Re:
References: <20020613065259.83808.qmail@web12305.mail.yahoo.com> <3D0F402E.E64F83A5@riverstonenet.com> <20020618092011.M84415@login.caida.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jun 2002 16:52:36.0540 (UTC) FILETIME=[8C82C7C0:01C216E8]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

David Moore wrote:
> 
> > > >       * Timestamp of the First Packet Observed
> > > >       * Timestamp of the Last Packet Observed
> > >
> > >         Generally the last time stamp is the time at which
> > > he flow has expired (as described earlier).
> > >
> > > The last
> > >         packet observed is not available unless each packet
> > >         is processed in software. So either we need another
> > >         field or a different definition.
> > >
> > > [G] Just curious. Why do we need a last-packet
> > >  observed field?
> >
> >       You need something that denotes the end of the
> >       flow. There are several ways to do it, start-time
> >       and duration, end-time and duration, start-time
> >       and end-time. My only point was the if end-time
> >       is defined as "last packet observed" the info
> >       will not be available unless the packets are
> >       processed in software.
> 
> Why will the info not be available unless the packets are processed in
> software?
> 
> The architecture document
> (http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-02.txt)
> and ipfix requirements document
> (http://www.ccrle.nec.de/draft-ietf-ipfix-reqs-03.txt) both have
> this picture.  Well the reqs document doesn't have sampling and
> and says that can go other places, but otherwise the same.
> 
>                        packet header capturing
>                                  |
>                             timestamping
>                                  |
>                                  v
>                           +----->+
>                           |      |
>                           |   sampling Si (1:1 in case of no sampling)
>                           |      |
>                           | classifying Fi (NULL when No criteria)
>                           |      |
>                           +------+
>                                  |
>                                  |
>                                  v
>                                Flows
> 
> Which suggest that one would be getting the timestamps in hardware, since it
> places timestamping ahead of classifying, presumably to minimize the overhead
> of variable length computation in the jittering the timestamps.
> 
> The ipfix reqs document also says in 5.4:
> 5.4.  Timestamps
> 
>    The metering process MUST be able to generate timestamps for the
>    first and the last observed packet of a flow. The timestamp
>    resolution MUST be at least the one of the sysUpTime [RFC1213], which
>    is one centisecond.
> 
> So if you really think last observed packet timestamps are difficult
> somehow, you should probably explain why, since all of the docs
> are currently suggesting they be there.  And assuming that you are
> getting timestamps as close to the packet reception as possible
> (ie, before classifying), I don't see why it's difficult to have
> this information.  But I'm guessing that is the problem, namely you
> don't want to do timestamps on the card, just do it on the first
> packet via a special case?
> 
	Right. I don't think most hardware timestamps every packet.
	Which is why I said we either need another field or
	another definition. But as you pointed out, there are
	other areas of the doc that will need to change too.
	

> -- david

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 13:21:26 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27219
	for ; Tue, 18 Jun 2002 13:21:26 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KMTp-0006vD-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 12:09:21 -0500
Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KMTn-0006ud-00
	for ipfix-req@net.doit.wisc.edu; Tue, 18 Jun 2002 12:09:19 -0500
Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 18 Jun 2002 10:08:46 -0700
Message-ID: <3D0F68D0.87ED5FC2@riverstonenet.com>
Date: Tue, 18 Jun 2002 13:07:28 -0400
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Logg, Connie A." 
CC: "'David Moore'" ,
        "Cottrell, Les" ,
        "'K.C. Norseth'" , req ,
        colleen 
Subject: Re: [cottrell@SLAC.Stanford.EDU: RE: [ipfix-req] Ipfix features]
References: <2846497B437BF84BAD1A4CC407418D26D13958@exchange1.slac.stanford.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jun 2002 17:08:47.0512 (UTC) FILETIME=[CF415980:01C216EA]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


Isn't the other problem that if fragemented flows are lumped 
into src, dst, proto, zero-src-port, zero-dst-port then
there are possibly multiple fragements counted in
one flow? 

Paul

"Logg, Connie A." wrote:
> 
> Actually, given the additional experience I have had in the last 3 months on processing metflow and extracting parallel streams,
> it is likely (although I do not have time to look at it now), that by sorting the traffic by src, dest, and time, one can probably
> match up the data fragments.  However there is a catch here.  It would hard to do this on the fly as the packets may be split over 2 or more netflow files (I cut files every 10 minutes) and process each file on the fly for time series rrd's.  It would have to be done in the overnight processing. That is where I currently extract and match parallel streams.  I can look into it in August.
> 
> Connie Logg - Network Analyst - 650-926-2879
> Stanford Linear Accelerator Center
> MS 97; 2575 SandHill Road; Menlo Park CA 94025
> "Happiness is found along the way, not at the end of the road"
> 
> -----Original Message-----
> From: David Moore [mailto:dmoore@caida.org]
> Sent: Tuesday, June 18, 2002 9:26 AM
> To: calato@riverstonenet.com
> Cc: David Moore; Cottrell, Les; 'K.C. Norseth'; req; Logg, Connie A.;
> colleen
> Subject: Re: [cottrell@SLAC.Stanford.EDU: RE: [ipfix-req] Ipfix
> features]
> 
> On Tue, Jun 18, 2002 at 09:56:53AM -0400, calato@riverstonenet.com wrote:
> >
> > Does reporting the fragment ID help? There is still an
> > issue with reusing the fragment ID but given the same
> > src/dst and a reasonably close time stamp might be
> > good enough to figure it out after the fact (i.e.
> > combining a fragment flow and a full flow at the collector).
> 
> Well, if you report the ipid on packets w/ MF set or offset != 0,
> that would be sufficient, however it will also create an awful lot
> of exported flows.  A typical tunneling situation with each original
> packet turning into 2 fragments at 1500 bytes and 20 bytes, using
> the ipid will result in one export record for each original packet.
> Which could readily result in hundreds to thousands of new flows
> per second for tunneled traffic of only a couple Mbit/sec.
> 
> >
> > Paul
> >
> > David Moore wrote:
> > >
> > > This may be difficult to get "correct".  I assume correct means
> > > something roughly like:
> > > 1. maintain state to determine what ports apply for a non-first fragmented
> > > packet.
> > > 2. once a fragmented packet's ports are determined, add it into the
> > > flow it would have gone into if it had ports.
> > >
> > > A few comments:
> > >
> > > A separate fragment/ipid timer would be needed to decide when to expire
> > > the state.  RFC 791 recommends 15 seconds, which also seems to match
> > > reasonably well with caida network measurements.
> > >
> > > Fragments may come in any order (in particular linux sends them
> > > from the back of the original packet backwards towards the front).
> > > This means that you may see a fragment w/o port information before
> > > you see the corresponding port information.  So you can't determine
> > > which flow the fragment belongs to until a later point.
> > >
> > > VPN and tunnel's cause a lot of fragmented traffic, which may occur
> > > at high-speed depending on the endpoints, which may result in a
> > > lot of state being needed.  A good garbage collection scheme may
> > > be needed for this (as well as DoS attacks with fragmented packets).
> > >
> > > Personally, I'd also like a flow field saying whether the packet
> > > was fragmented or not.  So fragmented packets to/from host/port &
> > > proto would be counted as a separate flow from non-fragmented
> > > packets to/from host/port & proto.  This would be in addition to
> > > any attempts to correctly assign ports to fragments.
> > >
> > > -- david
> > >
> > > ----- Forwarded message from "Cottrell, Les"  -----
> > >
> > >   Date: Tue, 11 Jun 2002 15:00:47 -0700
> > >   From: "Cottrell, Les" 
> > >   Subject: RE: [ipfix-req] Ipfix features
> > >   To: "'K.C. Norseth'" , req 
> > >   Cc: "Logg, Connie A." 
> > >   X-Mailer: Internet Mail Service (5.5.2653.19)
> > >
> > >   As an example of IP fragmentation see:
> > >
> > >   http://www.slac.stanford.edu/comp/net/netflow/afsexample.html
> > >
> > >   > -----Original Message-----
> > >   > From: K.C. Norseth [mailto:kcn@norseth.com]
> > >   > Sent: Tuesday, June 11, 2002 10:33 AM
> > >   > To: Cottrell, Les; req
> > >   > Cc: Logg, Connie A.
> > >   > Subject: Re: [ipfix-req] Ipfix features
> > >   >
> > >   >
> > >   > Discusssion is healthy. Please elaborate on what you mean.
> > >   >
> > >   > K.C.
> > >   > ----- Original Message -----
> > >   > From: "Cottrell, Les" 
> > >   > To: "req" 
> > >   > Cc: "Logg, Connie A." 
> > >   > Sent: Tuesday, June 11, 2002 11:16 AM
> > >   > Subject: [ipfix-req] Ipfix features
> > >   >
> > >   >
> > >   > | I hope this is not too off-subject, but in future realeases
> > >   > of ipfix
> > >   > | ttols
> > >   > such as Netflow, I would like to see:
> > >   > |
> > >   > | Max window size reported
> > >   > | Correct handling of fragmented packets
> > >   > |
> > >   > | --
> > >   > | Help        mailto:majordomo@net.doit.wisc.edu and say
> > >   > "help" in message
> > >   > body
> > >   > | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe
> > >   > | ipfix" in message body
> > >   > | Archive     http://ipfix.doit.wisc.edu/archive/
> > >   > |
> > >   >
> > >
> > >   --
> > >   Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> > >   Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > >   "unsubscribe ipfix" in message body
> > >   Archive     http://ipfix.doit.wisc.edu/archive/
> > >
> > > ----- End forwarded message -----
> > >
> > > --
> > > Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > > "unsubscribe ipfix" in message body
> > > Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 16:07:16 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03003
	for ; Tue, 18 Jun 2002 16:07:16 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KOsU-0002N9-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 14:42:58 -0500
Received: from maple.arbor.net ([204.181.64.21])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KOsQ-0002N0-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Jun 2002 14:42:54 -0500
Received: by maple.arbor.net (Postfix, from userid 1010)
	id A945088724; Tue, 18 Jun 2002 15:42:43 -0400 (EDT)
Date: Tue, 18 Jun 2002 15:42:43 -0400
From: Robert Stone 
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] "long aging" flows
Message-ID: <20020618154243.B28585@arbor.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Precedence: bulk
Sender: majordomo listserver 

Sorry, I haven't been doing a good job of keeping up with the list so
hopefully this isn't redundant.  Anyway,

in draft-ietf-ipfix-architecture-02, in the section:

7. Flow Expiration
...

     2. If the flow has been inactive for a certain period of time.
        This inactivity timeout SHOULD be configurable.  For example:
        flow generated by UDP type of traffic.

     3. For long aging flows, the exporter SHOULD export the flow
        records on regular basis, in order to:

          a. Report the flow records periodic accounting information to
             the collector
          b. Avoid counter wrapping This activity timeout SHOULD be
             configurable


I would add something like:

          c. Prevent an attacker from indefinitely delaying the delivery 
             of flow information to an (e.g. IDS) application by
             generating packets which fall within long aging flows.

Also, for "IDS" type applications some configuration option for #3
is really a must.  This "active timeout" or "update interval" could
default to some long value (30 minutes, for example) but it's pretty
critical to time and security sentitive applications that it be
configurable.

Robert Stone
Arbor Networks

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 18 22:16:52 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11600
	for ; Tue, 18 Jun 2002 22:16:52 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KUmL-0002Hl-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Jun 2002 21:01:01 -0500
Received: from h013.c001.snv.cp.net ([209.228.32.127] helo=c001.snv.cp.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 17KUmH-0002GX-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Jun 2002 21:00:57 -0500
Received: (cpmta 28060 invoked from network); 18 Jun 2002 19:00:25 -0700
Received: from 24.221.253.53 (HELO kcn)
  by smtp.register-admin.com (209.228.32.127) with SMTP; 18 Jun 2002 19:00:25 -0700
X-Sent: 19 Jun 2002 02:00:25 GMT
Message-ID: <00f401c21735$3a2e65e0$850f880a@kcn>
From: "K.C. Norseth" 
To: "Robert Stone" , 
References: <20020618154243.B28585@arbor.net>
Subject: Re: [ipfix] "long aging" flows
Date: Tue, 18 Jun 2002 20:01:28 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hi Robert,

----- Original Message -----
From: "Robert Stone" 
To: 
Sent: Tuesday, June 18, 2002 1:42 PM
Subject: [ipfix] "long aging" flows


| Sorry, I haven't been doing a good job of keeping up with the list so
| hopefully this isn't redundant.  Anyway,
|
| in draft-ietf-ipfix-architecture-02, in the section:
|
| 7. Flow Expiration
| ...
|
|      2. If the flow has been inactive for a certain period of time.
|         This inactivity timeout SHOULD be configurable.  For example:
|         flow generated by UDP type of traffic.
|
|      3. For long aging flows, the exporter SHOULD export the flow
|         records on regular basis, in order to:
|
|           a. Report the flow records periodic accounting information to
|              the collector
|           b. Avoid counter wrapping This activity timeout SHOULD be
|              configurable
|
|
| I would add something like:
|
|           c. Prevent an attacker from indefinitely delaying the delivery
|              of flow information to an (e.g. IDS) application by
|              generating packets which fall within long aging flows.

Agreed.

| Also, for "IDS" type applications some configuration option for #3
| is really a must.  This "active timeout" or "update interval" could
| default to some long value (30 minutes, for example) but it's pretty
| critical to time and security sentitive applications that it be
| configurable.

Agreed.  For me, this was a given, but if they want it for IDS, then it MUST
be configurable.

K.C.

| Robert Stone
| Arbor Networks
|
| --
| Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
| Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
| "unsubscribe ipfix" in message body
| Archive     http://ipfix.doit.wisc.edu/archive/
|


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jun 19 13:42:55 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28691
	for ; Wed, 19 Jun 2002 13:42:55 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KjFi-0000DZ-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Jun 2002 12:28:18 -0500
Received: from web12306.mail.yahoo.com ([216.136.173.104])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 17KjFf-0000DT-00
	for ipfix-arch@net.doit.wisc.edu; Wed, 19 Jun 2002 12:28:15 -0500
Message-ID: <20020619172814.85329.qmail@web12306.mail.yahoo.com>
Received: from [203.200.151.23] by web12306.mail.yahoo.com via HTTP; Wed, 19 Jun 2002 10:28:14 PDT
Date: Wed, 19 Jun 2002 10:28:14 -0700 (PDT)
From: Ganesh Sadasivan 
Subject: [ipfix-arch] Re: 
To: calato@riverstonenet.com
Cc: ipfix-arch@net.doit.wisc.edu
In-Reply-To: <3D0F402E.E64F83A5@riverstonenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 


--- calato@riverstonenet.com wrote:
> Ganesh Sadasivan wrote:
> > 
> > Paul,
> > 
> > > 5.1. Flow Classification
> > >
> > >    The collector MUST be able to map the flow to
> the
> > corresponding
> > >    property types defined by the flow type. This
> can
> > be done only if
> > >    the collector has a mapping from flow type
> > identifier (carried in
> > >    each flow record) to its actual structure.
> More
> > details of how
> > >    this can be achieved are described in section
> > 5.???
> > >
> > >
> > >    In addition the collector, when it receives
> the
> > flow records, MAY
> > >    need the following to interpret the flow
> records
> > further:
> > >
> > >       A. Observation Point.
> > >       B. Selection Criteria of Packets
> > >
> > >    As mentioned in section 2.1, a flow record
> can be
> > better analyzed
> > 
> > [G] Notice that it mentioned that the flow
> > can be "better analysed" and it is not a
> > MUST. Eg. If 2 observation
> > point A,B are measuring in flows in 2 different
> > ways say A is sampling 1 in 5 and B is sampling
> > 1 in 25. The collector can better analyse the
> > information, if along with the flow information,
> > the observation point is also specified.This is
> > not something mandatory but is useful for a
> > detailed analysis.
> 
> 	Since the sampling rate needs to be reported with
> 	(or can be correlated to) the flow, why do I need
> 	the observation point. All the information needed
> 	is in front of me. 
> 
> 	If you are saying the sampling rate is not
> correlated
> 	to the flow then how would an application interpret
> 	the flow information to begin with?

What I meant is that the observation point is the
correlation point between the configuration and the
flow records. Is it not better than sending the
config with the flow records?

> 
> > 
> > >    if the Observation Point from which it is
> > measured is known. As
> > >    such it is recommended that the flow record
> carry
> > the Observation
> > >    Point information along with the flow records
> > when exported. In
> > >    cases where there is a single observation
> point
> > or where the
> > >    observation point information is not
> relevant,
> > the exporter MAY
> > >    choose not to add this to the flow records.
> > >
> > 
> >         I don't understand this section. What is
> flow
> > classification?
> > 
> >         Also, A flow should be able to be
> interpreted
> > regardless of
> >         knowing the observation point. A single
> observation
> > point may
> >         map flows in 2 or more different ways. The
> fact that
> > different
> >         observation points map flows based on
> different
> > criteria
> >         is irrelevant. All the information needed
> to
> > interpret the flow
> >         must be passed up.
> > 
> > > 5.2.1. Function on properties that determines a
> flow
> > type (Fi)
> > >
> > >    Packets that satisfy a function on the fields
> > defined by the
> > >    packet header fields or fields obtained while
> > doing the packet
> > >    processing or the properties of the packet
> > itself.
> > >
> > >    Example:
> > >
> > >    Mask/Match of the fields that define a
> filter.
> > The filter may be
> > >    defined as {Protocol == TCP, Destination Port
> > between 80 and 120}.
> > >
> > >
> > >    could be used in any sequence to select
> > >    packets.
> > >
> > 
> >         I think it would it be better to say
> "Multiple such
> > functions"
> >         instead of filters?
> 
> 
> 	Agreed.
> 
> > 
> > > 5.3. Selection Criteria for flows for export
> > >
> > >    The measurement device MAY define additional
> > rules so that only
> > >    certain flows records are picked up for
> export.
> > This MAY be done
> > >    by either of the two types of methods defined
> in
> > 5.2.1 and
> > >    5.2.2 or a combination of them.
> > >
> > >    Example:
> > >
> > >    Only the flow records which meet the
> following
> > selection criteria
> > >    are exported.
> > >
> > >       1 All flow records whose destination IP
> > address matches
> > >         {20.3.1.5}.
> > >       2 Every other (.i.e. sampling rate 1 in 2)
> > flow record whose
> > >         destination IP address matches
> {160.0.1.30}.
> > >
> > 
> >         I'm not sure I agree with this. I think
> you have
> > defined
> >         2 flows in #1 and #2.
> > 
> > [G] That is true.
> > 
> > Given that, both flows are exported.
> >         I think maybe the "Selection Criteria" is
> really part
> > of
> >         the Flow Type.
> > 
> > [G] It could be a post-flow-measurement criteria
> > also. So need not be fixed to flow-type.
> 
> 	At a conceptual level I don't like having to
> different
> 	way of defining the same thing. At an
> implementation
> 	level, I can see the need to do it at different
> spots.
> 	
> 	In order to combine the 2, I think I would allow
> for 
> 	Flow-type to be applied in more than one place on
> the
> 	device. So the measuring device could apply
> flow-type 1 
> 	and then the post-flow-measurement to apply another
> 
> 	flow-type definition.

I don't disagree here. The main reason for this
separation is because of the metering process
definition in the requirement spec. The input to
metering porcess is always packets. So to provision
a room for post-flow-measurement, a differentiating
block is introduced.

> 	
> > 
> > >       * Packet Counter
> > >       * Dropped Packet Counter
> > >       * Byte Counter
> > >       * Dropped Byte Counter
> > >       * Timestamp of the First Packet Observed
> > >       * Timestamp of the Last Packet Observed
> > 
> >         Generally the last time stamp is the time
> at which
> > he flow has expired (as described earlier).
> > 
> > The last
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jun 19 14:42:34 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00550
	for ; Wed, 19 Jun 2002 14:42:33 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17KkD8-0001Yf-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Jun 2002 13:29:42 -0500
Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17KkD6-0001Y3-00
	for ipfix-arch@net.doit.wisc.edu; Wed, 19 Jun 2002 13:29:40 -0500
Received: from riverstonenet.com ([134.141.180.96]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 19 Jun 2002 11:29:07 -0700
Message-ID: <3D10CD46.119857A0@riverstonenet.com>
Date: Wed, 19 Jun 2002 14:28:22 -0400
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ganesh Sadasivan 
CC: ipfix-arch@net.doit.wisc.edu
Subject: [ipfix-arch] Re: 
References: <20020619172814.85329.qmail@web12306.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jun 2002 18:29:08.0232 (UTC) FILETIME=[330A9880:01C217BF]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Ganesh Sadasivan wrote:
> 
> --- calato@riverstonenet.com wrote:
> > Ganesh Sadasivan wrote:
> > >
> > > Paul,
> > >
> > > > 5.1. Flow Classification
> > > >
> > > >    The collector MUST be able to map the flow to
> > the
> > > corresponding
> > > >    property types defined by the flow type. This
> > can
> > > be done only if
> > > >    the collector has a mapping from flow type
> > > identifier (carried in
> > > >    each flow record) to its actual structure.
> > More
> > > details of how
> > > >    this can be achieved are described in section
> > > 5.???
> > > >
> > > >
> > > >    In addition the collector, when it receives
> > the
> > > flow records, MAY
> > > >    need the following to interpret the flow
> > records
> > > further:
> > > >
> > > >       A. Observation Point.
> > > >       B. Selection Criteria of Packets
> > > >
> > > >    As mentioned in section 2.1, a flow record
> > can be
> > > better analyzed
> > >
> > > [G] Notice that it mentioned that the flow
> > > can be "better analysed" and it is not a
> > > MUST. Eg. If 2 observation
> > > point A,B are measuring in flows in 2 different
> > > ways say A is sampling 1 in 5 and B is sampling
> > > 1 in 25. The collector can better analyse the
> > > information, if along with the flow information,
> > > the observation point is also specified.This is
> > > not something mandatory but is useful for a
> > > detailed analysis.
> >
> >       Since the sampling rate needs to be reported with
> >       (or can be correlated to) the flow, why do I need
> >       the observation point. All the information needed
> >       is in front of me.
> >
> >       If you are saying the sampling rate is not
> > correlated
> >       to the flow then how would an application interpret
> >       the flow information to begin with?
> 
> What I meant is that the observation point is the
> correlation point between the configuration and the
> flow records. 


	You could have an ID that maps to a flow definition and 
	then the ID is reported with the flow. The observation 
	point ID is not needed. So the definition gets reported 
	once and the ID is reported with each flow. I'm proposing 
	this kind of separation. Down stream I want the data to stand
	on its own without any required knowldge of devices.



> Is it not better than sending the
> config with the flow records?
> 
> >
> > >
> > > >    if the Observation Point from which it is
> > > measured is known. As
> > > >    such it is recommended that the flow record
> > carry
> > > the Observation
> > > >    Point information along with the flow records
> > > when exported. In
> > > >    cases where there is a single observation
> > point
> > > or where the
> > > >    observation point information is not
> > relevant,
> > > the exporter MAY
> > > >    choose not to add this to the flow records.
> > > >
> > >
> > >         I don't understand this section. What is
> > flow
> > > classification?
> > >
> > >         Also, A flow should be able to be
> > interpreted
> > > regardless of
> > >         knowing the observation point. A single
> > observation
> > > point may
> > >         map flows in 2 or more different ways. The
> > fact that
> > > different
> > >         observation points map flows based on
> > different
> > > criteria
> > >         is irrelevant. All the information needed
> > to
> > > interpret the flow
> > >         must be passed up.
> > >
> > > > 5.2.1. Function on properties that determines a
> > flow
> > > type (Fi)
> > > >
> > > >    Packets that satisfy a function on the fields
> > > defined by the
> > > >    packet header fields or fields obtained while
> > > doing the packet
> > > >    processing or the properties of the packet
> > > itself.
> > > >
> > > >    Example:
> > > >
> > > >    Mask/Match of the fields that define a
> > filter.
> > > The filter may be
> > > >    defined as {Protocol == TCP, Destination Port
> > > between 80 and 120}.
> > > >
> > > >
> > > >    could be used in any sequence to select
> > > >    packets.
> > > >
> > >
> > >         I think it would it be better to say
> > "Multiple such
> > > functions"
> > >         instead of filters?
> >
> >
> >       Agreed.
> >
> > >
> > > > 5.3. Selection Criteria for flows for export
> > > >
> > > >    The measurement device MAY define additional
> > > rules so that only
> > > >    certain flows records are picked up for
> > export.
> > > This MAY be done
> > > >    by either of the two types of methods defined
> > in
> > > 5.2.1 and
> > > >    5.2.2 or a combination of them.
> > > >
> > > >    Example:
> > > >
> > > >    Only the flow records which meet the
> > following
> > > selection criteria
> > > >    are exported.
> > > >
> > > >       1 All flow records whose destination IP
> > > address matches
> > > >         {20.3.1.5}.
> > > >       2 Every other (.i.e. sampling rate 1 in 2)
> > > flow record whose
> > > >         destination IP address matches
> > {160.0.1.30}.
> > > >
> > >
> > >         I'm not sure I agree with this. I think
> > you have
> > > defined
> > >         2 flows in #1 and #2.
> > >
> > > [G] That is true.
> > >
> > > Given that, both flows are exported.
> > >         I think maybe the "Selection Criteria" is
> > really part
> > > of
> > >         the Flow Type.
> > >
> > > [G] It could be a post-flow-measurement criteria
> > > also. So need not be fixed to flow-type.
> >
> >       At a conceptual level I don't like having to
> > different
> >       way of defining the same thing. At an
> > implementation
> >       level, I can see the need to do it at different
> > spots.
> >
> >       In order to combine the 2, I think I would allow
> > for
> >       Flow-type to be applied in more than one place on
> > the
> >       device. So the measuring device could apply
> > flow-type 1
> >       and then the post-flow-measurement to apply another
> >
> >       flow-type definition.
> 
> I don't disagree here. The main reason for this
> separation is because of the metering process
> definition in the requirement spec. The input to
> metering porcess is always packets. So to provision
> a room for post-flow-measurement, a differentiating
> block is introduced.

	Sounds like we're on the same page. 

	But I've raised this issue before and will again
	when I give comments on the latest req and arch docs.

	I see an iterative process here. Requiring packets as
	an input I think is a mistake. I should be able to input
	"flow data" reguardless of where it comes from.
	Then I can apply these functions in a successive fasion
	at many points in the system.
> 
> >
> > >
> > > >       * Packet Counter
> > > >       * Dropped Packet Counter
> > > >       * Byte Counter
> > > >       * Dropped Byte Counter
> > > >       * Timestamp of the First Packet Observed
> > > >       * Timestamp of the Last Packet Observed
> > >
> > >         Generally the last time stamp is the time
> > at which
> > > he flow has expired (as described earlier).
> > >
> > > The last
> >
> === message truncated ===
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jun 20 22:08:34 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18537
	for ; Thu, 20 Jun 2002 22:08:33 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17LDak-0004rC-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Jun 2002 20:52:02 -0500
Received: from web12307.mail.yahoo.com ([216.136.173.105])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 17LDah-0004qh-00
	for ipfix-arch@net.doit.wisc.edu; Thu, 20 Jun 2002 20:51:59 -0500
Message-ID: <20020621015158.7999.qmail@web12307.mail.yahoo.com>
Received: from [203.200.150.58] by web12307.mail.yahoo.com via HTTP; Thu, 20 Jun 2002 18:51:58 PDT
Date: Thu, 20 Jun 2002 18:51:58 -0700 (PDT)
From: Ganesh Sadasivan 
Subject: [ipfix-arch] Re: 
To: calato@riverstonenet.com
Cc: ipfix-arch@net.doit.wisc.edu
In-Reply-To: <3D10CD46.119857A0@riverstonenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 


--- calato@riverstonenet.com wrote:
> Ganesh Sadasivan wrote:
> > 
> > --- calato@riverstonenet.com wrote:
> > > Ganesh Sadasivan wrote:
> > > >
> > > > Paul,
> > > >
> > > > > 5.1. Flow Classification
> > > > >
> > > > >    The collector MUST be able to map the
> flow to
> > > the
> > > > corresponding
> > > > >    property types defined by the flow type.
> This
> > > can
> > > > be done only if
> > > > >    the collector has a mapping from flow
> type
> > > > identifier (carried in
> > > > >    each flow record) to its actual
> structure.
> > > More
> > > > details of how
> > > > >    this can be achieved are described in
> section
> > > > 5.???
> > > > >
> > > > >
> > > > >    In addition the collector, when it
> receives
> > > the
> > > > flow records, MAY
> > > > >    need the following to interpret the flow
> > > records
> > > > further:
> > > > >
> > > > >       A. Observation Point.
> > > > >       B. Selection Criteria of Packets
> > > > >
> > > > >    As mentioned in section 2.1, a flow
> record
> > > can be
> > > > better analyzed
> > > >
> > > > [G] Notice that it mentioned that the flow
> > > > can be "better analysed" and it is not a
> > > > MUST. Eg. If 2 observation
> > > > point A,B are measuring in flows in 2
> different
> > > > ways say A is sampling 1 in 5 and B is
> sampling
> > > > 1 in 25. The collector can better analyse the
> > > > information, if along with the flow
> information,
> > > > the observation point is also specified.This
> is
> > > > not something mandatory but is useful for a
> > > > detailed analysis.
> > >
> > >       Since the sampling rate needs to be
> reported with
> > >       (or can be correlated to) the flow, why do
> I need
> > >       the observation point. All the information
> needed
> > >       is in front of me.
> > >
> > >       If you are saying the sampling rate is not
> > > correlated
> > >       to the flow then how would an application
> interpret
> > >       the flow information to begin with?
> > 
> > What I meant is that the observation point is the
> > correlation point between the configuration and
> the
> > flow records. 
> 
> 
> 	You could have an ID that maps to a flow definition
> and 
> 	then the ID is reported with the flow. The
> observation 
> 	point ID is not needed. So the definition gets
> reported 
> 	once and the ID is reported with each flow. I'm
> proposing 
> 	this kind of separation. Down stream I want the
> data to stand
> 	on its own without any required knowldge of
> devices.

Ok. The degenerate case is that one could have 
config per observation ID in which case reusing
the observation ID is useful. Otherwise you
are correct, it is better t have a separate ID.

I did not understand your last sentence.
"Down stream I want the data to stand
on its own without any required knowldge of
devices."

-Ganesh



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jun 21 06:32:01 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06446
	for ; Fri, 21 Jun 2002 06:32:00 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17LLK2-0000s3-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Jun 2002 05:07:18 -0500
Received: from mailhub.fokus.gmd.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17LLJz-0000rv-00
	for ipfix-app@net.doit.wisc.edu; Fri, 21 Jun 2002 05:07:15 -0500
Received: from fokus.fhg.de (dhcp159 [195.37.78.159])
	by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g5LA7DW03105
	for ; Fri, 21 Jun 2002 12:07:13 +0200 (MEST)
Message-ID: <3D12FA83.8040906@fokus.fhg.de>
Date: Fri, 21 Jun 2002 12:05:55 +0200
From: Tanja Zseby 
Organization: FhI FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: ipfix-app@net.doit.wisc.edu
Subject: [ipfix-app] applicability draft
Content-Type: multipart/mixed;
 boundary="------------080200080805070407090607"
Precedence: bulk
Sender: majordomo listserver 

This is a multi-part message in MIME format.
--------------080200080805070407090607
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I submitted the new version of the applicability document (attached) as 
internet draft.

Regards
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
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)
--------------------------------------------------------------------------------------


--------------080200080805070407090607
Content-Type: text/plain;
 name="draft-zseby-ipfix-applicability-00.txt"
Content-Disposition: inline;
 filename="draft-zseby-ipfix-applicability-00.txt"
Content-Transfer-Encoding: 7bit

Internet Draft					Tanja Zseby
draft-zseby-ipfix-applicability-00.txt		FhI FOKUS
Expires: November 2002				Reinaldo Penno
						Nortel Networks
						Nevil Brownlee
						CAIDA 
	
						June 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. 

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.



1. INTRODUCTION							2
2. APPLICATIONS OF IPFIX					2
2.1. ACCOUNTING WITH IPFIX					2
2.2. INTRUSION DETECTION WITH IPFIX				2
2.3. QOS MONITORING WITH IPFIX					3
2.3.1. Measurement of Round-trip-time (RTT) with IPFIX		3
2.3.2. Measurement of One-way-delay (OWD) with IPFIX		4
2.3.3. Measurement of Loss with IPFIX				4
2.3.4. Measurement of delay variation with IPFIX		4
2.3.5. Sampling for QoS Monitoring				5
3. RELATION OF IPFIX TO OTHER FRAMEWORKS AND PROTOCOLS		5
3.1. IPFIX AND AAA						5
3.1.1. Connecting via an AAA Client				6
3.1.2. Connecting via an Application Specific Module (ASM)	6
3.2. IPFIX AND RTFM						7	
3.2.1. Definition of 'flow'					7
3.2.2. Configuration and Management				8
3.2.3. Data Model details					9
3.2.4. Application/transport protocol				9
3.3. IPFIX CONSIDERATIONS FOR MIDDLEBOXES			10
3.3.1. Firewall							11
3.3.2. Network Address Translation				11
3.3.3. Traffic Conditioners					13
3.3.4. Tunneling						14
3.3.5. VPNs							14
4. SECURITY CONSIDERATION					16

1. Introduction

The IPFIX protocol defines how IP Flow information can be exported 
from routers, measurement probes or other devices. It is intended to 
provide input for various applications. This document describes how 
applications can use the IPFIX protocol. Furthermore the relationship 
of IPFIX to other frameworks and architectures are described.

2. Applications of IPFIX

2.1.Accounting with IPFIX 

Usage based accounting is one of the major application for which the 
IPFIX protocol has been developed. IPFIX flow records contain the 
number of transferred bytes per flow. This information is an 
essential input for usage-based accounting.

In order to realize usage-based accounting with IPFIX the flow 
definition has to be chosen in accordance to the tariff model. A 
tariff can for instance be based on individual end-to-end stream. 
Accounting in such a scenario can be realized for instance with a 
flow definition determined by the quintuple that consists of source 
address, destination address, protocol and portnumbers. Another 
example is a class-dependent tariff (e.g. in a DiffServ networks). 
For this flows could be distinguished just by DiffServ codepoint 
(DSCP) and source address.


2.2.Intrusion detection with IPFIX 

Intrusion detection systems (IDS) monitor and control security 
incidents. A typical IDS system includes components like sensor, 
event collector, and management stations. Sensors monitor network and 
system traffic for attacks and other security-related events. Sensors 
respond to and notify the administrator about these events as they 
occur. Event collectors are a middle-tier component responsible for 
transmitting events from sensors to the console and database. The 
management component serves the following purposes:

  - visually monitors events (with a console)
  - collects data from sensors (with one or more event collectors)
  - stores data from sensors (in a database)

With IPFIX, events of interest can be reported to the sensor either 
by the collecting process or directly by the exporting process. It 
depends on the scenario and the events of interest which solution is 
better. Getting information directly from the exporting process has 
the advantage that the sensor gets the information faster. It does 
not need to wait for collector processing time or until the collector 
has all relevant data. 
Getting the information from a collector allows to correlate data 
from different exporting processes (e.g. from different routers) to 
get a better picture about what is going on in the network.

2.3.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 
transmission quality for single flows or traffic aggregates in the 
network. One example of its usefulness is 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.

2.3.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 [Brow00]. 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 metering process 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 packets. The 
capability to do this analysis is not part of the IPFIX requirements
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.

2.3.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 necessary to recognize packets at the 
second measurement point to correlate packet arrival events from both 
points. This can be done by capturing packet header and parts of the 
packet that can be used to recognize the same packet at the 
subsequent measurement point.
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. 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 sufficient solution. 

2.3.3.Measurement of Loss with IPFIX

Passive loss measurements for single flows can be performed at one 
measurement point 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 by the IPFIX 
metering process. 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. 

2.3.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 calculating the 
differences. 

2.3.5.Sampling for QoS Monitoring

Since QoS monitoring can produce an overwhelming amount of 
measurement data, methods such as aggregation of results, and 
sampling would greatly increase the efficiency of the collection and 
analysis process. 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 
heavily depends on the deployed sampling strategy, the application 
that receives the data needs to be aware of the sampling scheme and 
the parameters in use. Therefore it is important that the IPFIX 
exporter informs the collector precisely about the used sampling 
strategy. This is especially important if the metering process 
dynamically invokes sampling.

3. Relation of IPFIX to other frameworks and protocols 

3.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 [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 transfer of accounting records. 
Usage-based accounting requires measurement data from the network. 
IPFIX defines a protocol to export such data from routers, 
measurement probes and other devices.

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: 

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


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


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

Figure 3: IPFIX connects to AAA server via ASM


3.2.IPFIX and RTFM 

This section compares the Real-time Traffic Flow Measurement (RTFM) 
framework with the IPFIX framework.

3.2.1.Definition of 'flow'

RTFM and IPFIX both use the same definition of flow; a flow is a set
of packets which share a common set of end-point address attribute 
values.A flow is therefore completely specified by that set of 
values, together with an inactivity timeout.  A flow is considered to 
have ended when no packets are seen for at least the inactivity time.

RTFM flows are bidirectional, which has given rise to some confusion.
At the simplest level, a flow information exporter may achieve this
by maintaining two unidirectional flows, one for each direcion.  To
export bidirectional flow information, e.g. to- and from- packet 
counts, for a flow from A to B, the exporter has only to search its 
flow table to find the matching flow from B to A.

RTFM, however, takes bi-directionality a stage further, by including
in the RTFM architecture [RFC 2722] a fully-detailed algorithm for
realtime matching of the two directions of a flow.  This was done
for two reasons, to reduce the memory required to store each
flow (common address attributes for each direction), and to allow
for attributes which required fine detail for the two directions,
e.g. short-term bit rate distributions [RFC 2724].
** So far there has been no suggestion that IPFIX should do this.

3.2.2.Configuration and Management

The RTFM architecture specifies a complete system for gathering
flow information.  It defines three entities,
 - Meters are very similar to IPFIX exporters.
 - Meter Readers are very similar to IPFIX collectors.
 - Managers co-ordinate the activities of meters and meter readers,
      and download configuration to them.

Note that the whole RTFM system is asynchronous, many readers may
collector flow data from a meter, and any reader may collect flow
data from many meters.

Rulesets allow the user to specify which flows are of interest,
which are the source and destination ends of each flow, and
what level of address granularity is required in the metered flows.
For example, one may select all packets from 192.168/16, but
build flow information for 192.168/24.  RTFM selection is done by 
testing under masks, and the masks do not have to use consective ones 
from the left.  Non-contiguous masks were considered important for 
handling some OSI protocols, but the need for that has diminished 
considerably.

The RTFM approach is based on RMON, in that if a user wants to 
collect flow data for some particular set of flows, this can be 
achieved by writing a ruleset, i.e. an SRL program [RFC 2723], to 
specify what flows are of interest, requesting a manager to download 
that ruleset to a meter, and requesting the manager to have a meter 
reader collect the flow data at specified intervals.

The details of how the manager communicates this information to 
meters and meter readers is not specified in the architecture.  RTFM 
has a Meter MIB [RFC 2720], which is a standard which can be used to
configure a meter, but nothing is said about how to configure a meter
reader.

The extent to which IPFIX should specify how meters or exporters
should be configured is, at this stage, an open question.  Clearly
a collector needs some way to be sure of what it's collecting,
e.g. by receiving 'templates' from the meter.

RTFM and IPFIX both leave parts of the system unspecified.  For RTFM
flow data to be useful one must know the ruleset used to configure 
the meter, but a user can specify the ruleset.  For IPFIX one knows 
what the data is from the templates, but we have yet to determine 
whether in-band configuration will be supported.

3.2.3.Data Model details

3.2.3.1.Count in one bucket

Within a ruleset, a packet may only be counted on one bucket, i.e. it
may only be included in one flow.  This means that the meter does not
have to keep track of overlapping flows - if such aggregation is
required, it must be done after the raw flow data has been read by a
meter reader.

From time to time one may wish to collect flow data for different
levels of aggreation at the same time.  RTFM allows a meter to run
several rulesets at the same time, and meter readers must specify
which rulesets they are collecting data from.

The 'count in one bucket' rule, together with the ability to run
multiple rulesets, has proved very simple and effective in practice.

3.2.3.2.Counter wrapping

For its packet- and byte-count attributes RTFM uses continuously-
incrementing 64-bit counters, which are never reset.  This makes
asynchronous meter reading easy, any reader simply has to remember 
its previous reading and compute the difference.  The only caveat is that
the meter should be read often enough to avoid situations when the
counter has cycled more than once between readings.

3.2.3.3.Sampling issues

RTFM provides 1 out of N sampling as a configuration option, so
that some metering interfaces may only process every Nth packet.
The RTFM Arcitecture [RFC 2722] does not discuss the statistical
implications of this, merely saying that users will need to
satisfy themselves that sampling makes sense in their environment.

RTFM makes no provision for flow sampling.  Recently there has been a
lot of interest in flow sampling schemes which favour the 'most
important' flows, perhaps we need to consider this for IPFIX.  

3.2.4.Application/transport protocol

RTFM has a standards-track Meter MIB [RFC 2720], which can be used
both to configure a meter and to read flow data from it.  The MIB
provides a way to read lists of attributes with a single Object
Identifier (called a 'package'), which dramatically reduces the SNMP
overhead for flow data collection.  NeTraMet, a widely-used
open-source RTFM implementation, uses SNMPv2C for configuration and
data collection.

SNMP, of course, normally uses UDP as its transport protocol.
Since RTFM requires a reliable flow data transport system,
an RTFM meter reader must time out and resend unanswered SNMP 
requests.
Apart from being clumsy, this can limit the maximum data transfer
rate from meter to meter reader.  SNMP over TCP would be a better
approach, but that is currently an IRTF project.

On the other hand, RTFM does not specify an application protocol in
its architecture, leaving this as an implementation issue.  For
example, a team at IBM Research implemented a RTFM meter and meter
reader in a single host, with the reader storing the flow data
directly into a large database system.  Simlarly, many NeTraMet
user run the meter and meter reader on the same host system.
A need for high flow data rates highlights the need for careful
systems design when building a flow data collection system.  When 
data rates are high, and it is not possible to use a high level of
aggregation, then it makes sense to have the collectors very close to
their exporters.  Once the data is safely on a dedicated host 
machine, large volumes of it can be moved using 'background' 
techniques such as FTP.

The RTFM architecture only specifies a pull model for getting
data out of a meter.  To implement push mode data transfer would
require specification of triggers to indicate when data should
be sent for each flow.


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

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

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

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


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

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

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

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

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

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

3.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 factored 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).

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


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

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

3.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. Security Consideration

This document describes the usage of IPFIX in various scenarios. 
Currently only the IPFIX target applications (accounting, QoS 
monitoring, traffic profiling, traffic engineering and intrusion 
detection) are addressed. The security requirements for those 
applications are already addressed in the IPFIX requirements draft. 
These requirements must be considered for the selection and 
specification of the IPFIX protocol. The IPFIX extensions proposed in 
this document do not induce further security hazards.

The second section of this document describes how IPFIX can be used 
in combination with other frameworks. New security hazards can arise 
when two individually secure frameworks are combined. For the 
combination of AAA with IPFIX an ASM or an IPFIX collector can 
function as transit point for the messages. It has to be ensured that 
at this point the applied security mechanisms (e.g. encryption of 
messages) are maintained.


6. References

[QuZC02] J. Quittek ,et. Al "Requirements for IP Flow Information 
Export ", (work in progress) ,Internet Draft, Internet Engineering 
Task Force, , 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, , 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, , January 2002. 

[VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft 
, 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.

[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, 
"Generic AAA Architecture", RFC 2903, August 2000



7. Acknowledgements

We would like to thank the following persons for their contribution, 
discussion on the mailing list and valuable comments:

Robert Loewe


8. Author's Addresses

Tanja Zseby
Fraunhofer Institute for Open Communication Systems(FOKUS)  
Kaiserin-Augusta-Allee 31  
10589 Berlin  
Germany  
Phone: +49 30 3463 7153  
Email: zseby@fokus.fhg.de

Reinaldo Penno
Nortel Networks, Inc. 
2305 Mission College Boulevard
Building SC9-B1240  
Santa Clara, CA 95134
Email: rpenno@nortelnetworks.com 

Nevil Brownlee
CAIDA (UCSD/SDSC)
9500 Gilman Drive
La Jolla, CA 92093-0505
Phone : +1 858 534 8338
Email : nevil@caida.org



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.


--------------080200080805070407090607--



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jun 24 12:21:33 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15421
	for ; Mon, 24 Jun 2002 12:21:33 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17MWKI-0004E5-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Jun 2002 11:04:26 -0500
Received: from babar.switch.ch ([130.59.4.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17MWKF-0004Da-00
	for ipfix-data@net.doit.wisc.edu; Mon, 24 Jun 2002 11:04:23 -0500
Received: (from leinen@localhost)
	by babar.switch.ch (8.11.6+Sun/8.11.6) id g5OG3ZH01193;
	Mon, 24 Jun 2002 18:03:35 +0200 (MEST)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Ganesh Sadasivan 
Cc: ipfix-data@net.doit.wisc.edu, calato@riverstonenet.com
Subject: Re: [ipfix-data] Re: [ipfix] draft-ietf-ipfix-data-01.txt
References: <20020614171757.63072.qmail@web12307.mail.yahoo.com>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPdz,@ttmwYVO7l`6OXXYR`
From: Simon Leinen 
In-Reply-To: <20020614171757.63072.qmail@web12307.mail.yahoo.com>
Date: 24 Jun 2002 18:03:34 +0200
Message-ID: 
Lines: 36
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

>>>>> On Fri, 14 Jun 2002 10:17:57 -0700 (PDT), Ganesh Sadasivan  said:
>> Paul,
>> See my response in line starting with [G].
>> Thanks
>> Ganesh
[...]

>> >       * Packet Counter 
>> >       * Dropped Packet Counter 
>> >       * Byte Counter 
>> >       * Dropped Byte Counter
>> >       * Timestamp of the First Packet Observed 
>> >       * Timestamp of the Last Packet Observed 
>> 
>> Generally the last time stamp is the time at which
>> he flow has expired (as described earlier). 
>> 
>> The last packet observed is not available unless each packet is
>> processed in software.

Hm, that would imply that "only software" can update a per-flow
timestamp for every packet.  But even when all per-packet accounting
work is done "in hardware", it must be possible to update (increment)
byte/octet counters for every packet.  So it should also be possible
to copy a timestamp to the flow.  All that's needed is that the
("hardware") flow-updater needs access to a clock, and that memory
bandwidth to the per-flow table is sufficient to support that copy.

>> So either we need another field or a different definition.

>> [G] Just curious. Why do we need a last-packet observed field?

Because it makes it easier to compute approximate rates of flows.
It also nicely supports charging schemes with a usage time component.
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jun 25 12:36:00 2002
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14227
	for ; Tue, 25 Jun 2002 12:35:59 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 17Msyx-0007Fa-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Jun 2002 11:15:55 -0500
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 17Msyu-00075t-00
	for ipfix-req@net.doit.wisc.edu; Tue, 25 Jun 2002 11:15:52 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5PGFLK38082;
	Tue, 25 Jun 2002 18:15:21 +0200 (CEST)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA31089;
	Tue, 25 Jun 2002 18:10:19 +0200
Date: Tue, 25 Jun 2002 18:10:18 +0200
From: Juergen Quittek 
To: Tanja Zseby ,
        IPFIX Requirements 
Subject: [ipfix-req] Re: [Fwd: Re: version 3 of IPFIX requirements]
Message-ID: <35431247.1025028618@[192.168.102.164]>
In-Reply-To: <3D076901.3050602@fokus.fhg.de>
References:  <3D076901.3050602@fokus.fhg.de>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14227

Hi Tanja and all,

I am sorry, that all these suggested changes got "lost"
in the Internet. I want to submit another version of the
requirements draft including Tanja's "lost" changes before
the cut-off date.

If anyone else has suggestions for modifications, please
post them by Thursday, June 27.

Cheers,

    Juergen
-- 
Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


--On 12 June 2002 17:30 +0200 Tanja Zseby  wrote:

> Hi Jürgen,
>
>  it seems that something went wrong when I did send my comments to the requirements draft :-(
> (maybe because I did sent it from at home... I did not get an error from my mailtool, but it might have been caused by an unlucky combination of my virus scanner and zone alarm... )
>
> I had a lot of comments to the version. So I attached it again to this mail.
>  Maybe we can make further version and also include the comments that were send on the list during the last days ?
> Also if there are further comments from others they would have a last chance to contribute and send comments.
>
> Regards
>  Tanja
>
>
>
>  -------- Original Message --------
> Message-ID: <3CFFCE4E.4010008@fokus.fhg.de>
> Date: Thu, 06 Jun 2002 23:04:14 +0200
> From: Tanja Zseby 
> Organization: FhI FOKUS
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
> X-Accept-Language: en-us
> MIME-Version: 1.0
> To: Juergen Quittek 
> CC: Benoit Claise  ,Tanja Zseby  ,Sebastian Zander  ,Georg Carle  , "K.C. Norseth"  , n.brownlee@auckland.ac.nz , plonka@doit.wisc.edu
> Subject: Re: version 3 of IPFIX requirements
> References: <2900931.1019814195@[192.168.102.164]> <4782386.1023358227@[192.168.102.164]>
> Content-Type: multipart/mixed; boundary="------------090503030107020006050100"
>
>
> Dear Jürgen,
>
>  I read through the requirements draft and inserted my commnents in the document (marked with //TZS: ).
> It is mainly minor rephrasing and some typos. I attached the edited document.
>  One major point is that I still  have problems with the beginning  of section 6.3. (data transfer). I know we already discussed this several times... Please have a look at the extendended comment and proposed changes for this section in the document.
>  Furthermore it would be good if somebody reads the security considerations. Until now I only got some minor comments from Carter and Sebastian ...
>
>  Regards
>  Tanja
>  P.S.: I really like the new section. with the pictures..
>
>  Juergen Quittek wrote:
>
>  Dear all,
>
> Attached please find a new version of the IPFIX requirements
> draft based on our discussion on May 17. Please have a look
> at it and send comments until Saturday.
>
> I plan to submit the new version to the IETF on Monday, if we
> can agree on the draft until then.
>
> I have not yet read carefully the new security considerations.
> Also, the appendix with the application requirements table
> is still missing. I will include it over the weekend.
>
> Tanja or Sebastian, can one of you send me the source file
> of draft version 2?
>
> Cheers,
>
>    Juergen
>
>
>
> __________________________________________________
>
>
> Internet Draft                                                J. Quittek
> Document: draft-ietf-ipfix-reqs-03.txt                   NEC Europe Ltd.
> Expires: November 2002                                          T. Zseby
>                                                                FhI FOKUS
>                                                                B. Claise
>                                                            Cisco Systems
>                                                                S. Zander
>                                                                 G. Carle
>                                                                FhI FOKUS
>                                                             K.C. Norseth
>                                                               Consultant
>
>                                                                 May 2002
>
>               Req
>
>
> uirements for IP Flow Information Export
>
>                      
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of [RFC 2026]. 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 o
> f
>
> Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
>
>    Distribution of this document is unlimited.
>
> Copyright Notice
>
>    Copyright (C) The Internet Society (2001). All Rights Reserved.
>
>
> Abstract
>
>    This memo defines requirements for the export of measured IP flow
>    information out of routers, traffic measurement probes and
>    middleboxes.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 1]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> Table of Contents
>
>    1 Introduction .................................................    2
>    2 Terminology ..................................................    2
>    2.1 IP Traffic Flow ............................................    2
>    2.2 Observation Point .............................
> ..
> ..
> .........    3
>    2.3 Metering Process ...........................................    3
>    2.4 Flow Record ................................................    4
>    2.5 Export Process .............................................    4
>    2.6 Collecting Process .........................................    4
>    3 Applications Requiring IP Flow Information Export ............    4
>    3.1 Usage-based Accounting .....................................    5
>    3.2 Traffic Profiling ..........................................    5
>    3.3 Attack/Intrusion Detection .................................    6
>    3.4 QoS Monitoring .............................................    6
>    4 Distinguishing Flows .........................................    7
>    4.1 Interfaces .................................................    7
>    4.2 IP Header Fields ...........................................    7
>    4.3 Transport Header Fields .......................
> ...
> ...
> .......    8
>    4.4 MPLS Label .................................................    8
>    4.5 DiffServ Code Point ........................................    8
>    4.6 Header Compression and Encryption ..........................    8
>    5 Metering Process .............................................    8
>    5.1 Reliability ................................................    8
>    5.2 Sampling ...................................................    9
>    5.3 Overload Behavior ..........................................    9
>    5.4 Timestamps .................................................   10
>    5.5 Time Synchronization .......................................   10
>    5.6 Timeout ....................................................   10
>    5.7 Ignore Port Copy ...........................................   10
>    6 Data Export ..................................................   11
>    6.1 Information Model .............................
> ....
> ....
> .....   11
>    6.2 Data Model .................................................   12
>    6.3 Data Transfer ..............................................   13
>    6.3.1 Congestion Awareness .....................................   13
>    6.3.2 Reliability ..............................................   13
>    6.3.3 Security .................................................   13
>    6.4 Push and Pull Mode Reporting ...............................   14
>    6.5 Regular Reporting Interval .................................   14
>    6.6 Notification on Specific Events ............................   14
>    6.7 Anonymization ..............................................   14
>    7 Configuration ................................................   14
>    8 General Requirements .........................................   15
>    8.1 Openness ...................................................   15
>    8.2 Scalability Concerning the Number of Export Pro
> cesse
> s ...
> ...   15
>    8.3 Several Collectors .........................................   15
>    9 Special Device Considerations ................................   15
>    10 Security Considerations .....................................   17
>    10.1 Disclosure of Flow Information Data .......................   18
>    10.2 Forgery of Flow Records ...................................   18
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 2]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    10.3 Denial of Service (DoS) Attacks ...........................   18
>    11 Acknowledgments .............................................   19
>    12 References ..................................................   19
>    13 Authors' Addresses ..........................................   20
>    14 Full Copyright Statement ....................................   21
>
>
> 1.  Introduction
>
>
>   Ther
> e are
> several applications that require flow-based IP traffic
>    measurements. Such measurements could be performed by a router while
>    forwarding the traffic, by a middlebox [RFC3234], or by a traffic
>    measurement probe attached to a line or a monitored port. This memo
>    defines requirements for exporting traffic flow information out of
>    these boxes for further processing by applications located on other
>    devices. In section 2 a selection of such applications is presented.
>    The following sections list requirements derived from these
>    applications.
>
>    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 [RFC2119].
>
>
> 2.  Terminology
>
>    The following terminology is used within this document:
>
> 2.1.  IP Traffic Flow
>
>    There are several definitions of the term
> 'flow'
> being u
> sed by the
>    Internet community. Within this document we use the following one:
>
>    A flow is defined as a set of IP packets passing an observation point
>    in the network during a certain time interval. All packets belonging
>    to a particular flow have a set of common properties. Each property
>    is defined as the result of applying a function to the values of:
>
>       1. one or more of packet header fields (e.g. destination IP
>          address)
>
>       2. one or more properties of the packet itself (e.g. packet
>          length)
>
>       3. one or more of fields derived from packet treatment (e.g. AS
>          number)
>
>    A packet is defined to belong to a flow if it completely satisfies
>    all the defined properties of the flow.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 3]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>
>  This de
> finition
>  covers the range from a flow containing all packets
>    observed at a network interface to a flow consisting of just a single
>    packet between two applications with a specific sequence number.
>    Please note that the flow definition does not match a general
>    application-level end-to-end stream. However, an application may
>    derive properties of application-level streams by processing measured
>    flow data.
>
> 2.2.  Observation Point
>
>    The observation point is a location in the network where IP packets
>    can be observed. Examples are a line to which a probe is attached, a
>    shared medium, such as an Ethernet-based LAN, a single port of a
>    router, or a set of interfaces (physical or logical) of a router.
>
>    Please note that a coarse-grined observation point of one flow, for
>    example a line card with several ports, may be the superset of
>    several more fine-grained observation points of some other f
> lows, for
>
>    ex
> ample the individual ports of the line card.
>
> 2.3.  Metering Process
>
>    The metering process generates flow records. Input to the process are
>    IP packet headers observed at an observation point. The metering
>    process consists of a set of functions that includes packet header
>    capturing, timestamping, sampling, classifying, and maintaining flow
>    records.
>
>    The maintenance of flow records may include creating new records,
>    updating existing ones, computing flow statistics, deriving further
>    flow properties, detecting flow expiration, passing flows record to
>    the export process, and deleting flow records.
>
>    The sampling function and the classifying function may be applied
>    more than once with different parameters. Figure 1 shows the sequence
>    in which the functions are applied. Sampling is not illustrated in
>    the figure, it may be applied before any other function.
>
>
>
>
>
>
>
> <
> br>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 4]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>                            packet header capturing
>                                      |
>                                 timestamping
>                                      |
>                                      v
>                               +----->+
>                               |      |
>                               | classifying
>                               |      |
>                               +------+
>                                      |
>                           maintaining flow records
>                                      |
>                                      v
>
>
>                  Figure 1: Functions of the metering process
>
>
> 2.4.  Flow Record
>
>    A flow record contains information ab
> out a spec
> ific flow that wa
> s
>    metered at an observation point. A flow record contains measured
>    properties of the flow (e.g. the total number of bytes of all packets
>    of the flow) and usually also characteristic properties of the flow
>    (e.g. source IP address).
>
> 2.5.  Export Process
>
>    The export process sends flow records to one or more collectors.  The
>    flow records are generated by one or more metering processes.
>
> 2.6.  Collecting Process
>
>    The collecting process receives flow records from one or more export
>    processes. The collecting process might store received flow record or
>    further process them, but these actions are out of the scope of this
>    document.
>
>
> 3.  Applications Requiring IP Flow Information Export
>
>    The following list contains a selection of applications requiring IP
>    flow information export. Because requirements for flow export listed
>    in further sections below a
> re derived
> from these applica
> tions, their
>    selection is crucial. The goal of this requirements document is not
>    to cover all possible applications with all their flow export
>    requirements, but to cover applications which are considered to be of
>    significant importance in today's or future IP networks, and for
>    which requirements can be met with reasonable technical effort.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 5]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    Please note, that the described applications can have a large number
>    of differing implementations. Requirement details or the weighting of
>    requirements could differ for specific implementations. Therefore we
>    derive the requirements from the general functionality of the
>    selected applications. Furthermore, the list of applications should
>    lead to a better understanding of the re
> quirements w
> hich is
>    parti
> cularly important when designing or implementing a traffic flow
>    measuring device.
>
> 3.1.  Usage-based Accounting
>
>    Several new business models for selling IP service and IP-based
>    services are currently under investigation. Beyond flat rate services
>    which do not need accounting, accounting for these models can be
>    based on time or volume. Accounting data can serve as input for
>    billing systems. Accounting can be performed per user or per user
>    group, it can be performed just for basic IP service or individually
>    per high-level service and/or per content type delivered. For
>    advanced/future services, accounting may also be performed per class
>    of service, per application, per time of day, per used (label
>    switched) path, etc.
>
> 3.2.  Traffic Profiling
>
>    Traffic profiling is a process of characterizing IP flows and flow
>    aggregates by using a model that represents
>  key paramete
> rs of the
>    flow
>  such as flow duration, volume, time and burstiness. It is a
>    prerequisite for network planning, network dimensioning, trend
>    analysis, developing business models, and other activities. It
>    heavily depends on the particular traffic profiling objective(s) what
>    statistics and accuracy are required from the measurements. Typical
>    information needed for traffic profiling are the distribution of used
>    services and protocols in the network, the amount of packets of a
>    specific type (e.g. percentage of IPv6 packets) and specific flow
>    profiles.
>
>    Since objectives for traffic profiling can vary, this application
>    requires a high flexibility of the measurement infrastructure,
>    especially regarding the options for measurement configuration and
>    packet classification.
>
>    Traffic Engineering (TE) comprises methods for measurement, modeling,
>    characterization and control of a net
> work. The goal
>  of TE is the
>    o
> ptimization of network resource utilization and traffic performance
>    [RFC2702]. Since control and administrative reaction to measurement
>    results requires access to the involved network nodes, TE mechanisms
>    and the required measurement function usually are performed within
>    one administrative domain. Typical parameters required for TE are
>    link utilization, load between specific network nodes, number, size
>    and entry/exit points of the active flows and routing information.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 6]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 3.3.  Attack/Intrusion Detection
>
>    Capturing of flow information plays an important role for network
>    security, both for detection of security violation, and for
>    subsequent defense. In case of a Denial of Service (DOS) attack, flow
>    monitoring
> can allow detec
> tion of unusual load s
> ituations or
>    suspicious flows. In a second step, flow analysis can be performed in
>    order to gather information about the attacking flows, and for
>    deriving a defense strategy.
>
>    Intrusion detection is a potentially more demanding application which
>    would not only look at specific characteristics of flows, but that
>    may also use a stateful packet flow analysis for detecting specific,
>    suspicious activities, or unusually frequent activities. Such
>    activities may be characterized by specific communication patterns,
>    detectable by characteristic sequences of certain packet types.
>
> 3.4.  QoS Monitoring
>
>    QoS monitoring is the non-intrusive (passive) measurement of quality
>    parameters for single flows or traffic aggregates. In contrast to
>    intrusive (active) measurements, non-intrusive measurements utilize
>    the existing traffic in the network for QoS analysis. Since
>  no test
>    t
> raffic is sent, non-int
> rusive measurements can only be applied in
>    situations where the traffic of interest is already present in the
>    network. One example application is the validation of QoS parameters
>    negotiated in a service level specification (SLS).
>
>    Non-intrusive measurements cannot provide the kind of controllable
>    experiments that can be achieved with active measurements. On the
>    other hand non-intrusive measurements do not suffer from undesired
>    side effects caused by sending test traffic (e.g. additional load,
>    potential differences in treatment of test traffic and real customer
>    traffic)
>
>    QoS monitoring often requires the correlation of data from multiple
>    measurement instances  (e.g. for measuring one-way metrics). This
>    requires proper clock synchronization of the involved measurement
>    instances. For some measurements packet events at the different
>    measurement points
>  must be correlat
> ed. For this, the provis
> ioning of
>    post-processing functions (e.g. the generation of packet IDs) at the
>    measurement instances would be useful. Furthermore, QoS monitoring
>    can lead to a huge amount of measurement result data. Therefore it
>    would highly benefit from mechanisms to reduce the measurement data,
>    like aggregation of results and flow sampling.
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 7]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 4.  Distinguishing Flows
>
>    Packets are mapped to flows by evaluating their properties. Packets
>    with common properties are considered to belong to the same flow. A
>    packet showing at least one difference in the set of properties is
>    considered to belong to a different flow.
>
>    The following subsections list a set of properties which a metering
>    process MU
> ST, SHOULD, or MAY
>  be able to evaluate for
> mapping packets
>    to flows. Please note that requiring the ability to evaluate a
>    certain property does not imply that this property must be evaluated
>    for each packet.
>
>    In other words, meeting the IPFIX requirements means that the
>    metering process in general must be able, via its configuration, to
>    somehow support to distinguish flows via all the MUST fields, even if
>    in certain circumstance/for certain applications, only a subset of
>    the MUST fields is needed and only a subset of the MUST fields is
>    effectively used to distinguish flows.
>
>    Which combination of properties is used for distinguishing a flow in
>    a particular measurement and how these properties are evaluated
>    depends on the configuration of the metering process. The configured
>    choice of evaluated properties strongly depends on the environment
>    and purpose of the measurement and on the infor
> mation required by
> the
>    collector.
>    For specific deployments, only a subset of the REQUIRED properties
>    listed below can be used to distinguish flows, for example in order
>    to aggregate the flow records and reduce the number of flow records
>    exported. On the other hand, some other deployments will require
>    distinguishing flows by some extra parameters, like for example the
>    TTL field of the IP header or the BGP Autonomous Systems.
>
> 4.1.  Interfaces
>
>    The metering process MUST be able to separate flows by the incoming
>    interface or by the outgoing interface or by both of them.
>
> 4.2.  IP Header Fields
>
>    The metering process MUST, SHOULD, or MAY be able to separate flows
>    by the following fields of the IP header as indicated.
>
>       1. source IP address (MUST)
>
>       2. destination IP address (MUST)
>
>       3. protocol type (TCP,UDP,ICMP,...) (MUST)
>
>
>
> Quittek et al.
>      draft-ietf-ipfi
> x-reqs-03.txt              [Pa
> ge 8]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>       4. IP version number (SHOULD)
>          This requirement only applies if the the observation point is
>          located at a device is supporting more than one version of IP.
>
>    For source address and destination address, separating by full match
>    MUST be supported as well as separation by a partial match (for
>    example subnet masking).
>
> 4.3.  Transport Header Fields
>
>    The metering process MUST be able to separate flows by the port
>    numbers of the transport header in case of TCP or UDP being used as
>    transport protocol. Both, source and destination port number MUST be
>    supported for distinguishing flows, individually as well as in
>    combination.
>
> 4.4.  MPLS Label
>
>    If the observation point is located at a device supporting
>    Multiprotocol Label Switchin
> g (MPLS, see [RFC3031
> ]) then the metering
>    proc
> ess MUST be able to separate flows by the MPLS label.
>
> 4.5.  DiffServ Code Point
>
>    If the observation point is located at a device supporting
>    Differentiated Services (DiffServ) then the metering process MUST be
>    able to separate flows by the DiffServ Code Point (DSCP, see
>    [RFC2474]).
>
> 4.6.  Header Compression and Encryption
>
>    If header compression or encryption is used, the metering process
>    might not be able to access all header fields. For packets with
>    compressed or encrypted headers, the requirements stated in this
>    section 4 MUST be met for observation points at end points of header
>    compression or of packet encryption, but they do not need to be met
>    for observation points between the end points.
>
>
> 5.  Metering Process
>
>    The following are requirements for the metering process. All
>    measurements MUST be conducted from the point
>  of view of the
>
> observation point.
>
> 5.1.
> Reliability
>
>    The metering process MUST either be reliable or missing reliability
>    MUST be known and indicated. The metering process is reliable, if
>    each packet passing the observation point is measured according to
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 9]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    the configuration of the metering process. If, e.g. due to some
>    overload, not all passing packets can be included into the metering
>    process, then the metering process MUST be able to detect this
>    failure and to report about it.
>
> 5.2.  Sampling
>
>    Sampling describes the systematic or random selection of a subset of
>    elements (the sample) out of a set of elements (the parent
>    population). Usually the purpose of applying sampling techniques is
>    to estimate a parameter of th
> e parent population by
> using only the
>    elements of
> the subset. Sampling techniques can be applied for
>    instance to select a subset of packets out of all packets of a flow
>    or to select a subset of flows out of all flows on a link.  Sampling
>    methods differ in their sampling strategy (e.g. systematic or random)
>    and in the event that triggers the selection of an element. The
>    selection of one packet can for instance be triggered by its arrival
>    time (time-based sampling), by its position in the flow (count-based
>    sampling) or by the packet content (content-based sampling).
>
>    The metering process MAY support measuring traffic by packet
>    sampling. If sampling is supported the sampling configuration MUST be
>    well defined. The sampling configuration includes the samplng method
>    and all its parameters.
>
>    If the sampling configuration is changed during operation, the new
>    sampling configuration with its pa
> rameters MUST be indicat
> ed to all
>    collectors receivi
> ng the affected flow records.
>
>    In case of any change in the sampling configuration, all flow records
>    metered by the previous sampling configuration MUST be terminated and
>    exported according to the export configuration. The metering process
>    MUST not merge the flow records generated with the new sampling
>    configuration with the flow records generated with the previous
>    sampling configuration.
>
> 5.3.  Overload Behavior
>
>    In case of an overload, for example lack of memory or processing
>    power, the metering process MAY change in order to cope with the lack
>    of resources. Possible reactions include:
>
>       -  Reduce the number of flow accounts. This can be achieved by
>          more coarse grained flow measurement or by a restriction of the
>          flow accounts to a subset of the set of original ones.
>
>       -  Switch to sampling packets before
> they are processed by the
>
>          metering process or -
> if sampling is already performed - reduce
>          the sampling rate.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 10]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>       -  Stop metering.
>
>       -  Reducing the resource usage of competing processes on the same
>          device.  Example: reducing the packet forwarding throughput
>
>    Overload behavior is not restricted to the four options listed above.
>    But in case the overload behavior has an impact on the metering
>    process or the export process, the overload behavior MUST be clearly
>    defined and the collector MUST be able to distinguish the flow
>    records exported before and after the metering process behavior
>    change: In case of any change of the meter's behavior, all flow
>    records metered by the previous behavior MUST be terminated
> and
>    exported accordi
> ng to the export configuration. The
> metering process
>    MUST not merge the flow records generated with the new behavior with
>    the flow records generated with the previous behavior.
>
> 5.4.  Timestamps
>
>    The metering process MUST be able to generate timestamps for the
>    first and the last observed packet of a flow. The timestamp
>    accuricaty MUST be at least the one of the sysUpTime [RFC1213], which
>    is one centisecond.
>
> 5.5.  Time Synchronization
>
>    Metering processes and collectors SHOULD be time-synchronized with
>    each other. Using NTP or GPS are possible ways of achieving this.
>    However selecting a method for time synchronization is not in the
>    scope of this document.
>
> 5.6.  Timeout
>
>    The metering process MUST be able to detect flow timeout. A flow is
>    considered to be timed out if no packet of this flow has been
>    observed for a given timeout interval. The meter
> ing process MAY
>    suppo
> rt means for detecting the end of a f
> low before a time out
>    occurs, for example by detecting the FIN or RST bits in a TCP
>    connection. The procedure for detecting a flow timeout MUST be
>    clearly defined.
>
> 5.7.  Ignore Port Copy
>
>    The metering process MAY be able to ignore packets which are
>    generated by a port copy function acting at the device where the
>    observation point of a flow is located.
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 11]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 6.  Data Export
>
>    The following are requirements for exporting measured flow data out
>    of the exporter. Beside requirements on the data transfer, we
>    separate requirements concerning the information model from
>    requirements concerning the data model. Furthermore, we list
>    requirements on reporting t
> imes and events and on anony
> mization of
>    records.
>
> 6.1.
>   Information Model
>
>    The information model for the flow information export is the list of
>    attributes of a flow to be contained in the report (including the
>    semantics of the attributes).
>
>    This section lists attributes an export process MUST or MAY be able
>    to report. This does not imply that each exported flow records MUST
>    contain all REQUIRED attributes, but that it MUST be possible to
>    configure the device in a way that all of the REQUIRED attributes are
>    transmitted from the export process to the colleting process for each
>    measured flow.
>
>    In other words, meeting the IPFIX requirements means that the export
>    process in general must be able, via its configuration, to somehow
>    support to report all the MUST fields, even if in certain
>    circumstance or for certain applications, only a subset of the MUST
>    fields is needed and on
> ly a subset of the MUST field
> s is effectively
>    reported.
>
>    Beyond that, the device might offer to report also further attributes
>    not mentioned here. A particular flow record may contain some of the
>    "REQUIRED" attributes as well as some additional ones, for example
>    covering future technologies.
>
>    This document does not impose that the following attributes would
>    reported for every single flow records, especially for repetitif
>    attributes. For example, if the observation point is the incoming
>    packet stream at IP interface with the ifIndex value 3, then this
>    observstion point does not have to be exported as part of every
>    single flow record. Exporting it just once might give sufficient
>    information to the collecting process.
>
>    The measuring device MUST be able to report the following attributes
>    for each measured flow:
>
>       1. IP version number
>          This requirement only applies i
> f the observation point is
>
>          located at a device supporting
>  more than one version of IP.
>       2. source IP address
>       3. destination IP address
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 12]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>       4. IP protocol type (TCP,UDP,ICMP,...)
>       5. source TCP/UDP port number
>       6. destination TCP/UDP port number
>       7. input interface (ifIndex)
>          This requirement does not apply if the observation point is
>          located at a probe device.
>       8. output interface (ifIndex)
>          This requirement does not apply if the observation point is
>          located at a probe device. This requirement does not apply in
>          case of multicast flow records.
>       9. packet counter
>          If a packet is fragmented, each fragment is counted as an
>          individual packet.
>      10. by
> te counter
>          Which by
> tes of a packet are counted MUST be defi
> ned exactly.
>      11. in case of IPv4: Type of Service
>      10. in case of IPv6: Flow Label
>      11. if BGP is supported at the observation point: BGP AS#
>      12. if MPLS is supported at the observation point: MPLS label
>      13. if DiffServ is supported at the observation point: DSCP
>      14. timestamp of the first packet of the flow
>      15. timestamp of the last packet of the flow
>      16. if sampling is used: sampling configuration
>      17. unique identifier of the observation point
>      18. unique identifier of the export process
>
>    The metering process MAY be able to report the following attributes
>    for each measured flow:
>
>      20. Time To Live
>      21. IP header flags
>      22. TCP header flags
>      23. dropped packet counter at the observation point
>          If a packet is fragmented, each fragment MUST be counted as an
>          indi
> vidual packet.
>      24. fragm
> ented packet counter
>          counter
> of all packets for which the fragmented bit is set in
>          the IP header
>      25. multicast replication factor
>          the number of outgoing packets originating from a single
>          incoming multicast packet
>
> 6.2.  Data Model
>
>    The data model describes how information is represented in flow
>    records.
>
>    The data model MUST be extensible for future attributes to be added.
>    Even if a set of attributes is fixed in the flow record, the data
>    model MUST provide a way of extending the record by configuration or
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 13]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    for certain implementations.
>
>    The data model used for exporting flow information MAY be flexible
>    concerning the flow attributes contained in flow records.
>  A flexible
>    record format w
> ould offer the possibility of defining rec
> ords in a
>    flexible (customizable) way regarding the number and type of
>    contained attributes.
>
>    The Data Model SHOULD be independent of the underlying transport
>    protocol, i.e. the data transfer.
>
> 6.3.  Data Transfer
>
>    Requirements for the data transfer include reliability and security
>    requirements. These requirements do not apply to the measuring device
>    alone, but also to the transport network. Consequently, the export
>    process does not necessarily have to guarantee that all requirements
>    are met. Particularly if the security requirements are already
>    guaranteed by the network used for data transfer, then these
>    requirements do not have to be considered anymore by the export
>    process. Therefore, these requirements are OPTIONAL for the export
>    process, although they may be REQUIRED for the data transfer as
>    specified
>  in the appendix.
>
> 6.3.1.  C
> ongestion Awareness
>
>    For the data
> transfer, a congestion aware protocol MUST be supported.
>
> 6.3.2.  Reliability
>
>    Absence of reliability, for example caused by export packet loss or
>    export packet reordering, of the data transfer MUST be indicated.
>
>    Please note that if an unreliable transport protocol is used,
>    reliability can be provided by higher layers. In such a case only
>    lack of overall reliability MUST be indicated. For example reordering
>    could be dealt with by adding a sequence number to each packet.
>
> 6.3.3.  Security
>
>    Confidentiality of flow specific data transferred from an export
>    process to a collecting process SHOULD be ensured.
>
>    Integrity of flow specific data transferred from an export process to
>    a collecting process MUST be ensured.
>
>    Authenticity of flow specific data transferred from an export process
>    to a collecting proce
> ss MUST be ensured.
>
>    See m
> ore about Security in the "Security Consider
> ations" section 10,
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 14]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    from which the 3 requirements above are deducted.
>
> 6.4.  Push and Pull Mode Reporting
>
>    In general, there are two ways of deciding on reporting times: push
>    mode and pull mode. In push mode, the export process decides without
>    an external trigger on when to send a report on measured flows. In
>    pull mode, sending a report is triggered by an explicit request from
>    a collector. The measuring device MUST support push mode reporting,
>    it MAY support pull mode reporting.
>
> 6.5.  Regular Reporting Interval
>
>    The export process SHOULD be capable of reporting measured traffic
>    data regularly according to a given interval length.
>
> 6.6.  Notification
>  on Specific Events
>
>    The ex
> port process MAY be capable of sending notifi
> cations to a
>    collecting process, if a specific event occurs. Such an event can be
>    the arrival of the first packet of a new flow, or the termination of
>    a flow after flow timeout.
>
> 6.7.  Anonymization
>
>    The export process MAY be capable of anonymizing source and
>    destination IP addresses in flow data before exporting them. It MAY
>    support anonymization of port numbers and other fields. Please note
>    that anonymization is not originally an application requirement, but
>    derived from general requirements for treatment of traffic within a
>    network.
>
>
> 7.  Configuration
>
>    The metering process MUST provide a way of configuring traffic
>    measurement. The following parameters of the metering process SHOULD
>    be configurable:
>
>       1. specification of the observation point, e.g. an interface or
>          a list of int
> erfaces to be monitored.
>       2.
> specifications of flows to be metered
>
>  3. flow timeouts
>
>    The following parameters MAY be configurable:
>
>       4. sampling method and parameters, if feature is supported
>       5. overload behavior
>
>    The export process MUST provide a way of configuring the data export.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 15]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    The following parameters of the export process SHOULD be
>    configurable:
>
>       1. reporting data format
>          Specifying the reporting data format SHOULD include a selection
>          of attributes to be reported for each flow.
>       2. the collecting process (or list of collecting processes) to
>          which flows are reported 2. notifications to be sent to the
>          collecting process(es) 3. flow anonymization, if the export
>
>      process supports it
>
>    If
> configuration is done remotely, security of the
>  configuration
>    SHOULD be supported including confidentiality, integrity and
>    authenticity. The means used for remote configuration are out of the
>    scope of this document.
>
>
> 8.  General Requirements
>
> 8.1.  Openness
>
>    IPFIX specifications SHOULD be open to future technologies. This
>    includes extensibility of configuration of measurement and reporting.
>
>    Openness is also required concerning the extensibility of the data
>    model, as stated in section 6.2.
>
> 8.2.  Scalability Concerning the Number of Export Processes
>
>    Data collection from hundreds of different export processes MUST be
>    supported. The collecting process MUST be able to distinguish several
>    hundred export processes by their identifiers.
>
> 8.3.  Several Collectors
>
>    The export process MAY be able to export flow information to more
>    tha
> n one collecting process.
>
>
> 9.
>   Special Device Considerations
>
>    This d
> ocument is intended to avoid constraining the architecture of
>    probes, routers, and other devices hosting observation points,
>    metering processes, export processes, or collecting processes.  It
>    can be expected that typically observation point, metering process,
>    and export process are co-located at a single device.  However, the
>    requirements defined in this document do not exclude devices that
>    derive from this configureation. Figure 2 shows some examples.
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 16]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>             +---+     +-----+     +---------+       +---------+
>             | E-+->   |  E--+->   |    E----+->   <-+--E   E--+->
>             | | |     |  |  |     |   /    |       |  |   |  |
>
>      | M |     |  M  |     |  M   M  |
>      |  M   M  |
>             | | |     | /| |
>     | /| /| |       | /| /| |
>             | O |     | OOO |     | OOO OOO |       | OOO OOO |
>             +---+     +-----+     +---------+       +---------+
>             Probe      Basic        Complex          Multiple
>                        Router       Router           Exporters
>
>
>           +---+     +---+     +---+
>           | E-+->   | E-+->   | E-+------------->---+
>           | | |     | | |     | | | +---+         +-+-----+
>           +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
>             |       | | |     | | | | | | +---+   +-+-----+
>           +-+-+     +-+-+     | O | | M | | E-+->---+
>           | | |       |       +---+ | | | | | |
>           | M |     +-+-+           | O | | M |
>           | | |     | | |           +---+ | | |           +-----+
>           | O |     | O |                 | O |        ->
> -+-C-E-+->
>           +---+     +---
> +                 +---+           +-----+
>
>
>         Protocol   Remote             Concentrator        Proxy
>          Converter  Observation
>
>                       Figure X: IPFIX-related Devices
>
>    All examples are composed of one or more of the following elements:
>    observation point (O), full or partial metering process (M), export
>    process (E), collecting process (C).
>
>    A very simple device is a probe. It contains on a single observation
>    point, a single metering process, and a single export process.  For
>    this device the observation domain contains a single observation
>    point only.
>
>    A basic router extends this structure by multiple observation point.
>    Here an exported flow record may still have an observation domain
>    containing a single observation point. But also Observation domains
>    containing all observation points of the routers are possible.
>
>    A more complex router may host more th
> an one metering process, for
>    example one per
> line card. Please note that an observation domain is
>    restricted to the observation points connected to a single metering
>    process. An observation domain containing all observation points of
>    this router is not possible with this structure.
>
>    Alternatively, a complex router may use different export processes
>    for flow records generated by different metering processes.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 17]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    A protocol converter makes use of a metering process that can be
>    accessed only by another protocol than the one defined for IPFIX, for
>    example the SNMP and the Meter MIB module [RFC2720]. Then the
>    exporter receives flow record from a remote metering process and
>    exports these records using the
>  IPFIX protocol.
>
>    Another choice i
> s remote packet observation. Packet header captured<
> br>   at an observation point may be exported as raw data to a device
>    hosting metering process and exproting process.
>
>    An intermediate structure between protocol converter and remote
>    observation (not shown in the Figure) would be a split metering
>    process, for example performing timestaping and sampling at the
>    device hosting the observation point and performing packet
>    classification at another device hosting the export process.
>
>    A concentrator receives flow records via the IPFIX protocol, merges
>    them into higher aggregated flows and exports the resulting flows
>    again using the IPFIX protocol. Please note that for the final flow
>    records the observation domain potentially contains observation
>    points at all first level devices. The metering process of the final
>    flow records is composed by the (partial)
> metering processes at the
>    first level
> devices and the partial metering process at the
>    conce
> ntrator.
>
>    Finally, a very simple IPFIX-related device is a proxy. It just
>    receives flow records using the IPFIX protocol and sends them further
>    using the same protocol. A proxy might be useful for traversing
>    firewalls or other gateways.
>
>
> 10.  Security Considerations
>
>    The future IPFIX protocol must be capable to transport data over the
>    public Internet. Therefore it cannot be excluded that an attacker
>    captures or modifies exchanged packets or inserts additional packets.
>
>    This section describes security requirements for IPFIX.  It therefore
>    also states the required security features for a future IPFIX
>    protocol. Like other requirements, the security requirements differ
>    for the considered applications. The incentive to modify collected
>    data for accounting or intrusion detection for instan
> ce is usually
>    higher than the incentive
>  to change data collected for traffic
>    profiling. There
> fore the required security features in this document
>    are listed per application in the appendix.  The suggestion of
>    concrete solutions for achieving the required security properties
>    will be part of the IPFIX architecture and protocol description and
>    is out of scope of this document. Furthermore, methods for remote
>    configuration of the IPFIX processes are out of scope for IPFIX.
>    Therefore, threads that are caused by data exchange for remote
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 18]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    configuration are not considered here.
>
>    The following potential security hazards for an IPFIX protocol can be
>    identified: disclosure of IP flow information, forgery of flow
>    records, and Denial of Service
>  (DoS) attacks.
>
> 10.1.  Disclosure of Fl
> ow Information Data
>
>    The content of data exchanged b
> y the IPFIX protocol (e.g. IPFIX flow
>    records) should be kept confidential between the involved parties
>    (export process and colleting process). Observation of IPFIX flow
>    records gives an attacker information about the active flows in the
>    network, communication endpoints and traffic patterns. This
>    information cannot only be used to spy out user behavior but also to
>    plan and conceal future attacks. Therefore the requirements document
>    recommends to ensure the confidentiality of the transferred data.
>    This can be achieved for instance by encryption.
>
> 10.2.  Forgery of Flow Records
>
>    Because of the potential uses of IPFIX flow records in accounting and
>    security applications, there are strong incentives to forge exported
>    IPFIX  flow records (e.g. to save money or prevent the detection of
>    an attack
> ). This can be done either by altering flow rec
> ords on the
>    path or by injecting forged flow records tha
> t pretend to be
>    originated by the original export process. In order to make the IPFIX
>    protocol resistant against such attacks this document requires to
>    ensure authenticity and integrity for the IPFIX data transfer.
>
>    Special caution is required if security applications rely on IPFIX
>    data. With forged flow records it is possible to trick on security
>    applications. It is for instance possible to pretend that a DoS
>    attack happens without even launching a real attack.
>
>    IPFIX flow records are used in accounting and security applications.
>    This leads to strong incentives for attackers to forge exported IPFIX
>    flow records (for example to save money or to prevent the detection
>    of an attack). In order to make the IPFIX protocol resistant against
>    such attacks, source authentication and integrity assuran
> ce must be
>    provided for IPFIX data. These
> requirements are covered in the
>    security requirements sec
> tion of this document.
>
> 10.3.  Denial of Service (DoS) Attacks
>
>    DoS attacks on routers or other middleboxes that have the IPFIX
>    protocol implemented would also affect the IPFIX protocol and impair
>    the sending of IPFIX records. Nevertheless, since such hazards are
>    not induced specifically by the IPFIX protocol the prevention of such
>    attacks is out of scope of this document.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 19]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    Nevertheless IPFIX itself also causes potential hazards for DoS
>    attacks.  All processes that expect the reception of traffic can be
>    target of a DoS attack. With the IPFIX export process this is only
>    the case if it supports the pull mode (which can be an optiona
> l
>    feature of the future IPFIX protocol acco
> rding to this document). The
>    collecting process always exp
> ects data and therefore can be flooded
>    by forged flow records.
>
>
> 11.  Acknowledgments
>
>    We like to thank all the people contributing to the requirements
>    discussion on the mailing list for a lot of valuable comments.
>
>
> 12.  References
>
> [RFC2026]   S. Bradner, "The Internet Standards Process -- Revision 3",
>             RFC 2026, October 1996.
>
> [RFC3234]   B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234,
>             February 2002.
>
> [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
>             Requirement Levels", RFC 2119, March 1997.
>
> [RFC2702]   D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
>             "Requirements for Traffic Engineering Over MPLS", RFC 2702,
>             September 1999.
>
> [RFC3031]   E. Rosen, A. Viswanathan, R. Callon, "Multip
> rotocol Label
>             Switching Architectur
> e", RFC 3031, January 2001.
>
> [RFC2474]   K. Nichols, S. Bla
> ke, F. Baker, D. Black, "Definition of the
>             Differentiated Services Field (DS Field) in the IPv4 and
>             IPv6 Headers", RFC 2474, December 1998.
>
> [RFC1213]   K. McCloghrie, M. Rose. "Management Information Base for
>             Network Management of TCP/IP-based internets: MIB-II", RFC
>             1213, March 1991.
>
>
>
>
>
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 20]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 13.  Authors' Addresses
>
>      Juergen Quittek
>      NEC Europe Ltd., Network Laboratories
>      Adenauerplatz 6
>      69115 Heidelberg
>      Germany
>
>      Phone: +49 6221 90511-15
>      EMail: quittek@ccrle.nec.
> de
>
>
>      Tanja Zseby
>      Fraunhof
> er Institute for Open Communication Systems (FOKUS)
>      Kaiser
> in-Augusta-Allee 31
>      10589 Berlin
>      Germany
>
>      Phone: +49 30 3463 7153
>      Email: zseby@fokus.fhg.de
>
>
>      Benoit Claise
>      Cisco Systems
>      De Kleetlaan 6a b1
>      1831 Diegem
>      Belgium
>
>      Phone: +32 2 704 5622
>      Email: bclaise@cisco.com
>
>
>      Sebastian Zander
>      Fraunhofer Institute for Open Communication Systems (FOKUS)
>      Kaiserin-Augusta-Allee 31
>      10589 Berlin
>      Germany
>
>      Phone: +49 30 3463 7287
>      Email: zander@fokus.fhg.de
>
>
>      Georg Carle
>      Fraunhofer Institute for Open Communication Systems (FOKUS)
>
>     Kaiserin-Augusta-Allee 31
>      10589 Berlin     Germany
>
>      Phone: +49 30 3463 7149
>      Email: <
> a class="moz-txt-link-abbreviated" href="mailto:carle@fokus.fhg.de">carle@fokus.fhg.de
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 21]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>      K.C. Norseth
>      Consultant
>      934 S. Palos Verdes Dr.
>      Kaysville, Utah 84037 USA
>
>      Phone: 801.546.3316
>      Email: kcn@norseth.com
>
>
> 14.  Full Copyright Statement
>
>    Copyright (C) The Internet Society (2001). All Rights Reserved.
>
>    This document and translations of it may be copied and furnished to
>    others, and derivat
> ive 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 languages other than
>    English.
>
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
>
>    This document and the information contained herein i
> s provided on an
>    "AS IS" basis and THE INTERNET SOC
> IETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RI
> GHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 22]
>
>
>
>
>
>
>
> --
> Dipl.-Ing. Tanja Zseby			    	      	
> FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
> 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)
> --------------------------------------------------------------------------------------
>
>
>
>
> --
> Dipl.-Ing. Tanja Zseby			    	      	
> FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
> 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)
> --------------------------------------------------------------------------------------
>
>
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/