[AusNOG] Effect of Data Retention regime on smaller ISPs

[John Lindsay]

As the technical advisor to a startup ISP who is using CG NAT the option of becoming Australia's first IPv6-only ISP is looking increasingly attractive. 

We live in remarkably silly times. 

John Lindsay

> On 6 Mar 2015, at 7:45 pm, Geoff Huston <gih902 at gmail.com> wrote:
> 
> So if the network uses a CGN then....?
> 
> Your points 2 and 3 seem to indicate that this is the CGN port binding log that needs to be retained.
> 
> But CableLabs looked at this a little while ago and their sums point out that for a network of 1 M customers behind a CGN structure, then the data volume coming out of the CGN system to support this volume of customers is 20Mbps per second on average, and the storage is 1Pb per month. (http://www.nanog.org/meetings/nanog54/presentations/Tuesday/GrundemannLT.pdf)
> 
> So let me understand this - over two years the requirement is to encrypt and store (and subsequently search) over 24Pb of CGN binding log data - and thats per 1M subscriber connections? And run accurate time? 
> 
> Gee, thats a world of pain all by itself.
> 
> Just as well we haven't run out of IPv4, so nobody has to run CGNs inside their access networks. Hang on...
> 
>  Geoff
> 
> 
> 
> 
> 
> 
>> On 6 Mar 2015, at 5:33 pm, 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 ; Expert360: Profile
>>> 
>>> 
>>> 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
>