Subject: Re: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues]

From: Ganesh Sadasivan <[email-masked]>
Date: Mon, 01 Mar 2004 11:08:05 -0800

Hi Juergen,
   
    If there is no obervability into the IP packet, naming it as an IP flow
    is incorrect for  it is not known if it is an IP flow.  The first 
question would be
    whether we want to classify such an observation point as IPFIX
    observation point? I am inclined to say that unless the observation 
point has
    the capability to peek into atleast 1 IP header  in the packet that 
it observes,
    it should not be a valid IPFIX observation point.

    As far as a flow is concerned, even if  the observation point has 
visibility into
    IP packets, it may not choose to define flows based on any of the 
fields in the
    IP header.

     Consider one more case. Say an observation point has capability to
     peek into the first 20 bytes after the L2 header and it receives IP and
     MPLS packets. For a normal IP packet, the metering process can get
     the entire header information. But if  there is 1 MPLS label, part 
of the
     IP header becomes non-observable. If there are 5 or more labels, then
     not even a single byte of the IP header is visible. In such a case IMO
     they should not be counted as valid IPFIX  flows.

     What you mentioned about IPSEC is one variation of a general
     problem of encapsulated packets .i.e " what is the flow definition 
in the
    case a packet has multiple encapsulations and the observability into
     all the encapsulations is  limited  either because of performance or
     capability at the observation point."
     
     IMHO we could have the following guidelines:
     1. The observation Point MUST be able to observe atleast 1 IP header.
     2. If there are multiple levels of encapsulation, the flow MAY be 
defined
          choosing fields from the encapsulation at any level. This 
depends on whether
          the observation point has the capacity to observe the fields 
that defines the
          flow.
     3. We should build capability in the information model (and while 
encoding the templates)
         to describe the encapsulation information along with the field 
information.

Thanks
Ganesh

Juergen Quittek wrote:

> Dear all,
>
> I have a need for clarification:
>
> At an IP device, or better: at a device that handles the header of
> an IP packet (whether it arrives encapsulated or not) I have no problem
> with considering the sub-IP layers as flow attributes or even part of
> the flow key.
>
> But at non-IP devices, for example an ATM or MPLS switch, where
> packets/frames/cells are just forwarded based on their label/VPI/VCI
> we enter a gray area: If we just look at the labels we need some
> higher level/outside information in order to know that there are IP
> packets carried with a certain label. Still we do not know if the label
> is exclusively used for IP packets, for example when running Ethernet
> over MPLS.
>
> So, if at the observation point no IP packet is visible to be observed,
> then why should we call this an observed IP flow?
>
> A related issue is IPsec. The encapsulated IP flow is not visible at
> the IP router forwarding it.  Hence, is cannot observe it at the 
> observation
> point. Hence, we do not consider it an observed IP flow.  This would be
> different in a situation where the router holds a copy of the key that is
> needed for decoding the packets. If done so and the IP header can be 
> observed,
> I would call it an observed IP flow (although this smells like 
> surveillance).
>
> Thanks,
>
>    Juergen

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