Subject: [IPFIX] exporting ranges in IPFIX

From: Paul Aitken <[email-masked]>
Date: Tue, 05 Jun 2012 16:29:15 +0100

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.

---

From: Andrew Feren <[email-masked]>
Date: Tue, 05 Jun 2012 11:35:26 -0400

Hi Paul,

This seems useful, but out of curiousity, why "Number of ports in block" 
instead of "Port block end".

-Andrew

On 06/05/2012 11:29 AM, Paul Aitken wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Tue, 05 Jun 2012 16:50:32 +0100

Andrew,

> This seems useful, but out of curiousity, why "Number of ports in 
> block" instead of "Port block end".

Because (step size) x (number of steps) clearly identifies the end, 
whereas (end - start) might not divide evenly by (size).

ie, starting at 1000, with a step size of 10, ending at 1195... the last 
value is ambiguous. Should we stop before or after 1195?

Whereas starting at 1000, with 20 steps of 10, the last value is 
unambiguous.

P.

>> As far as I know, IPFIX doesn't have a generic mechanism for 
>> reporting ranges.
>>
>> 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.
>>

---

From: Paul Aitken <[email-masked]>
Date: Fri, 08 Jun 2012 22:06:06 +0100

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.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 11 Jun 2012 16:48:45 +0200

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

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.

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.

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:
> 
> 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.
> 
> 
>> 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.
>> 
>> 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.
>>

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 11 Jun 2012 12:33:01 -0400

On 6/11/12 10:48 AM, "Brian Trammell" <[email-masked]> 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.
>
>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:
>

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