Subject: [ipfix] Re: NAT (aka agenda)

From: [email-masked]
Date: Fri, 01 Feb 2002 11:53:07 -0500

"Wang, Cliff" wrote:
> 
> Comments in line.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 01, 2002 11:31 AM
> To: Wang, Cliff
> Subject: Re: Agenda
> 
> "Wang, Cliff" wrote:
> >
> > Agree. But finding the NAT info should be out of the scope of this WG.
> 
>         Not sure what you mean by "finding the NAT info". How the
>         device retrieves any of the info is beyond the scope
>         of the WG. We just provide a way to report it.
> 
> [cliff] we are saying the same thing.
> 
> >
> > On the other hand, the collector may have to deal the nasty NAT issue
> > when the flow reported may contain address of a different address
> > space. How to interprete that address seems to me something we need to
> > look at.
> >
> > The other issue is whether we will allow some kind of NAT ALG, which
> > translate the address in the report. Thoughts?
> 
>         Collectors may do a lot of stuff based on information
>         which they got from non-IPFIX sources. But we, I don't
>         think, are investigating that.
> 
> [cliff]
> What I am think are the following cases:
> 1) NAT does the report packet header address translation. The payload is not
> touched.
>    Then the question is the report may carry private address that collector
> may or may not recognize.
> 
> 2) NAT does the report packet header address translation. If ipfix ALG is
> built, it may also translate the IP address in the report. Then collector
> doesn't care the private address space at all. But doing NAT ALG is
> difficult and may not be applicable all the time.

	Still not quite sure I follow. So let me go through
	step by step and then you can point out where I've 
	gone off track.

	1) If the reporting device does not know any NAT info
	   is can only report the IP's it sees in the packet.
	   No affect on IPFIX in this case.

	   If the collector has no NAT knowledge, the reports
	   only show addresses seen. No affect on IPFIX.

	   If the collector does have NAT knowledge it MAY
	   be able to report on public or private addresses
	   based on info it has. What ever the collector does
	   and how it does it in this case is outside IPFIX.

	2) the reporting device does have NAT knowledge. 
	   Lets say the reporting device is the one performing
	   the translation. In this case IPFIX should provide
	   a way to report the private and public addresses for
	   the flow. This does affect IPFIX.

	   If the collector has no NAT knowledge, it can make
	   use of the data reported by the device, but no new
	   requirements on IPFIX.

	   If the collector has NAT knowledge, it can either use
	   the info provided by the reporting device or it's own
	   info. But no new requirements on IPFIX.

	So as I see it, the only time the IPFIX WG takes NAT
	into consideration is when the reporting device wants
	to transport NAT related info for a particular flow. 

	Paul 

> 
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, February 01, 2002 10:52 AM
> > To: Wang, Cliff
> > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC;
> > [email-masked]; K.C. Norseth; ipfix arch; ipfix data; ipfix
> > chairs
> > Subject: Re: Agenda
> >
> > We should provide a way to report the NAT info if the
> > device knows it. It is not a required field since not
> > all devices will have it. IMHO it should be reported
> > as attributes of one flow, not multiple flows.
> >
> > Paul
> >
> > "Wang, Cliff" wrote:
> > >
> > > The problem is that the NAT box is in the path and the probe may not
> > > have any knowledge of the outside IP address it may get assigned.
> > > The collector may know the mapping if it knows the inside private
> > > address of the probe.
> > >
> > > -----Original Message-----
> > > From: Benoit Claise [mailto:[email-masked]]
> > > Sent: Thursday, January 31, 2002 1:46 PM
> > > To: Reinaldo Penno
> > > Cc: Norseth, KC; [email-masked]; K.C. Norseth; ipfix arch;
> > > ipfix data; ipfix chairs
> > > Subject: Re: Agenda
> > >
> > > Hi all
> > >
> > > >
> > > >
> > > > other comments (not necessarily to be discussed on the call)
> > > > Concerning some form of capabilities negotiation I have It is also
> > > > useful for the case of overlapping flows (discussed on the list)
> > > >
> > > > Middlebox:
> > > > What about when the device is also a middlebox ? (sorry if this
> > > > was already hashed out on the list) If using NAT/NAPT should the
> > > > device export the flow on the private side, public side or both?
> > > > Should the behavior be agreed on the capabilities negotiation?
> > >
> > > It's in my mind the same behaviour as for unidirectional and
> > > bidirectional flows.
> > >     In case the exporter has got the knowledge of the bi-directional
> > >     flows and in case the bi-directional information make sense, the
> > >     exporter MAY choose to export in the same Template/Flow Record,
> > >     along with bidirectional accounting information.
> > > So
> > >     In case the exporter is doing NAT, the exporter MAY choose to
> > > export
> > >
> > >     in the same Template/Flow Record, both inside and outside ip
> > > addresses
> > >
> > > This just implies that the information model MUST have inside and
> > > outside IP addresses defined.
> > >
> > > Regards, Benoit
> > >
> > > >
> > > >
> > > > I think the most useful behavior would be export the flows on the
> > > > private and public side within the same record (or if in different
> > > > records provide some key to bind them together), so you know the
> > > > complete flow end-to-end. But in this case although we have two
> > > > seprate flows, it is still the same packet. Same reasoning can be
> > > > applied for proxy, proxy firewalls, etc.
> > > >
> > > > It would be impossible for a external probe to provde NAT
> > > > information. All it sees is the snapshot of what is passing by.
> > > > This could be worked out as a MAY.  Whether it is resolved or not,
> > > > we should clarify the stance on NAT in the archecture.
> > > >
> > > >
> > > > [Penno, Reinaldo [SC9:T327:EXCH]]
> > > >
> > > > I wouldn't say it's impossible. It depends if the platform keeps
> > > > "memory" (full stateful NATs, proxies) or not . And yes, I agree
> > > > that whatever the outcome we should clarify NAT/NAPT behavior on
> > > > the doc.
> > > >
> > > > regards,
> > > >
> > > > Reinaldo
> > > >
> > > >
> > > >

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

---

From: "Wang, Cliff" <[email-masked]>
Date: Sat, 2 Feb 2002 21:01:22 -0000

I agree the crux of the issue is the interpretation of the reported data by
the collector.
But on the hand, if this is a valid scenario, IPFIX needs to either specify
this is out of scope or try to find possible solutions. Otherwise the data
reported may be useless.  Let's listen to the outcome of the MIDBOX
architecture team. 

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: Friday, February 01, 2002 6:43 PM
To: Wang, Cliff
Cc: [email-masked]'; ipfixx
Subject: Re: [ipfix] RE: NAT (aka agenda)

Hi Cliff,

"Wang, Cliff" wrote:

> Paul,
>
> I think we probably out of sync in the scenario we picture. I think we 
> have potentially two scenarios:
> 1) NAT is performing on the flow being reported. Yes I am totally 
> agree with your analysis.
> 2) NAT is between the probe and the collector. Actually I am talking 
> about this case, where NAT performs on the reporting traffic.

I think this case is out of the scope of the WG.
This is actually a task for a mediation device which will analyze the data
(in this case the IP addresses and ports) of the flow records received by
the collector. In your case, the mediation device should contain an NAT
translator. The charter doesn't speak about analyzing the flow records
information.

My 0.02 EURO

Regards, Benoit

>
>
> Again, I agree with your standing that if either probe or collector 
> knows the NAT mapping, use it. Otherwise, it is out of the scope of 
> this WG to find the NAT info.
>
> cliff
>
> Sent: Friday, February 01, 2002 11:53 AM
> To: Wang, Cliff; ipfixx
> Subject: Re: NAT (aka agenda)
>
> "Wang, Cliff" wrote:
> >
> > Comments in line.
> >
> > > On the other hand, the collector may have to deal the nasty NAT 
> > > issue when the flow reported may contain address of a different 
> > > address space. How to interprete that address seems to me 
> > > something we need to look at.
> > >
> > > The other issue is whether we will allow some kind of NAT ALG, 
> > > which translate the address in the report. Thoughts?
> >
> > 1) NAT does the report packet header address translation. The 
> > payload is not touched.
> >    Then the question is the report may carry private address that 
> > collector may or may not recognize.
> >
> > 2) NAT does the report packet header address translation. If ipfix 
> > ALG is built, it may also translate the IP address in the report. 
> > Then collector doesn't care the private address space at all. But 
> > doing NAT ALG is difficult and may not be applicable all the time.
>
> > > We should provide a way to report the NAT info if the device knows 
> > > it. It is not a required field since not all devices will have it. 
> > > IMHO it should be reported as attributes of one flow, not multiple 
> > > flows.
> > >
> > > Paul
> > >
> > > "Wang, Cliff" wrote:
> > > >
> > > > The problem is that the NAT box is in the path and the probe may 
> > > > not have any knowledge of the outside IP address it may get 
> > > > assigned. The collector may know the mapping if it knows the 
> > > > inside private address of the probe.
> > > >
> > > > Cc: Norseth, KC; [email-masked]; K.C. Norseth; ipfix 
> > > > arch; ipfix data; ipfix chairs
> > > > Subject: Re: Agenda
> > > >
> > > > Hi all
> > > >
> > > > >
> > > > >
> > > > > Concerning some form of capabilities negotiation I have It is 
> > > > > also useful for the case of overlapping flows (discussed on 
> > > > > the
> > > > > list)
> > > > >
> > > > > Middlebox:
> > > > > What about when the device is also a middlebox ? (sorry if 
> > > > > this was already hashed out on the list) If using NAT/NAPT 
> > > > > should the device export the flow on the private side, public 
> > > > > side or both? Should the behavior be agreed on the 
> > > > > capabilities negotiation?
> > > >
> > > >     In case the exporter is doing NAT, the exporter MAY choose 
> > > > to export
> > > >
> > > > This just implies that the information model MUST have inside 
> > > > and outside IP addresses defined.
> > > >
> > > > Regards, Benoit
> > > >
> > > > >
> > > > >
> > > > > I think the most useful behavior would be export the flows on 
> > > > > the private and public side within the same record (or if in 
> > > > > different records provide some key to bind them together), so 
> > > > > you know the complete flow end-to-end. But in this case 
> > > > > although we have two seprate flows, it is still the same 
> > > > > packet. Same reasoning can be applied for proxy, proxy 
> > > > > firewalls, etc.
> > > > >
> > > > > information. All it sees is the snapshot of what is passing 
> > > > > by. This could be worked out as a MAY.  Whether it is resolved 
> > > > > or not, we should clarify the stance on NAT in the archecture.
> > > > >
> > > > >
> > > > > I wouldn't say it's impossible. It depends if the platform 
> > > > > keeps "memory" (full stateful NATs, proxies) or not . And yes, 
> > > > > I agree that whatever the outcome we should clarify NAT/NAPT 
> > > > > behavior on the doc.
> > > > >
> > > > > regards,
> > > > >
> > > > > Reinaldo
> > > > >
> > > > >
> > > > >
>
> --
> Unsubscribe mailto:[email-masked] and say "unsubscribe 
> ipfix" in message body

---

From: "Harrington, David" <[email-masked]>
Date: Thu, 7 Feb 2002 14:53:14 -0500

Hi,

Comments inline

> From: Wang, Cliff [mailto:[email-masked]]
> Sent: Friday, February 01, 2002 1:16 PM
> To: Calato, Paul; ipfixx
> Subject: [ipfix] RE: NAT (aka agenda)
> 
> 
> Paul,
> 
> I think we probably out of sync in the scenario we picture. I 
> think we have
> potentially two scenarios:
> 1) NAT is performing on the flow being reported. Yes I am 
> totally agree with
> your analysis.
> 2) NAT is between the probe and the collector. Actually I am 
> talking about
> this case, where NAT performs on the reporting traffic.
> 
> Again, I agree with your standing that if either probe or 
> collector knows
> the NAT mapping, use it. Otherwise, it is out of the scope of 
> this WG to
> find the NAT info.

There is a concern that NAT hides what is actually happening on the network.
In some cases this is desirable; in other cases it is not. 

For a billing application, it probably doesn't matter. The most likely
billing scenario is a server farm with a NAT front-end, hiding the details
of how the service is provided. The supplier is fairly likely to own both
the back-end server and the front-end NAT device.

For a network capacity planning application or a security application, and
others, it may be very important to know that the flow actually occurred on
a back-end server, which server it was, and possibly which front-end it was.
Hiding the real network relationships makes it impossible to analyze the
data in a useful way in situations where knowing the difference is
important.

Therefore, I think it is important to provide both addresses if both are
known at the flow device, and for some applications it is important to not
change the data in the report when passing through an ALG.

See RFC2962 for a fuller discussion of the issues.

dbh
David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
  
> > > Agree. But finding the NAT info should be out of the 
> scope of this 
> > > WG.
> > 
> > 1) NAT does the report packet header address translation. 
> The payload 
> > is not touched.
> > 2) NAT does the report packet header address translation. 
> If ipfix ALG 
> > is built, it may also translate the IP address in the report. Then 
> > collector doesn't care the private address space at all. 
> But doing NAT 
> > ALG is difficult and may not be applicable all the time.
> 
> device knows 
> > > > > also useful for the case of overlapping flows 
> (discussed on the 
> > > > > list)
> > > > >
> > > > > Middlebox:
> > > > > you know the complete flow end-to-end. But in this 
> case although 
> > > > > we have two seprate flows, it is still the same packet. Same 
> > > > > reasoning can be applied for proxy, proxy firewalls, etc.
> > > > >
> > > > > This could be worked out as a MAY.  Whether it is resolved or 
> > > > > not, we should clarify the stance on NAT in the archecture.
> > > > >
> > > > >

---

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 7 Feb 2002 12:56:12 -0800

Hello David,
 
please refer to the MIDOCM discussion on the upcmong draft. I think I
covered most of these issues. 
 
thanks,
 
Reinaldo

-----Original Message-----
From: Harrington, David [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 11:53 AM
To: ipfixx
Subject: RE: [ipfix] RE: NAT (aka agenda)

Hi, 

Comments inline 

> From: Wang, Cliff [ mailto:[email-masked]
<mailto:[email-masked]> ] 

dbh 
David Harrington 
  
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > From: Benoit Claise [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Help        mailto:[email-masked]
<mailto:[email-masked]>  and say "help" 
> in message body 
> Unsubscribe mailto:[email-masked]
<mailto:[email-masked]>  and say 
> Archive     http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>