[AusNOG] Effect of Data Retention regime on smaller ISPs

Paul Wilkins paulwilkins369 at gmail.com
Sat Mar 7 13:28:36 EST 2015


John,
Do I detect a rebuke? I'm happy to agree to disagree. If you have an
alternate reading of the legislation, I'd welcome rational argument.

I claim #3 is contentious, having read the legislation, and the proposed
bill. I don't see where anyone can claim it's not contentious, where the
metadata is still before the Expert Group, and where Labour will still need
to sign off on whatever is finally proposed. Claiming anything is settled
at this stage only helps supports the passage of this bill, while areas of
uncertainty suggests the bill's not ready to be put to the Parliament.
Sober consideration of what is proposed hopefully can avoid the worst of
the foreseeable nonsense.

3. Every time a connection is made to your servers you need to log the IP
address and timestamp and be able to search by that.

I don't think this is true. I doubt they'll want every NTP or DNS lookup
logged. Hopefully it will depend what the Metadata Expert Group recommends.
The government would be foolish to push the bill through without their
endorsement.

Also I doubt data retention applies to content providers, as opposed to
internet service providers. To my reading, content providers are outside
the scope of the Broadcasting Services Act 1992, and so outside the scope
of the data retention bill. However, ultimately, the Communications Access
Co-ordinator, and/or the Minister, may ultimately be delegated the power to
declare a provider to be an internet service provider, or not.

(ianal)

Paul Wilkins


On 6 March 2015 at 22:28, John Lindsay <johnslindsay at mac.com> wrote:

> Says you Paul.
>
> I'm just taking the headings from the draft bill.
>
> Oh, and a bunch of years running big ISPs and meeting with the people who
> care about this stuff.
>
> If you run servers in Australia be prepared for #3. If not, be prepared
> for some seriously sad stuff to go down.
>
> John Lindsay
>
> On 6 Mar 2015, at 9:11 pm, Paul Wilkins <paulwilkins369 at gmail.com> wrote:
>
> John,
> Agree with all but this one:
>
> 3. Every time a connection is made to your servers you need to log the IP
> address and timestamp and be able to search by that.
>
> This is contentious. Depends on how they draft the bill.
>
> Paul Wilkins
>
> On 6 March 2015 at 19:33, John Lindsay <johnslindsay at mac.com> wrote:
>
>> Let’s think about this rationally.
>>
>> The categories covered by the bill are:
>>
>> * Characteristics of a subscriber of a relevant service
>> * Characteristics of an account, telecommunications device or other
>> relevant service relating to a relevant service
>> * The source of a communication
>> * The destination of a communication
>> * The date, time and duration of a communication, or of its connection to
>> a carriage service
>> * The type of a communication and relevant service used in connection
>> with a communication
>> * The location of equipment or a line used in connection with a
>> communication
>>
>> So you are going to ned to be able to answer the following questions:
>>
>> 1. Given the “identity" of a subscriber (some combination of name,
>> address, date of birth, drivers license number) what services do they have
>> with you? Your Billing System should be able to find this.
>>
>> 2. Given an IP address and a timestamp which subscriber had it
>> allocated?  You’re going to have to answer #1 for them too.
>>
>> 3. Every time a connection is made to your servers you need to log the IP
>> address and timestamp and be able to search by that.
>>
>> 4. When you provide a “fixed” service you need to know the address it is
>> delivered to.
>>
>> 5. When you provide a “mobile” (not fixed, perhaps wireless, who knows?)
>> service you need to know where the user is within reason. Don’t waste our
>> time with “what if they have a high gain antenna?” You know the location of
>> your tower and that’s a good start.
>>
>> Beyond that? Well requirements are always subject to scope creep until
>> the requirements exceed the laws of physics.
>>
>> But if you can’t manage at least the stuff above you’re going to be in a
>> world of pain.
>>
>> By world of pain I mean at risk of being forced to shut down. You can
>> assume the press will treat it as you aiding and abetting (insert class of
>> scary people).
>>
>> Cheers,
>>
>> John Lindsay
>>
>> On 3 Mar 2015, at 5:38 pm, Skeeve Stevens <
>> skeeve+ausnog at eintellegonetworks.com> wrote:
>>
>> Hey Justin - and others.
>>
>> As soon as we actually know what we're supposed to be doing, I will be
>> doing my best to put something together for the smaller ISPs to help them
>> deal with this... we just need to know what the requirements will be...
>>  what will be collected, what needs to be summarised, if it needs to be
>> encrypted, and how it needs to be stored.
>>
>> At the moment I am thinking that AWS Glacier will be one of the cheapest
>> places to store elastic data as its recovery time will be in hours.  But it
>> depends on the required information access time is... and what kinds of
>> requests they will make and how to extract a specific piece of data. If it
>> needs to be in a DB format for querying, I don't see how we're going to be
>> able to encrypt it easily.
>>
>> It is all a blur until we know the answers to a lot of these questions.
>>
>>
>> ...Skeeve
>>
>> *Skeeve Stevens - Founder & Chief Network Architect*
>> eintellego Networks Pty Ltd
>> Email: skeeve at eintellegonetworks.com
>> Cell +61 (0)414 753 383 ; Skype: skeeve
>> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile
>> <https://expert360.com/profile/d54a9>
>>
>>
>> On Tue, Mar 3, 2015 at 12:30 PM, Justin Clacherty <justin at redfish.com.au>
>> wrote:
>>
>>> Hi,
>>>
>>> Is anyone working for one of the smaller ISPs willing to help us (Future
>>> Wise) understand how the data retention laws may effect them in
>>> comparison to the larger players?
>>>
>>> Reply off list.
>>>
>>> Cheers,
>>> Justin.
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>> _______________________________________________
>> 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/20150307/28f9e3de/attachment.html>


More information about the AusNOG mailing list