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

From: Changhoon Kim <[email-masked]>
Date: Fri, 01 Aug 2003 17:30:37 +0900

Altough I still have some doubt even on the necessity of "encryption", 
anyway, I vote against "anonymization."
Unanonymized flow records play a crucial role in many applications, let 
alone TE.

- Chang

Nevil Brownlee wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 1 Aug 2003 08:28:32 -0700

> anyway, I vote against "anonymization."

this is the ietf.  we don't vote here.

and we are dealing with an inter-area privacy concern.  the iesg will
and has taken this quite seriously.

randy

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 05 Aug 2003 08:13:12 -0500

David Moore wrote:

>On Thu, Jul 31, 2003 at 04:52:28AM +1200, Nevil Brownlee wrote:
>  
>
>How do IPSEC and TLS interact with not using TCP as the transport
>protocol?  For IPSEC, I presume you just tunnel SCTP in it since
>it is packet based, but I have no idea how you'd do TLS with SCTP.
>  
>

David:

RFC3436 details how you use TLS over SCTP.. this works fine but there
is one cavet to using TLS with SCTP... not all of the features will
work... in particular the un-ordered and the soon to be an RFC pr-sctp
cannot be used. This makes sense if one thinks about it since TLS uses
cipher block chaining.. which means everything MUST be delivered in
order for it to work. Note UDP and DCCP have the same issues as well... 
I believe
that Allision was going to work on a "modified" TLS (at least I have heard
that second hand) that might be capable of handling things like UDP, 
DCCP and
PR-SCTP... but this is several years away at best...

>Probably saying that they MUST provide for encryption is fine.
>It's just likely that the preferred format may come down related
>to if there is a mandatory minimal transport protocol to be supported.
>  
>
SCTP or TCP works fine with TLS so it should not be a problem ....
And of course all of them TCP/UDP/SCTP/DCCP work fine with
IP-Sec...

R

>Also, as written, implementations might chose to do encryption in
>some proprietary way and therefore prevent interoperability.  Although,
>obviously one would hope they wouldn't.
>
>  
>
>In a perfect world, I'd like to see ipfix support anonymization,
>but I'm not sure what the right approach to suggest is.  And I'm
>not sure that I really like the idea that by having a 'MUST support
>anonymization", that every vendor will go off an implement an ad-hoc
>anonymization scheme.
>
>-- david
>
>--

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)