Re: [IPFIX] [Sender: [e-mail]] Re: Maji - an open source IPFIX meter implementation

[Andrew Johnson <[e-mail]>]

Gerhard Muenz wrote:
> Hi Andrew,
> 
>>>> Looking again, you seem to have have a start, stop and mask value for
>>>> each filter.  So what would you expect the behaviour to be of a filter
>>>> that demands a TCP flags value of 0 when faced with a UDP packet?
>>> I do not know. Is it defined somewhere?
>> Not as far as I know, however if you're matching on and IPv4 address of
>> 192.168.0.1, I would not expect all IPv6 traffic to pass the filter.
> 
> Is it useful to add a note to PSAMP-TECH?

Probably, but maybe too late now.


>>>> My instinct is that it should reject the UDP packet because it cannot
>>>> provide a TCP flags value of 0.  An alternate filter could be set up to
>>>> accept UDP packets.
>>>>
>>>> If we agree on that point, then how about a TCP flags filter that
>>>> filtered on TCP flags being in the range 0x00 to 0xFF.  It would accept
>>>> all values for the TCP flags field, but reject packets that didn't have
>>>> the field.
>>> Then, we could place a property match filter in front of the Cache that
>>> matches all fields of the Cache Layout with mask=0x00 (or start=0 and
>>> end=infinity) to ensure that all fields are present.
>> Exactly.
>>
>>
>>> However, I'm a little bit confused about the following paragraph in
>>> PSAMP-TECH:
>>>
>>> 6.1 Property Match Filtering
>>>
>>>     ....
>>>
>>>     A packet is selected if Field=Value. Masks and ranges are only
>>>     supported to the extent to which [RFC5102] allows them e.g. by
>>>     providing explicit fields like the netmasks for source and
>>>     destination addresses.
>>>
>>> Also, PSAMP-PROTOCOL does not allow to export a value range [start,
>>> stop] in an Option :(
>> Yes, I know.  It's very difficult to export min/max/mask using IPFIX
>> without defining new Information Elements for each field you want to
>> filter on.
> 
> Hm, I do not think that defining min/max/mask IEs for every existing IE
> is needed. I'm sure that a better solution can be found.

Perhaps, I'd certainly like to think so, but so far I've not seen any real
contenders.  I can't think of anything that doesn't need data types and/or
deviate a lot from how we use IPFIX today.


>>> Note that the configuration data model is based in PSAMP-MIB where
>>> "start", "stop" and "mask" are mentioned as parameters of property match
>>> filtering. It seems that these parameters are outdated?
>> When we added the Filtering Interpretation Report in version 02 we
>> didn't have min/max/mask either.  There's just no easy way to export
>> this sort of think in IPFIX without defining three additional I.E.s per
>> field.  Unless anyone can think of something?
> 
> Yes:
> http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01

I don't see how this helps, other than the ability to exclude certain
values.  I didn't see any indication of how to handle multiple uses of
the same I.E., but presumably they follow the same rule as for different
I.E.s and are added with an AND operation, and are therefore
automatically conflicting.

For example, how would you represent a match on the TCP syn flag?  With
min/max/flags we could have 0x02, 0x02, 0x02.  Easy.

In the Filtering Interpretation Report you could use multiple inclusion
filters / selection paths:

  OP1, TCP flags = 0x02
  OP1, TCP flags = 0x03
  OP1, TCP flags = 0x06
  OP1, TCP flags = 0x07
  ...
  OP1, TCP flags = 0x1A
  OP1, TCP flags = 0x1B
  OP1, TCP flags = 0x1E
  OP1, TCP flags = 0x1F

Yuck.

How would this be done with
http://tools.ietf.org/html/draft-sommer-ipfix-mediator-ext-01?


> In my opinion, the current property match filtering specified in PSAMP
> is too restrictive because it only covers simplistic fiters that are
> rarely used in practice. Maybe it should be removed from the documents
> until a better solution is found.

Well, a future draft could extend the filtering mechanisms, but I don't
think we should discard what we have today.  A new selection type can be
added later when we have a way of representing more complex solutions.

Cheers

Andrew