Subject: RE: [ipfix] Requirements: Encryption and Anonymozation

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 30 Jul 2003 13:15:36 -0400

Nevil,

  I agree with statements on anonymization.  I.e. it is still a research
area.  The flows are staying w/in the operators domain, so what they collect
must have privacy considerations addressed before sharing (providing
aggregate summaries to other parties is one way to effectively remove
individual information).

  I agree with the approach on encryption of communication, although I am
less certain how frequently it will be used.

Regards,

  Jeff Meyer

-----Original Message-----
From: Nevil Brownlee [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 9:52 AM
To: [email-masked]
Subject: [ipfix] Requirements: Encryption and Anonymozation

Hello all:

I've been thinking about Allison's rejection of our Anonymization
and Encrytpion SHOULD implement position.
Allison (supported by Randy) believes that they should be 'MUST 
implement's, on the grounds that if they were, people would use them.

My first thought was 'IPFIX charter says "standardize existing
practice",' but I checked it, and it doesn't actually say that.
It does say we'll
  * Identify and address any security privacy concerns affecting
    flow data.  Determine technology for securing the flow information
    export data, e.g. TLS.
so we clearly have to address encryption.  We didn't mention
anonymization in the charter though, it just crept in to the 
Requirements draft.

In an attempt to move forward, I've had some email discussions
with the Requirements Draft editors and co-chairs.  Based on that, 
I propose the following:

 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 IPSEC or IPSEC for that, rather than
    try to do it at the application layer in IPFIX.  So ...
    we should write a 'requirements' sentence saying that "IPFIX
    implementations MUST provide for encryption of exported IPFIX
    data, e.g. by using IPSEC or TLS."  [We need to verify that
    TLS would be suitable for this.]

 b) For anonymization, we should remove any mention of it from
    the Requirements Draft, because:
    - 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 are several anonymoization tools one could
      use.  tcpdpriv is the most common, but it has known
      vulnerabilities.  Crypto-PaN is probably better, but has high
      processor demands.  Overall, good algorithms for anonymization
      are still a research issue, not something which is ready to go
      into production network devices.

In a more detailed comment on 'privacy' vs 'security', Sebastian Zander
said:

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

I like the idea of a 'privacy considerations' section, probably in the
Architecture draft (rather than the Requirements draft).

What do you think?  Lets have some feedback on the list, please, just
a line saying 'yes for encryption, no for anonymization' would be fine.
But we want to get the Requirements Draft finished, so please respond
quickly!

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

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

--
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: Alex Audu <[email-masked]>
Date: Wed, 30 Jul 2003 13:53:53 -0500

I am not sure if the issue is having IPFIX anonymize the packets in the collected

flows. I think the real issue is: can IPFIX handle anonymized packets? It may be
be able to. I just don't know.

Regards,
Alex.