[AusNOG] Data Retention Guidelines, and an explanation around DNS

[Andrew Yager]

Hi all,

Long e-mail; sorry. There is a lot of stuff circulating today around this
and I've finally had some time to digest.

As most of you are aware DRIPs are currently due on 13th August 2015. We,
like I'm sure many others, have been consulting with the CAC around
implementation guidelines and what we "should" do with our DRIPs.

We have been asking a number of specific questions around services we
offer, and early last week they provided some helpful guidance with regards
to interpreting the guidelines - and particularly how to interpret both the
"relevant services" and implementation steps.

I've been eager to distribute the information that they have been sharing;
but had not had an opportunity to parse the last e-mail I received which
actually gave me permission to circulate this material. They have provided
a Data Retention Implementation Flow Chart which I have attached. In
addition, the CAC generally provides four other documents "Data Retention
Overview May 2015" which is available on the AGD website, "Data Retention
Guidelines for Service Providers - v1.0 - May 2015" which seems to be only
available on request but is "helpful" in general terms, "Data Retention
Industry FAQ - v1.0 - May 2015" which outlines some of the types of data
required to collect in a general fashion and a template for completing a
DRIP which follows a similar form to the standard Interception Plan
document that carriers are required to complete. These last four documents
should be freely and easily available to C/CSPs who email cac at ag.gov.au;
but I'm not clear on whether we are allowed to generally distribute these.

I'm copying-pasting-verbosely; so please don't shoot the messenger; but
also feel free to discuss on-list.

Thanks for the e-mail querying DNS requests in relation to data retention.
>
> More than happy to work through questions as they come up. I’ve also
> attached a flow chart which we are hoping to distribute more broadly around
> industry. The flow-chart intends to guide providers about the order of
> applying the relevant provisions and where elements should be considered
> separately, rather than together.
>
> For DNS our view is that, where the relevant service in question is an *internet
> access service*, the internet access service provider does not have to
> keep any DNS information because the DNS server is a ‘destination on the
> internet’ and retaining that information would reveal browsing history. So
> DNS for ISPs is excluded.
>
> Where the relevant service in question is a *DNS server* operated by a
> C/CSP the analysis is different. Rather than relying on 187A(4) exclusions,
> the better reading is that a DNS server is not a ‘relevant service’ because
> under 187A(3) it does not ‘carry communications’ or ‘enable communications
> to be carried’. While DNS is certainly convenient to the operation of other
> services that do carry or enable carriage, the meaning of ‘relevant
> service’ is not unlimited. This reading is also consistent with an
> abundance of extrinsic material explaining that any information that
> reveals ‘browsing history’ is excluded from obligations.
>
> By way of example in terms of the attached flow-chart, take a CSP that
> offers an internet access service, a VoIP service and a DNS server. The CSP
> passes step one of the chart by virtue of being a CSP, and passes step two
> because of either of the services it offers. It would then pick a service
> for step three—take the internet access service. In step four it would
> consider the application of ‘session’ to that relevant service. In this
> case the session would be the assignment of a private-IP to the customer.
> It would then apply the data set to that definition of session for step six
> – i.e. when did the session begin and end, what identifiers were allocated
> during the session etc. Then, because it is an internet access service, it
> would apply the exclusion to remove all ‘destination’ information,
> including DNS and IP addresses etc.
>
> The answer to step seven is ‘yes’ because of the VoIP service is another
> relevant service that needs to be considered. The process would then
> repeat. For VoIP, each ‘session’ would be each call scenario rather than
> each packet. The data set would be applied to each call, and would include
> source and destination information for those calls as well as timestamps
> etc. The ‘destination’ exclusion does not apply to a VoIP service, so the
> destination information would not be carved out. The CSP does not offer any
> more relevant services because the DNS server or its internal corporate
> network etc are not ‘relevant’. The CSP could the begin completing its DRIP.
>
> We intend to make both the exclusion of DNS and the operation of the
> flow-chart clear in the next version of the guidance materials. In the
> meantime you are more than welcome to distribute to your colleagues.


This matches well with the advice we are giving to our customers now
regarding the creation of DRIPs to submit. This bit is "our" (read Real
World's) advice to our staff and customers and so if you so feel that you
must I'll accept flaming criticism here.


> *1. Identify if your business is required to retain data*If you believe
> you are not required to retain data, you should start this process by
> contacting the Communications Access Co-ordinator (cac at ag.gov.au or 02
> 6141 2884), outlining your business and seeking clarification on whether
> you are covered by this legislation.
>
> *2. Identify the relevant services your business provides*This sounds
> obvious, but for a number of our service providers this may pose a
> challenge, as it has for us. One of the "good" things about an elastic
> business model is that you can be flexible to meet your customer needs;
> however the legislation and implementation are not geared towards
> businesses that operate under this model.
> *It is important to note that your data retention obligations will be
> considered per "service" you provide.*
> For example:
> Our list of covered products includes:
>
>    - [cut short because you don't all care]
>
> Our obligations are only considered on the basis of these named services.
>
> *3. Identify your customers*It's important you identify your customers
> for each of these services. Meta Data Retention is to be retained per
> location. The AGD have indicated to us that they intend to view a single
> corporation as a "customer", so for example if you provide a private WAN
> service to a business with an internet gateway your retention obligations
> would likely only apply to the point where the traffic egresses to the
> internet.
> You will need to retain details identified in the data retention matrix
> for each customer for *two years after their service is terminated.*
>
> *4. Identify any excluded services*Some services, such as Café Free Wifi
> are explicitly excluded from the legislation.
>
> *5. Identify what data you actually need to collect*This is where life
> gets difficult. We have attached the list of data that is contained in the
> legislation that makes up the "data set". An example would be that you
> would need to collect and retain customer data for a period of two years.
> You would need to obtain session start/stop details on an internet access
> service. You would need to obtain logs on an email service you run for your
> clients. You would need to retain call logs for any telephony service you
> provide. You would need to retain any data with regards to diversions or
> call forwards you may put in place for a customer as a service.
> Make sure you have a plan for each service. Even if the service is not
> delivered on your infrastructure (i.e. you are a Virtual Service Provider)
> you *must still have a plan to retain this data*. Ultimately, the law
> holds you, as a service provider, responsible for the retention of this
> data. For a number of our customers this will mean that you must work with
> us to meet your retention obligations.
> We have found this to be the greatest area of concern both internally and
> within the CSP community. Our general approach has been to try and
> determine the "spirit" of the legislation with regards to the data
> retention policy and then consult with the Communications Access
> Co-ordinator at the Attorney General's Department around the specifics of
> our plans. As we move through this process we remain happy to discuss this
> individually with service providers as they consider their obligations.
>
> *6. Identify what data you already are retaining*For a number of our
> customers, the majority of data will already be obtained in some form or
> other. This is a good starting point for your retention obligations. *Note
> that the legislation indicates that it is illegal to actively reduce the
> data you are retaining where it might be related to your Data Retention
> obligations.*
>
> *7. Identify what data you require a third party provider to collect on
> your behalf*Where you are not in a position to collect the data yourself,
> or rely on a third party provider, such as Real World, to collect this data
> for you. Once you have done this, make contact with the third party
> provider outlining what you may require them to collect on your behalf. The
> provider may then give you some specific advise.
>
> *8. Identify how you intend to store your data*The Meta Data Retention
> Legislation requires you to store your data encrypted. This is probably not
> practical in a lot of situations. Ensure you have a plan for how you will
> encrypt data, and, for information that can not be encrypted ensure you
> have a plan on how you will ensure the security of this data.
>
> *9. Submit a Data Retention Implementation Plan (DRIP)*Real World or the
> CAC will provide you with a draft template for your DRIP.
> This is perhaps the most important component of the process. A DRIP allows
> a provider up to 18 months to become compliant with any data retention
> obligations they have for services. It is also an important legal document,
> as it outlines how you are intending to be compliant with the legislation.
> The CAC will review these documents and advise if they "approve" of both
> your implementation plan, and your plans for retention.
> We would recommend that, at a minimum, your DRIP identifies:
>
>    - What data you intend to collect for each of your services
>
>
>    - How you intend to store the data
>
>
>    - What data you currently collect
>
>
>    - How long you store the data you currently collect
>
>
>    - When you intend to start collecting the required data that you do
>    not currently collect
>
>
>    - When you intend to start storing the data for the minimum 2 years
>    once it is collected
>
>
>    - How you intend to encrypt the data, and if it is not encrypted how
>    you intend to store it
>
> The Communications Access Co-ordinator will review your DRIP and then
> provide you notice as to whether or not they find your plan acceptable. In
> the event that there is ever a dispute with an enforcement agency or ACMA,
> an approved DRIP would be vital to any defence of your position.


We can still live in hope of an "extension" to submit our DRIPs, but to be
honest I think if we "think" we're going to get one we are actually
dreaming. That doesn't mean that we shouldn't ask/lobby/assert our need for
this, but I think it's unlikely.

So at the end of this, hopefully it helps some other providers out there.
I'm trying a "let's not stick my head in the sand and hope it goes away"
approach. And with that said, on a personal note, I'm quite happy to enter
into constructive discussions about this; and I know that IA and CA are
both also keep to help get through the FUD to a sensible position where
people can actually deal with this.

Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150712/567f7c0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Data Retention Implementation Flow Chart - June 2015.pdf
Type: application/pdf
Size: 45832 bytes
Desc: not available
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150712/567f7c0c/attachment.pdf>