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

[Paul Wilkins]

I would regard this as AGs best ambit claim. There's nothing in the bill to
indicate the exemptions of 187A4 are to be given effect piecemeal. The bill
is what it is, and obviously it behooves the AG to judge their powers in
their own best interests. We're very fortunate they didn't end up with the
power to define the metadata.

(I'm not a lawyer. This is not expert opinion)

Paul Wilkins

On 12 July 2015 at 14:55, Andrew Yager <andrew at rwts.com.au> wrote:

> 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
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150713/7f0bd6de/attachment.html>