Subject: RE: [ipfix] Draft updates - Comments on the data model

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 20:53:49 -0800

Hello Paul,

the problem with the "virtual" word is that there is no way to find out what
is "virtual" and what is not. So, the "virtual" can be actually the real
one.  This is the same thing as outside and inside. See
draft-iab-unsaf-considerations-01.txt. In the case of twice NAT where Src,
Dest and Port may change it's really a mess.

regards,

Reinaldo

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 12, 2002 9:04 AM
>To: Juergen Quittek
>Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
>[email-masked]; data
>Subject: Re: [ipfix] Draft updates - Comments on the data model
>
>
>
>Comments in-line...
>
>Juergen Quittek wrote:
>> 
>> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
>> 
>> >
>> > Comments:
>> >
>> > First ol all, would you guys mind if I rewrite this whole
>> > section using the words "private side" and "public side" so
>> > we align our nomenclature to RFC2663?
>> 
>> Why risking further inconsistencies? Just refer to RFC 2663.
>> All you want to introduce is well explained there.
>> 
>> >
>> > Also, the subsection titles refer to "virtual" this and that,
>> > but the IEs refer to "outside" and "inside". So, we need some
>> > unified terminology. I also think that using inside and outside
>> > can cause confusion since the exporter/collector does not know
>> > what's inside and outside. See 
>draft-iab-unsaf-considerations-01.html
>> 
>> I still have problems with "virtual", "inside", and "outside".
>> This applies to firewalls and IPv4 NATs, but not to several other
>> boxes. Why not using more general terms, such as "received" and
>> "transmitted" or "original" and "modified". These terms would
>> apply to a wider range of boxes (what is "inside" for a NAT-PT?).
>> 
>> This would make the draft more independent from certain NAT/firewall
>> scenarios and would be understandable even for people who do not care
>> about NAT issues at all.
>
>	I thought I addressed this already buit let me try
>	again. BTW - I believe this my proposal is not
>	at all specific to NAT/firewall. Maybe an example is 
>	the best way to explain it. Using your terminology it
>	looks like this
>
>	Flow on the way out...
>
>		C -> IP-R gets translated to C -> IP-A
>
>	Gets reported as
>
>		Src              = C
>		Dest-Received    = IP-O
>		Dest-Transmitted = IP-A
>
>	On the way back
>
>		IP-A -> C  gets translated to IP-O -> C
>
>	Gets Reported as
>
>		Src-Received    = IP-A
>		Src-Transmitted = IP-O
>		Dest            = C
>
>
>
>	Now suppose I want to find all the flows to and from 
>	my virtual IP. First I need a list of virtual IP's so
>	I can find them. Then I need to search both the received
>	and transmitted fields for both Src and Dest. It can be
>	done but it can also be easier (maybe not easier for
>	the IPFIX protocol but that's not what we're here for).
>
>	If reported as I proposed it looks like this...
>
>
>
>		Src            = C
>		Dest-virtual   = IP-O
>		Dest-Actual    = IP-A
>
>		Src-virtual    = IP-O
>		Src-Actal      = IP-A
>		Dest           = C
>
>	Now if I want to see all the traffic for my
>	virtual IP's I just look for flows that have
>	the same src or dest virtual address. I don't
>	need a list and the query is simple. Also, the
>	data in the fields is clear. The actual field
>	is where the packet actually came from or
>	went to. The virtual is the requested source
>	or destination.
>
>
>	This work for ANY packet that gets re-directed for ANY
>	reason. Even if IP's are not actually modified. Such
>	as MAC based re-direction.
>
>
>> 
>> Reinaldo, you talked about good writing. I think this includes
>> avoiding irrelevant information (while still remaining clearly
>> understandable).
>> 
>> > other stuff.
>> >
>> [...]
>> >
>> > then in 5.11.18 and 5.11.9
>> >
>> > "The Destination Virtual IE contains the destination address of
>> > the flow/port as *received* by the Exporter"
>> >
>> > It should be *transmited* by the exporter, ie, you need an almost
>> > complete 5-tuple set of IEs for the private side and for the
>> > public side.
>> 
>> You see, it already gets confusing. "received/original destination"
>> would have been a much better choice of term compared to "virtual
>> destination".
>> 
>>     Juergen
>> --
>> Juergen Quittek     [email-masked]     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
>

---

From: [email-masked]
Date: Wed, 13 Feb 2002 08:59:02 -0500

From that draft....

   However, as a side effect of address
   translation, communicating endpoints on either side of the middlebox
   do not know how to refer to themselves using addresses that are
   applicable in the other realm -- the address translation is locked
   within the middlebox. 

I assumed it was the "middlebox" doing the reporting. In that
case it has all the info needed. If not, then I agree
trying to figure it out after the fact would be dificult.

Paul

Reinaldo Penno wrote:
> 
> Hello Paul,
> 
> the problem with the "virtual" word is that there is no way to find
> out what is "virtual" and what is not. So, the "virtual" can be
> actually the real one.  This is the same thing as outside and inside.
> See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT
> where Src, Dest and Port may change it's really a mess.
> 
> 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: [email-masked]
Date: Wed, 13 Feb 2002 08:59:02 -0500

From that draft....

Paul