Subject: RE: [ipfix-data] Data doc - Section 7.11

From: "Reinaldo Penno"<[email-masked]>
Date: Fri, 12 Apr 2002 23:05:22 -0700

My concern with the "virtual" wording is that there is nothing "virtual"
about the modified packet. Virtual implies the original/actual packet is
more real than the modified one, which is not. The modified packet can
actually be more "real" if you are doing NAT, for instance. My opinion is
that another terminology sould be used.

As for the first question, imagine you receive a packet and you apply
several services to it (NAT, insertion of content, whatever) and you want to
report that (the services applied) on flow records. 

So, the order in which you apply these services matters and so the order in
which you report them. As I said, if you apply NAT and then some firewall
(possibly dropping the packet), but on the flow records you say the other
way around, you will get the wrong picture. This is a easy example, but you
can expand that for all other services that modify, drop, tunnel a packet.

regards,

Reinaldo

>-----Original Message-----
>From: Juergen Quittek [mailto:[email-masked]]
>Sent: Friday, April 12, 2002 6:42 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>[email-masked]
>Cc: [email-masked]
>Subject: RE: [ipfix-data] Data doc - Section 7.11
>
>
>Hi Reinaldo,
>
>With 'reflect the order of the operstions performed', do you mean
>finding out what is the original and what the modified header field?
>
>I had a long discussion on the modified scheme versus the modified
>scheme with Paul:
>
>The virtual scheme:
>  Any source-related header field in an arriving packet is called
>  actual. Any destination-reated header field in a leaving packet
>  is called actual. Actual values are the ones usually reported.
>
>  If the value of a source-related header field in a leaving packet
>  differs from its value in the arriving packet, then this value is
>  called 'virtual'. If the value of a destination-related header
>  field in an arriving packet differs from its value in the leaving
>  packet, then this value is called 'virtual'.
>
>The modified scheme:
>  The value of a header field in an arriving packet is called original.
>  Original values are the ones usually reported.
>  If the value of a header field is modified in the leaving packet,
>  then it may be reported as the 'modified' value.
>
>In the end we preferred the virtual scheme. But please feel free
>to convince us that the modified scheme is more appropriate.
>
>    Juergen
>
>
>--On 12 April 2002 11:45 -0700 Reinaldo Penno 
><[email-masked]> wrote:
>
>>
>> Hello Juergen,
>>
>> thanks for the comments. answers inline
>>
>>> -----Original Message-----
>>> From: Juergen Quittek [mailto:[email-masked]]
>>> Sent: Friday, April 12, 2002 4:30 AM
>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>>> [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [ipfix-data] Data doc - Section 7.11
>>>
>>>
>>> Hi Reinaldo,
>>>
>>> --On 09 April 2002 14:49 -0700 Reinaldo Penno
>>> <[email-masked]> wrote:
>>>
>>>>
>>>> In the data doc there was a part that Paul disagrees (or
>>> used to) with me. I'm okay with finding other names anyway,
>>> but IMO the description is better this way
>>>>
>>>> Basically I wanted to change section on NAT/source
>>> virtual/destination virtual to:
>>>>
>>>> 7.11. Middlebox and other Services
>>>
>>> Having to choose between "Virtual Information" and "Middlebox and
>>> other Services", I prefer the first one, because it is as general
>>> as "other services" and it better reflects a meter's view: It does
>>> not care that much about functions and applications/services running
>>> additionally on the same box, it just cares about what such
>>> applications do with packets or beterr with packet headers. Then
>>> the concept of virtual and actual values of header fields seem so
>>> be an adequate and sufficient view of what is happening.
>>
>> no problem, I can change the name. Do you think the 
>description is adequate?
>>
>>>>
>>>> An exporter may be involved in providing services that require
>>>> application level intelligence and/or transform or filter
>>> content such
>>>
>>> I don't think there will be any router or other exporter device
>>> that deserves the attribute 'intelligent'. These boxes are SO dumb!
>>> Just work with them and you'll see :-)
>>
>> he!he! Some of them are a little more 'intelligent'..
>>
>>>
>>>> as middlebox and OPES respectively.
>>>>
>>>> When the exporter is involved on these types of services 
>the order of
>>>> the IEs that contain information associated with these service MUST
>>>> reflect the order of the operations performed.
>>>
>>> No. We should not have a MUST here. This would mean that you
>>> cannot add middlebox functions to your box without updating the
>>> IPFIX software/hardware. You could not run the same implementation
>>> on boxes with different functionality. It is nice if the IPFIX
>>> device reflects middlebox functions, but a MAY should be
>>> appropriate.
>>
>> What I meant by the above phrase is that the order on which 
>these services are applied are very important ans o should be 
>the reporting. If you apply NAT and then layer 2/3 tunneling 
>is different than the other way around. If the exporter does not
>> indicate this, you might get misleading data in the end.
>>
>> So, my point was if you are ptoviding these service you 
>SHOULD be able to report them on the order they were applied. 
>I think that's reasonable.
>>
>>>
>>>>
>>>> Each type field of the following IEs contain the type of operation
>>>> performed on the packet. The currently available types are:
>>>>
>>>> 1. - NAT
>>>> 2. - LSNAT
>>>> 3. - Twice NAT
>>>> 4. - Request Routing [KRR]
>>>> 5. - Outgoing L3 Tunnel
>>>> 6. - Incoming L3 Tunnel
>>>> 7. - Outgoing L2 Tunnel
>>>> 8. - Incoming L2 Tunnel
>>>> 9. - OPES (several sub-services here)
>>>> 10. - others...
>>>>
>>>> 6.12.1.  Modified Source Address
>>>>
>>>> This information element contains the source address of the flow as
>>>> transmitted by the Exporter after a middlebox, OPES or
>>> similar service
>>>
>>> What is a OPES similar service? This is rather unclear, particularly
>>> if you request a MUST to support it. I prefer Paul's term 
>'redirecting
>>> packets/flows'.
>>>
>>>    Juergen
>>>
>>>> was applied to the packet. It may be different than the
>>> source address
>>>> information element, which contains the original source
>>> address of the packet.
>>>>
>>>> The address is defined the same as for Source Address.
>>>>
>>>> Template ID: ###   Field Type: ###   Size: ###
>>>>
>>>> 6.12.2.  Modified Source Port
>>>>
>>>> This information element contains the source port of the flow as
>>>> transmitted by the exporter after a middlebox, OPES or
>>> similar service
>>>> was applied to the packet. It may be different than the source port
>>>> information element, which contains the original source port
>>> of the packet.
>>>>
>>>> Template ID: ###   Field Type: ###   Size: ###
>>>>
>>>> 6.12.3.  Modified Destination Address
>>>>
>>>> This information element contains the destination address 
>of the flow
>>>> as transmitted by the exporter after a middlebox, OPES or similar
>>>> service was applied to the packet. It might be different than the
>>>> destination address information element, which contains 
>the original
>>>> destination address of the packet.
>>>>
>>>> Template ID: ###   Field Type: ###   Size: ###
>>>>
>
>
>

---

From: [email-masked]
Date: Mon, 15 Apr 2002 11:41:00 -0400

Reinaldo Penno wrote:
> 
> My concern with the "virtual" wording is that there is nothing
> "virtual" about the modified packet. Virtual implies the
> original/actual packet is more real than the modified one, which is
> not. The modified packet can actually be more "real" if you are doing
> NAT, for instance. My opinion is that another terminology sould be
> used.
> 
> several services to it (NAT, insertion of content, whatever) and you
> want to report that (the services applied) on flow records.
> 
> So, the order in which you apply these services matters and so the
> order in which you report them. As I said, if you apply NAT and then
> some firewall (possibly dropping the packet), but on the flow records
> you say the other way around, you will get the wrong picture. This is
> a easy example, but you can expand that for all other services that
> modify, drop, tunnel a packet.

	If you are saying that if more than one of these fields
	are reported in a flow then they must be in order,that 
	seems reasonable to me too. But we are NOT saying you must 
	report the fields in the first place, correct?

--
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: Juergen Quittek <[email-masked]>
Date: Mon, 15 Apr 2002 18:55:06 +0200

Reinaldo,

--On 12 April 2002 23:05 -0700 Reinaldo Penno wrote:

> original/actual packet is more real than the modified one,

Not the packet is virtual, but the header entry for source
or destination addresses may be virtual. If a NAT replaces
the source address by its own one while forwarding a packet,
then I think it is acceptable calling the modified source
address field in the leaving packet 'virtual'.

    Juergen

> which is not. The modified packet can actually be more "real"
> if you are
> doing NAT, for instance. My opinion is that another terminology sould be used.
>
> As for the first question, imagine you receive a packet and you apply several services to it (NAT, insertion of content, whatever) and you want to report that (the services applied) on flow records.
>
> So, the order in which you apply these services matters and so the order in which you report them. As I said, if you apply NAT and then some firewall (possibly dropping the packet), but on the flow records you say the other way around, you will get the
> wrong picture. This is a easy example, but you can expand that for all other services that modify, drop, tunnel a packet.
>
> regards,
>
> Reinaldo
>

---

From: [email-masked]
Date: Mon, 15 Apr 2002 12:56:39 -0400

Maybe the picture you drew on your PC would
be helpful.

Paul