Subject: [ipfix] RE: MIDCOM first draft

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 13 Feb 2002 13:56:28 -0800

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, February 13, 2002 1:10 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: [email-masked];
>[email-masked]; K.C. Norseth; ipfixx
>Subject: Re: MIDCOM first draft
>
>
>Reinaldo Penno wrote:
>> 
>> Hello Paul,
>> 
>> comments inline.
>> 
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]]
>> >Sent: Wednesday, February 13, 2002 5:34 AM
>> >To: Penno, Reinaldo [SC9:T327:EXCH]
>> >Cc: [email-masked];
>> >[email-masked]; K.C. Norseth; ipfixx
>> >Subject: Re: MIDCOM first draft
>> >
>> >
>> >>
>> >> Hello Paul,
>> >>
>> >> I'll try to be more structured now.
>> >>
>> >> the way it is reported is one thing, but a NAT is by all purposes
>> (by
>> >> definition) composed of two flows. You can export them in one
>> record
>> >> or two records, but that doesn't change how it should be faced.
>> >>
>> >> would you agree with this?
>> >
>> >       I would say no. Since a flow is defined by its key
>> >       you cannot take that out of the picture. If the
>> >       key is actual-src and actual-destination then
>> >       there is only 1 flow and only 1 record.
>> 
>> There is no actual src and actual dest. The flow can be 
>NATed twice in
>> the same box. It's just how from an aimplementation standpoint you
>> look at it (see below)
>> 
>
>	Doesn't matter how many times it gets NATed. The end result
>	is some IP gets stuffed in the paceket to go out and that is the
>	actual address in the NAT case. The addresses in the middle 
>	are what I call the virtual addresses (for lack of a 
>better term).
>	There can be a list of virtual addresses if more than one
>	translation takes place.

well, you do not really know when the translation ended. The packet might
com in a interface and get translated, and then as it goes out another is
translated again. If the intefaces are independent you would get two records
saying that this is the "actual" destination.

Remeber that the collector is the "middlebox controller" in this case. It
can be 10 hops away for all we care. It doesn't know where is inside,
outside, virtual or actual from the exporter(s) point of view. it will
believe what is told and might receive several flow saying that for a given
source, this is the "actual" destination, which IMHO is misleading.

Saying what operation was performed on the packet (NAT, Twice NAT, etc) and
what fields changed (without getting into outside, inside, virtual, actual,
etc) is less confusing in my opinion. But if I couldn't convince you up to 
know that's okay (;-)

>
>> >
>> >       If the key is packet-src, packet-destination then
>> >       it would be 2 flows as you suggest.
>> 
>> Paul, the "key" is something that we invented. It's an implementation
>> thing in the same sense that you might prefer to export NAT flows in
>> one record. But it doesn't change the basic definition. A flow is
>> defined by a 5-tuple. It's basic definition independent of IPfix.
>
>	I don't think there is such a standard definition. Unless
>	you mean a NAT flow and the NAT RFC defines such a thing
>	(I'm not sure if it does or doesn't). ICMP for example does 
>	not have src and dest port but I'm sure it can be NATed just
>	the same.

It's still a 5-tuple but in the case of ICMP some of the tuples are missing.
RFC 2914 has some discussion on this subject

"This raises the issue of the appropriate granularity of a "flow",
   where we define a `flow' as the level of granularity appropriate for
   the application of both fairness and congestion control.  From RFC
   2309:  "There are a few `natural' answers: 1) a TCP or UDP connection
   (source address/port, destination address/port); 2) a
   source/destination host pair; 3) a given source host or a given
   destination host."

IMO NAT is consisted of two flows. Actually after you NAT a packet it can be
dropped by a firewall rule in the same box. A flow that otherwise wouldn't
be dropped if the packet hasn't been modified. You can also take a step
further asying that in the ingress direction stateful firewalls follow the
conversation after the NAT, no before it. They do not consider the flow
before the NAT the same thing, ie, you cannot send a unsolicited packet with
the original addresses (before the NAT) in it and expect a firewall to
accept them.

Did I convince you? (;-)

regards,

Reinaldo

>> regards,
>> Reinaldo

---

From: [email-masked]
Date: Thu, 14 Feb 2002 09:14:25 -0500

Reinaldo Penno wrote:
> well, you do not really know when the translation ended. The packet
> might com in a interface and get translated, and then as it goes out
> another is translated again. If the intefaces are independent you
> would get two records saying that this is the "actual" destination.

	This is no different than having the packet go through
	2 totally separate NAT boxes both of which are reporting
	on the packets seen.

> 
> Remeber that the collector is the "middlebox controller" in this case.

	This might be part of the confusion. I speaking from
	and exporter point of view. We are not defining Collector
	behavior in IPFIX.

> It can be 10 hops away for all we care. It doesn't know where is
> inside, outside, virtual or actual from the exporter(s) point of view.

	Here you switch back to exporter. Not sure if you
	mean Collector.

	But in any case, if the exporter is also doing the NAT,
	it must know what IP it put in the packet (even if it
	is later translated again) and it must know what IP
	it took out of the packet. Hence actual and virtual
	or actual and original if you like that word better.

> it will believe what is told and might receive several flow saying
> that for a given source, this is the "actual" destination, which IMHO
> is misleading.

	Since any report is from the perspective of the exporter
	it is correct. What happens later is not we are trying
	to report.

	Also, whomever is setting up these NAT sitiations
	understands their address space. By reporting it
	as I suggest, I believe more accurately represents
	the data and allows for more useful data mining later.

> 
> Saying what operation was performed on the packet (NAT, Twice NAT,
> etc) and what fields changed (without getting into outside, inside,
> virtual, actual, etc) is less confusing in my opinion. But if I
> couldn't convince you up to
> 
> know that's okay (;-)

	I already agreed it iwas less confusuing but I also
	believe less useful.

> It's still a 5-tuple but in the case of ICMP some of the tuples are
> missing. RFC 2914 has some discussion on this subject
> 

	I know there has been talk of a standard flow definition
	but I don't see how that can happen. IPFIX will be used
	to report flows with all types of keys that may or may
	not overlap with the 5-tuple field set. Even if we agree
	to the 5-tuple key set, what use will it be. 

> 
> IMO NAT is consisted of two flows. Actually after you NAT a packet it
> can be dropped by a firewall rule in the same box. A flow that
> otherwise wouldn't be dropped if the packet hasn't been modified. You
> can also take a step further asying that in the ingress direction
> stateful firewalls follow the conversation after the NAT, no before
> it. They do not consider the flow before the NAT the same thing, ie,
> you cannot send a unsolicited packet with the original addresses
> (before the NAT) in it and expect a firewall to accept them.

	We seem to be arguing over the defintion of a flow. From
	the IPFIX docs so far, a more general definiton seems
	to be developing than the 5-tuple mentioned earlier...

From reqs:
==========

      A flow is a set of 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 derived from the
      data contained in the packet and from the packet treatment at the
      observation point.

From Arch (which matches Cisco doc):
===================================

"A flow is a set of 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 derived from the data contained in
the packet and from the packet treatment at the observation point."

In this draft we define the flow more specifically.  A flow is defined
as a set of 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:

a. one or more of packet header fields (eg. destination IP address)
b. one or more properties of the packet itself (eg. packet length)
c. one or more of fields derived from packet treatment (eg. AS number)

A packet is defined to belong to a flow if it matches all the defined
properties of the flow. Flows can be defined in multiple ways. Some

> Did I convince you? (;-)

	No yet. Are you going to the next meeting. Maybe
	Juergen , you amd I can sit down and hash this thing
	out over a couple beers!

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