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

From: "Carter Bullard" <[email-masked]>
Date: Wed, 30 Jul 2003 15:29:21 -0400

IPSEC compatibility requires nothing of IPFIX but
anonymization indication support requires at least
a bit in the IPFIX header to indicate that the
addresses, time, ports, protocols, whatever, are
not real.

A MUST for IPSEC requires nothing of the protocol
and is completely unenforceable, so it will be an
extremely weird statement in the RFC.  Sounds
like religion or better yet, marketing instead
of anything else.

A MUST for anonymization indication support is
appropriate, but the IETF should NOT try to define an
anoymization algorithm.

Carter

> -----Original Message-----
> From: majordomo listserver
> [mailto:[email-masked]] On Behalf Of Alex Audu
> Sent: Wednesday, July 30, 2003 1:54 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'Nevil Brownlee'; [email-masked]
> Subject: Re: [ipfix] Requirements: Encryption and Anonymozation
>
>
> 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.
>
> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>
> > 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/
>
>
> --
> 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: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 30 Jul 2003 12:31:32 -0700

Hi,

  I think anonymized identifiers could be defined as simply another element
in the data model leaving the anonymization mechanism up to the
implementation.

  This would imply the collector could do aggregation around anonymized
identifiers, but would not be able to associate these with users.

  In practice I think Nevil raises the question whether such anonymization
operations would likely find their way onto exporting systems.  I think
there is also the question of what the field type is for an anonymized
identifier (e.g. does an anonymized v4 address still land in a 4 byte field
or is it mapped to a larger space, using some crypto hash)
  
  Are any items other than IP (v4 or v6) addresses targets of anonymization?
I would think not.  But...

  One could argue that correlation techniques may allow for detection of
anonymized identifiers via techniques such as sending sets of flows to known
ports, or of known size or some other pattern to a target, thus allowing the
IP address associated with an "anonymized" flow to be inferred from a set of
flows.

  I fear that that such "attacks" on anonymization and attempting to address
them would turn into a rathole...  Or effectively render the anonymized flow
useless.  Aggregation (i.e. a post collection task) would address this.  At
the raw flow level, I have my doubts.

-- Jeff

-----Original Message-----
From: Alex Audu [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 11:54 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Nevil Brownlee'; [email-masked]
Subject: Re: [ipfix] Requirements: Encryption and Anonymozation

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.

"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:

> 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
> 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
> implement's, on the grounds that if they were, people would use them.
>
>     flow data.  Determine technology for securing the flow information
>     export data, e.g. TLS.
>       IPFIX data can be encrypted in transit, there is no operational
>       data before giving researchers access to it, that is easily done
> 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
> > 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
> > I think there are differences between security and privacy which justify
> > - Security/encryption can *always* be used for ipfix although it means
> >    using more resources etc. whereas privacy/anonymization can *not* be
> > - 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
> > - 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
> > - 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
> I like the idea of a 'privacy considerations' section, probably in the
> 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
>
> -----------------------------------------------------------------------