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

From: "Wang, Cliff" <[email-masked]>
Date: Fri, 1 Feb 2002 18:16:17 -0000

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.

cliff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 01, 2002 11:53 AM
To: Wang, Cliff; ipfixx
Subject: Re: NAT (aka agenda)

"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: "Carter Bullard" <[email-masked]>
Date: Fri, 1 Feb 2002 13:54:50 -0500

Gentle people,
   Reporting an alias for a key element, such as an
address which may be NAT'd, or the actual DNS name
for a specific address in the flow key, are just a few
of the additional attributes that we will want to
provide in a flow report.  Other examples may include
the session protocol used, such as RTP, the application/
service name as an alias for the service port, or even
the MAC addresses, as extended attributes of the src
and dst identifiers.  IPFIX should be able to handle
any of these.  I don't see NAT as particularly more
or less complicated.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> From: majordomo listserver 
> [mailto:[email-masked]] On Behalf Of Wang, Cliff
> Sent: Friday, February 01, 2002 1:16 PM
> To: [email-masked]'; 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.
> 
> cliff
>

---

From: Benoit Claise <[email-masked]>
Date: Sat, 02 Feb 2002 00:43:26 +0100

Hi Cliff,

> 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