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

[Paul Wilkins]

Unless the legislation draws a distinction between PSTN and packet switched
networks, it's hard to see how destination phone numbers can  be required,
without making a similar requirement for IP. As to whether destination IPs
are required to be captured, I prefer to not listen to what's been said in
the media, but to go from the text of the draft legislation.

As currently drafted, 187A2 creates a clear requirement for the destination
of a communication to be captured. As to what constitutes a "communication"
that is left open.

This requirement is qualified by 187A4, which is vague, and it's not at all
clear to what extent it limits the requirements of 187A2.

Given that 187A2 clearly stipulates destinations are required, and that
187A4 is vague and open to interpretation, there likely is the requirement,
per the current draft, to retain destination IPs.

Given the substantial costs of compliance, the lawyers are going to have a
lot of fun with this.

(IANAL)

Paul Wilkins

On 2 November 2014 07:21, Paul Julian <paul at oxygennetworks.com.au> wrote:

> There are a couple of bits in this which seem to contradict themselves, or
> what is claimed perhaps anyway.
>
> The particular one that is highlighted in everything is that you won't
> need to record destination IP address or URL, I think this is repeated
> about 400,000 times (slight exaggeration perhaps) but it's clear that they
> seem to believe that by not having to do this means that people can't claim
> that it's filtering or I don't know what really.
>
> Anyway, the interesting things I find are things such as:
>
> "This includes where a phone rings, but is not answered" so we will have
> to keep all attempts to connect to everything, even if that call is made
> but not answered we will have to keep those CDR's instead of tossing them.
>
> Whilst we don't have to keep destination IP address or URL we do have to
> identify what type of communication it was, so we have to record
> destination ports then at least to identify what type of service the user
> was using, or trying to use.
>
> On one hand they say we don't have to keep destination IP addresses or
> URL's, but then they say "For communications terminating on another
> provider’s network or service, the destination identifier should be
> retained"(3a), so I read that to say if one of your customers are talking
> to another one of your customers within your network then you don't have to
> keep destination IP's or URL's, but as soon as that customer goes outside
> of your network (communications terminating on another provider's network
> or service) which is surely most of what we all see, then you must keep the
> destination identifier, so if the destination identifier isn't an IP
> address or URL then what is it besides perhaps a phone number ?
>
> Luckily they clarify that a Wifi provider doesn't need to record an IMEI
> number, phew..... ;-)
>
> And lastly they cover their butts and leave the door open with this
> statement:
> "Any examples given throughout this document are illustrative only. An
> example, or lack of, does not indicate only data pertaining to the specific
> exemplified scenario should be retained"
>
> Personally I think if people really think that there isn't much work or
> cost involved in implementing some of this stuff then they need to think it
> through a bit more.
> Take for example NAT records, some people use NAT some people don't, but I
> think I am safe to say that most people do somewhere, for those who do you
> will need to have a device doing that NAT that is capable of logging the
> translated data set, private IP, public IP, who it was, where they were,
> ports used, and probably MAC address, for those running a substantial NAT
> network, who I know of some, this will represent a massive amount of data
> over two years.
>
> Regards
> Paul
>
> -----Original Message-----
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Narelle
> Sent: Friday, 31 October 2014 1:19 PM
> To: Matt Perkins
> Cc: ausnog at ausnog.net
> Subject: Re: [AusNOG] Metadata retention... it's now (almost) a thing
>
> [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>
> 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.
>
> 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
> (b) any current or historical account, service and/or device registered to
> the account
> (c) any current or historical permanent or transient identifier(s)
> allocated by the provider to an account, service and/or device
> (d) any current or historical supplementary identification, billing and
> payment, or contact information
> (e) current and historical account, service and/or device status
> (f) current and historical information about the usage of the account,
> service and/or device 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.
> 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
> (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.
> 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
> (b) the time and date of the connection to and disconnection from the
> service 5. Information necessary to identify the type of communication:
> (a) the type of service used
> (b) service features used by or enabled for the communication 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
> (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.
> 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.
>
> _______________________________________________
> 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/20141102/e50c977b/attachment.html>