Subject: RE: [ipfix-eval] Some comments on the evaluation team draft

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 14 Nov 2002 08:20:51 -0800

Hello Benoit,
 
some answers...

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]]
Sent: Thursday, November 14, 2002 10:53 AM
To: [email-masked]
Subject: [ipfix-eval] Some comments on the evaluation team draft

All,

I have 2 coments regarding the following draft
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
<http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt

4.5 Time Synchronization  (5.5) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T

In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt
<http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt>
, I wrote

3.4.5 Time Synchronization (5.5) 

Total Compliance. 
The export packet header contains the UTC time of the export packet 
generation. This header also contains the router sysUpTime at the 
time of the export packet generation. The UTC time the router booted 
can therefore be deduced. The flow records contain the flow start 
and flow end sysUpTime, so that the NetFlow collector can deduce the 
flow start and flow end UTC time. 

5.7 Anonymization  (6.7) 

LFAP: E     CRANE: E     IPDR: E     NetFlow: E     Diameter: E
In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt
<http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt>
, I wrote

3.5.7 Anonymization (6.6) 
    
   "The exporting process MAY be capable of anonymizing source and 
   destination IP addresses in flow data before exporting them."
   Total Compliance. 

You can export the prefix is you want to and not the specific source and
destination IP addresses. 
 
From my point of view exporting only the prefix is not considered
anonymization. I'm not sure this got into the recent requirements draft, but
was the conclusion of some discussions that I actually think (but not
posisitive) you were copied.  I should put that as a open item....

I would appreciate if those two points above could be changed.

BTW, maybe I misunderstood the idea of the evaluation team, but from
http://ipfix.doit.wisc.edu/archive/1000.html
<http://ipfix.doit.wisc.edu/archive/1000.html> 

3) Evaluation Team met by teleconference for an hour on Wed 26 June

   The team was strongly influenced by the MIDCOM WG's recent

   evaluation effort; the IPFIX process will be similar.

   a) The team will publish a 'Protocol Advocacy' draft, to be used

      by the Protocol Advocates in making their submissions to the

      Evaluation team.

   b) They will also publish a 'call for IPFIX protocol submissions,'

      most probably via the IPFIX list, referring to a web page on

      the IPFIX web site.  The call for submissions will set out

      preconditions (e.g. 'must be documented in an Internet Draft

      or RFC'), as discussed previously.

   c) Once all the submissions are in, the team will publish them,

      and call for comments about them on the IPFIX list.

      In addition, the team will read all the drafts and form their

      own opionions of them.

   d) The team will publish an 'Evaluation' draft, using the same

      outline as the Protocol Advocacy drafts; this will conclude

      with a recommendation on which protocol most nearly meets the

      IPFIX requirements.

   e) The Evaluation draft will be discussed on the IPFIX list, 

      until we reach WG consensus.

From above, you can read "this will conclude with a recommendation on which
protocol most nearly meets the IPFIX requirements."
And it seems that we miss that part in
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
<http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
> . 
 
that's because the draft will still got through revisions after the
advocates have a chance to comment on the items they find relevant (just
like you did), and also after the open requirements that are relevant to the
evaluation are closed (e.g. reliability). Only after that we will issue a
final recommendation
 
regards,
 
Reinaldo
 
The only exception was  in the initial draft from Simon Leinen. But the
"conclusion" section was removed in the second version of his draft.

Regards, Benoit.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 15 Nov 2002 07:45:55 -0800

Benoit,
 
you can use other fields, such as IP Proto, TCP Ports, packet size, etc,
etc..There are several sites where you can download public data from
probes/exporters where the IP addresses are maked by a one-way function but
the other fields can be seen. See for instance
http://tracer.csl.sony.co.jp/mawi/guideline.txt
<http://tracer.csl.sony.co.jp/mawi/guideline.txt> 
 
"Protecting User Privacy

There are 2 issues regarding user privacy.

1. Removing user data:
Leave only protocol headers and remove protocol
payload which could contain user data.
2. Providing anonymity:
Scramble addresses which could be used to identify a
user.
"
 
regards,
 
Reinaldo

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]]
Sent: Friday, November 15, 2002 8:51 AM
To: Simon Leinen
Cc: [email-masked]; [email-masked]
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft

Simon,

On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise
<mailto:[email-masked]> <[email-masked]> said:

5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E

NetFlow: E     Diameter: E

In my draft

            "The exporting process MAY be capable of anonymizing

source and

       _Total Compliance. _

You can export the prefix is you want to and not the specific source

and destination IP addresses.

I would call that "(router-based) aggregation" rather than

"anonymization".  With anonymization you somehow expect to maintain

granularity, but want some kind of (non-reversible?) scrambling to

cover up privacy-sensitive parts of the traffic data, such as IP

addresses.

So what's the point to export something that you can't use?

Benoit.

Don't take this requirement too seriously.  None of the candidates has

addressed this, and I think as a requirement it hasn't been thought

through too well.  It doesn't really reflect current practice, and

personally I think this is better done on the collector side.