<?xml version="1.0" standalone="no"?>
                    <!DOCTYPE div SYSTEM "/www/backend/www-xml-443/dtd/caidaML.dtd">
                    <!-- do NOT ERASE the DOCTYPE declaration! --><div>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>URL:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<a href="http://portal.acm.org/citation.cfm?id=1111322.1111330">http://portal.acm.org/citation.cfm?id=1111322.1111330</a><br/>
<a href="http://www.icir.org/enterprise-tracing/devil-ccr-jan06.pdf">http://www.icir.org/enterprise-tracing/devil-ccr-jan06.pdf</a>
</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>ENTRY DATE:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
2008-06-16


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>ABSTRACT:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
Releasing network measurement data---including packet traces---to the
research community is a virtuous activity that promotes solid
research. However, in practice, releasing anonymized packet traces for
public use entails many more vexing considerations than just the usual
notion of how to scramble IP addresses to preserve privacy. Publishing
traces requires carefully balancing the security needs of the
organization providing the trace with the research usefulness of the
anonymized trace. In this paper we recount our experiences in (i)
securing permission from a large site to release packet header traces of
the site's internal traffic, (ii) implementing the corresponding
anonymization policy, and (iii) validating its correctness. We present a
general tool, tcpmkpub, for anonymizing traces, discuss the process used
to determine the particular anonymization policy, and describe the use
of metadata accompanying the traces to provide insight into features
that have been obfuscated by anonymization
 




</font>
  </td>
</tr>
</div>

