Subject: [ipfix] NAT repoiting (was agenda)

From: "Norseth, KC" <[email-masked]>
Date: Fri, 1 Feb 2002 11:30:23 -0500

I am sending this to the whole list for concensus and comments....

Is it out of scope?  It is definitly not a key component of the IPFIX data,
where it is not even possible to get in a lot of circumstances.  It does
contain part of the Flow Information of a flow.  If we can report it, it
would be useful for attributes.  What NAT atreibutes would want to be
reported ?

K.C.

|-----Original Message-----
|From: Wang, Cliff [mailto:[email-masked]] 
|Sent: Friday, February 01, 2002 9:18 AM
|To: Calato, Paul
|Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; 
[email-masked]; K.C. Norseth; ipfix arch; ipfix data; 
|ipfix chairs
|Subject: RE: Agenda
|
|
|Agree. But finding the NAT info should be out of the scope of this WG.
|
|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?
|
|-----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
|> >
|> >
|> >
|

---

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 01 Feb 2002 08:59:31 -0800

The only relevance I see here is an ability for the exporter to
tell that "this is a NAT address type" (if it has the capability)
and for the collector to recognize the structure of this field
at the minimum and if it capable of understanding the semantics,
it can do more interpretation.
There are similar issues of multiple addresses with IPV6 mobility.
But the general rule I think should be the collector should at the
minimum be alse to understand the structure of the exported data
even if does not know the semantics.

Thanks
Ganesh

"Norseth, KC" wrote:

>   ------------------------------------------------------------------------
>
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

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