Re: [IPFIX] exporting ranges in IPFIX

[Senthil Sivakumar <[e-mail]>]

On 6/11/12 10:48 AM, "Brian Trammell" <[e-mail]> wrote:

>Hi, Paul, all,
>
>As for adding the port block range IEs, this makes sense as there is (1)
>no generic range mechanism for IPFIX and (2) no way to report blocks of
>ports semantically consistent with that required by
>draft-ietf-behave-lsn-requirements.
>
>Two comments, neither particularly IPFIX-specific:
>
>First, there is a danger here, of course, that self-inconsistent
>information can be reported using either the step size or number of ports
>in block for stepped ranges: simply report a step or count greater than
>the range. This should of course be treated in the descriptions of the
>IEs...

True. There is an effort underway in Behave that is capturing the IE's for
NAT logging. And we should have all the constraints and restrictions on
what should be reported/collected.

>
>Second, it's not clear that the proposed solution covers the applications
>envisioned by the draft in question; from section 5:
>
>   Note that this list is not exhaustive.  There is a continuum of
>   behavior that a CGN may choose to implement.  For example, a CGN
>   could use scattered port sets of consecutive port sets.

It is very difficult to have a generic solution for all possible port
allocation mechanisms. There are two goals : one is to reduce the amount
of logs sent/received (to avoid per-connection logging) and not to be too
predictable that would open one to attacks. That is where the bulk
allocation with some arbitrary step size. Of course, it is not fool proof
in all respects.


>
>The stepped-range thing seems a little hackish to me, but I'm not at all
>familiar with how things are done on CGNs. What about disjoint stepped
>ranges? What about uneven steps? Hacks are great, but they should at
>least address the whole problem, I think. However, I suppose these IEs
>plus structured data would handle every reasonable case... if that's the
>approach, that should also be mentioned.

If one wants to have uneven steps or some complex port scattered
allocation mechanism then the implementations would have to figure out the
necessary information that would required to be synced so that the
exporter and collector can work in tandem knowing what port is allocated
to which user. We don¹t have such a mechanism today and when we have one,
we might have to come back and ask for additional fields if required.

Thanks
Senthil

>
>Cheers,
>
>Brian
>
>
>On Jun 8, 2012, at 11:06 PM, Paul Aitken wrote:
>
>> Dear all,
>> 
>> I've had two feedbacks requesting a range start / range end mechanism.
>>So I propose to request four fields:
>> 
>>   Port block start:           16 bits
>>   Port block end:             16 bits
>>   Port block step size        16 bits
>>   Number of ports in block    16 bits
>> 
>> These can be reported in whatever way best matches the implementation.
>> 
>> eg, { start, step, number }, { start, end, step }, { start, end, number
>>}.
>> 
>> The default step size will be 1, so { start, end } indicates a
>>contiguous range.
>> 
>> Finally, I've upped the step size from 8 bits to 16 bits to allow step
>>sizes > 255.
>> 
>> Any further feedback?
>> 
>> Thanks,
>> P.
>> 
>> 
>> On 05/06/12 16:29, Paul Aitken wrote:
>>> Dear IPFIX experts,
>>> 
>>> As far as I know, IPFIX doesn't have a generic mechanism for reporting
>>>ranges.
>>> 
>>> I'm looking for a way to report bulk port allocation per section 5 of
>>>http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05.
>>> 
>>> This method would be useful for reporting port ranges in
>>>draft-tsou-behave-natx4-log-reduction-02 and
>>>draft-bajko-pripaddrassign-04.
>>> 
>>> So I propose to request three new IPFIX Information Elements:
>>> 
>>>   Port block start:           16 bits
>>>   Port block step size         8 bits
>>>   Number of ports in block    16 bits
>>> 
>>> 
>>> However, there could be better ways to export a "range" which don't
>>>require three new IEs each time. Do you forsee a need for a such a
>>>mechanism?
>>> 
>>> Shall I proceed with my request to IANA? If so, should I write a short
>>>ID explaining how the three IEs should be used together?
>>> 
>>> Thanks,
>>> P.
>>> 
>>> _______________________________________________
>>> IPFIX mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>> 
>> _______________________________________________
>> IPFIX mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>_______________________________________________
>IPFIX mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ipfix