Subject: [ipfix] "long aging" flows

From: Robert Stone <[email-masked]>
Date: Tue, 18 Jun 2002 15:42:43 -0400

Sorry, I haven't been doing a good job of keeping up with the list so
hopefully this isn't redundant.  Anyway,

in draft-ietf-ipfix-architecture-02, in the section:

7. Flow Expiration
...

     2. If the flow has been inactive for a certain period of time.
        This inactivity timeout SHOULD be configurable.  For example:
        flow generated by UDP type of traffic.

     3. For long aging flows, the exporter SHOULD export the flow
        records on regular basis, in order to:

          a. Report the flow records periodic accounting information to
             the collector
          b. Avoid counter wrapping This activity timeout SHOULD be
             configurable

I would add something like:

          c. Prevent an attacker from indefinitely delaying the delivery 
             of flow information to an (e.g. IDS) application by
             generating packets which fall within long aging flows.

Also, for "IDS" type applications some configuration option for #3
is really a must.  This "active timeout" or "update interval" could
default to some long value (30 minutes, for example) but it's pretty
critical to time and security sentitive applications that it be
configurable.

Robert Stone
Arbor Networks

--
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: "K.C. Norseth" <[email-masked]>
Date: Tue, 18 Jun 2002 20:01:28 -0600

Hi Robert,

----- Original Message -----
From: "Robert Stone" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 18, 2002 1:42 PM
Subject: [ipfix] "long aging" flows

| Sorry, I haven't been doing a good job of keeping up with the list so
| hopefully this isn't redundant.  Anyway,
|
| in draft-ietf-ipfix-architecture-02, in the section:
|
| 7. Flow Expiration
| ...
|
|      2. If the flow has been inactive for a certain period of time.
|         This inactivity timeout SHOULD be configurable.  For example:
|         flow generated by UDP type of traffic.
|
|      3. For long aging flows, the exporter SHOULD export the flow
|         records on regular basis, in order to:
|
|           a. Report the flow records periodic accounting information to
|              the collector
|           b. Avoid counter wrapping This activity timeout SHOULD be
|              configurable
|
|
| I would add something like:
|
|           c. Prevent an attacker from indefinitely delaying the delivery
|              of flow information to an (e.g. IDS) application by
|              generating packets which fall within long aging flows.

Agreed.

| Also, for "IDS" type applications some configuration option for #3
| is really a must.  This "active timeout" or "update interval" could
| default to some long value (30 minutes, for example) but it's pretty
| critical to time and security sentitive applications that it be
| configurable.

Agreed.  For me, this was a given, but if they want it for IDS, then it MUST
be configurable.

K.C.

| Robert Stone
| Arbor Networks
|
| --
| 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/
|