Subject: [ipfix-reqs] Re: IPFIX Requirements issues (resend)

From: Nevil Brownlee <[email-masked]>
Date: Fri, 3 Oct 2003 15:18:05 +1200

Hi Randy:

> in the absense of allison's response, i will now move the process.
> 
> how do you feel the wg has addressed her comments?

Juergen Quittek, the Requirememnt Draft Editor hasn't responded to me 
yet, so I'll answer your question directly.

The IPFIX WG discussed the IESG questions arising from version -10.txt,
and agreed that all except those from Allison concerning Confidentiality
and Anonymisation would be handled by small editing changes.

There was a lively discussion of Confidentiality and Anonymisation on the 
IPFIX list after the Vienna meeting.  We reached a clear WG consensus, as follows:

 a) A fair proportion of users probably would use encryption to
    get their IPFIX data safely across the Internet.  We've said
    all along that we'd use TLS or IPSEC for that, rather than
    try to do it at the application layer in IPFIX.

    We propose to addres your concern about IPFIX encrytion by
    changing the IPFIX Requirements draft to say that "IPFIX
    implementations MUST provide for encryption of exported IPFIX
    data, e.g. by using IPSEC or TLS."

 b) For anonymization the situation is much less clear.
    - IPFIX data will normally be collected by network operators
      for traffic engineering and/or accounting purposes.  In both
      these cases raw (un-anonymized) data is needed; again, since
      IPFIX data can be encrypted in transit, there is no operational
      need for further privacy protection.  
    - Although it may be useful for operators to anonymize traffic
      data before giving researchers access to it, that is easily done
      (as at present) using anonymization tools.
    - At this stage there is not a clear understanding of how to
      implement anonymisation.  There are at least three algorithms
      in use (Crypto-PaN, tcpdpriv, and hashing each address to
      a randomly chosen anonymised address).  Each algorithm has
      different resource demands, and produces different properties
      in the anonymised addresses.  We believe that anonymization is
      still a research issue, not something which is ready to go
      into production network devices.

   We propose that rather than attempt to standardise anonymisation,
   we should remove all mention of it from the IPFIX Requirements
   draft.

 c) Notwithstanding the remarks in (b), the WG believe that we need
    to address users' privacy concerns.  We propose to do this by
    adding a 'Privacy Concerns' section to the Requirements draft,
    as suggested by Sebastain Zander (appended bleow).

I emailed Allison on 7 August 03 to ask whether this was sufficient; 
I've had no response.  'Agreement in principle' is what we're waiting for.
Given that, the IPFIX requirements editors will press ahead, make the 
changes and resubmit requirements-11.txt for IESG consideration.

Meanwhile, in the last week or so the IPFIX list seems to have woken
up, I hope that we'll have the four main IPFIX drafts fairly complete
in time for the November meeting.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

Sebastian Zander's suggestion:

> I think that IPFIX must deal with privacy issues somehow. Afterall we
> are standardizing something which could be used to get a detailed log
> of a users activities.
>
> Different countries may have completly different laws on privacy. But
> there are laws (e.g. in the EU). So what may be a privacy violation in one
> country may not be a privacy violation in another.
>
> In general i agree to your proposal. However i think some of the arguments
> against a MUST are not too strong. If i have a flat rate why would my
> provider need to record my flow data? What would prevent someone to give
> a 3rd party access to ipfix informtion? Technically nothing...
> (but there are laws).
>
> I think there are differences between security and privacy which justify
> a different treatment IMO:
> - Security/encryption can *always* be used for ipfix although it means
>    using more resources etc. whereas privacy/anonymization can *not* be
>    used in any case (e.g. in case of accounting srcip must not be
>    anonymized).
> - We have to assume that in those cases the people who use ipfix comply to
>    the relevant privacy laws. Privacy can't be enforced by the protocol
>    itself, only by laws or social norms.
> - The scenarios where people would like to access ipfix data and can do
>    this only through the use of anonymization are currently rare and out
>  of scope(?).
> - Encryption techniques are more mature and widely understood whereas
>    anonymization techniques are still research and therefore its more
>    difficult to put them into a standard now.
> - I think its not the scope of this group to develop and/or standard
>    anonymization techniques. There are standards for encryption but for
>    anonymization?
>
> Maybe it would be a good idea to have some text on privacy considerations
> in the draft (similar to security considerations).

-------------------------------------------------------------------------------

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
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: Randy Bush <[email-masked]>
Date: Thu, 2 Oct 2003 23:06:16 -0700

thanks, nevil

randy