[AusNOG] Metadata retention... it's now (almost) a thing

Joseph Goldman joe at apcs.com.au
Mon Nov 3 08:20:15 EST 2014 

Well, with current requests for information that I have received before 
(from AFP exclusively), that requests for information on who was using 
what IP at what time, it wasn't the fact that we handed over the raw 
logs, as they would just come with a customer identifier that means 
nothing to law enforcement, instead we figure out from logs what 
customer it was and provide their actual account information, so its not 
the sake of the law enforcement see a list of customers using that IP 
over a big period of time.

I would imagine it wouldn't change much with the new laws - they are 
interested in the personal info related to the log, not the log itself. 
The only reason I could see them needing the raw logs is if it is 
required for evidence in prosecution (have had AFP agents fly in to pick 
up some form of evidence before from a colleague in a previous job).

On 03/11/14 07:37, David Beveridge wrote:
> An Example, for a PPPoE connection.,  See below inline
> As I stated before this is more complex for mobile phones, as they would
> also need to provide IMEI numbers and cell tower locations.
> With ADSL, all that stuff is relatively static.
>
> One thing is that it does lead to a lot of discovery.
> When they ask for who was using this IP address at a given time,
> they are also asking every other IP address used ever by that customer
> and the time periods for all those too.
>
> I am not a lawyer either, so if someone can point out how I have this
> wrong, I'd appreciate it.
>
> dave
>
> On Fri, Oct 31, 2014 at 12:18 PM, Narelle <narellec at gmail.com
> <mailto:narellec at gmail.com>> wrote:
>
>     [Provisor IANAL and I haven't gone through the legislation yet... N]
>
>     On Thu, Oct 30, 2014 at 3:40 PM, Matt Perkins <matt at spectrum.com.au
>     <mailto:matt at spectrum.com.au>> wrote:
>     > I would be interested to see paragraph 187A(4) of the act.  It seems to
>     > indicate that
>     >
>     > This item will only apply to the service provider operating the relevant
>     > service: So does that mean we need to know who chatted to who on facebook
>     > for example but facebook is the service provider so they would be the people
>     > that would need to get the info. Not the ISP. The ISP could not be expected
>     > to break an encryption do get the info.
>     >
>     > So im thinking a lot of this will be "who is the service provider" .  Is it
>     > skype, Is it facebook, Is it the guy providing the copper ?
>     >
>     > Matt.
>
>
>     Matt
>     in the discussion paper it says: "Nothing in this data set applies to
>     or requires the retention of destination web address identifiers, such
>     as destination IP addresses or URLs."
>
>     Thus given facebook is accessed via a "web address" it would be out
>     of scope.
>
>     Of course, by extension, if you want your activities to stay unlogged
>     or obfuscated, you change mac addresses, use other people's wifi, and
>     wrap things via http or some other vpn.
>
>     BUT
>
>     the paper also requires a LOT more than just radius logs.
>
> As for the stuff we're currently not already retaining, is mostly
> historic billing addresses.
> In the past when a customer changed address, we did not keep the old one.
>
>     It does apply to "all entities that provide communications services to
>     the public".
>     "Who will data retention apply to?
>     Data retention obligations, consistent with existing legal and
>     regulatory obligations, should be able to apply to all entities that
>     provide communications services available to the public in Australia.
>     Therefore, data retention obligations should not be limited to
>     licenced carriers but should also extend to any entity that provides
>     communications services to the Australian public."
>
>
>
>
>     Here is the full text of the "requirements" egs not included, but
>     copy attached.
>
>     B. Obligations for data retention—data set
>     The data set described in the following pages has been developed for
>     consultation with the telecommunications industry. It reflects the key
>     requirements of security and law enforcement agencies, is designed to
>     be technologically-neutral, and is broadly consistent with the
>     categories of data set out in Article 5 of the former Directive
>     2006/24/EC; and ETSI Standards TS 102 656 (V1.2.1) Retained Data:
>     Requirements of Law Enforcement Agencies for handling Retained Data,
>     and TS 102 657 (V1.15.1) Retained Data Handling: Handover interface
>     for the request and delivery of retained data.
>     The explanatory information in section B provides further information
>     including examples of how these requirements would apply to particular
>     technologies and services.
>     Nothing in this data set applies to or requires the retention of
>     destination web address identifiers, such as destination IP addresses
>     or URLs.
>
>     1. Information necessary to identify, and supplementary information
>     regarding, the subscriber of a service:
>     (a) the current and historical name and address of the subscriber of
>     the account, service and/or device
>
> Joe Blocks, 123 Example Street, Townville, (07) 1234 5678, 0432 987 654 etc
>
>     (b) any current or historical account, service and/or device
>     registered to the account
>
> PPPoE over ADSL
>
>     (c) any current or historical permanent or transient identifier(s)
>     allocated by the provider to an account, service and/or device
>
> Extract from RADIUS log (all IP address ever allocated to customer)
>
>     (d) any current or historical supplementary identification, billing
>     and payment, or contact information
>
> Extract from sales history
>
>     (e) current and historical account, service and/or device status
>
> Extract from RADIUS log
>
>     (f) current and historical information about the usage of the account,
>     service and/or device
>
> Extract from RADIUS Log.
>
>     2. Information necessary to trace and identify the source of a
>     communication (including unsuccessful or untariffed communications):
>     (a) the identifier(s) allocated to an account, service and/or device
>     from which a communication is sent or attempted to be sent.
>
> PPPoE UserName
>
>     3. Information necessary to identify the destination of a
>     communication (including unsuccessful or untariffed communications):
>     (a) the identifier(s) allocated to an account, service and/or device
>     to which a communication is sent or attempted to be sent
>
> NAS IP Address, from RADIUS log
>
>     (b) in cases where a communication is forwarded, routed or
>     transferred, the identifier(s) allocated to an account, service and/or
>     device to which a communication is forwarded etc, or attempted to be
>     forwarded etc.
>
> N/A
>
>     4. Information necessary to accurately identify the date, time of
>     start and end or duration of a communication (including unsuccessful
>     or untarriffed communications)
>     (a) the time and date of the start and end of the communication, or
>     attempted communication
>
> AcctStartTime, AcctStopTime from RADIUS log.
>
>     (b) the time and date of the connection to and disconnection from
>     the service
>
> AcctStopTime from RADIUS Log
>
>     5. Information necessary to identify the type of communication:
>     (a) the type of service used
>
> PPPoE over ADSL
>
>     (b) service features used by or enabled for the communication
>
> TCP/IP
>
>     6. Information necessary to identify subscribers communication
>     equipment or what purports to be their equipment:
>     (a) the identifier(s)of the line, device and equipment connected to
>     the service from which a communication is sent or attempted to be sent
>
> 192.0.0.1
>
>     (b) the identifier(s) of the line, device and equipment connected to
>     the service to which a communication is sent, including a device or
>     equipment to which a communication is forwarded or transferred.
>
> dslam5.state.isp.net.au <http://dslam5.state.isp.net.au>
>
>     7. Information necessary to identify the location of communications
>     equipment:
>     (a) the location of the device or equipment used to send or receive a
>     communication, based on the device’s or equipment’s connection to the
>     service at the start and end of a communication or session.
>
> Some Data Center belongs to ISP.  (cell tower for mobiles)
>
>
>     _______________________________________________
>     AusNOG mailing list
>     AusNOG at lists.ausnog.net <mailto: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
>

More information about the AusNOG mailing list