Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] /. ITU Approves Deep Packet Inspection

Petter Ericson pettter at acc.umu.se
Wed Dec 5 11:24:30 PST 2012


There are a number of places where data security is mentioned, but not
very extensively. A particularly worrying requirement is

R-6.2.1/2: The DPI signatures library is required to be securely
maintained and not visible to unauthorized users.

I.e. ordinary users MUST not be able to see the rules that are applied
during the DPI. Obviously this may be overridden through some other way.
In particular, governments could mandate that DPI rules are published by
any entity applying DPI at some point.

Apart from this, most requirements refer to national guidelines for data
security and retention. For EU countries this means the Data Protection
and Data Retention Directives and national implementations of same.
Other countries obviously have other rules.

As you say, it is a very technical document for the most part, and does
not really deal with all the implications of DPI. Thankfully, it also
does nothing to mandate this kind of equipment in any way.

However, thinking further, I could definitely see how _later_ standards
could refer to Y.2770 to mandate a DPI-FE (functional entity) at some
specific point, or, even more likely, that governments could mandate
such an entity for ISPs operating within their jurisdiction. No more
need for a state-run ISP in order to keep shit under control, no, hire
some large telco to run your networks, and mandate use of Y.2770
compatible DPI equipment instead.

That, I think, is the main danger posed by this document.

TL;DR: Standards for DPI makes it easier for bad governments to
outsource ISP (including DPI) onto external large telcos. E.g. 
Saudi + TeliaSonera.

Best

/P

On 05 December, 2012 - Fenwick Mckelvey wrote:

> Hi all,
> To Nick's point re:what's the problem. I think part of the problem
> with the ITU talking about DPI is that it is a case of forum-shifting.
> The ITU is a less accountable body than a government. The challenge is
> that on a quick skim of this document I find it highly technical in
> nature and lacking in any discussion of privacy or data retention
> issues. How should we regulate these technologies? Can their
> regulation be left to technology firms? It'd be of note to compare the
> Canadian CRTC's own debates over traffic management practices
> (http://www.michaelgeist.ca/content/view/6021/125/).
> 
> I'd also point to the great work Chris Parsons
> (http://www.christopher-parsons.com/blog/) has done on this issue,
> especially: http://www.deeppacketinspection.ca/.
> 
> Happy to chat more re: framing matters. It's an interest event and I
> am really appreciating all the comments here as always.
> 
> Best,
> Fen
> 
> On Wed, Dec 5, 2012 at 10:34 AM, Petter Ericson <pettter at acc.umu.se> wrote:
> > Reading the draft document provided by Asher, I find nowhere any
> > reference to this being a required activity for any ISP. Instead, it
> > talks mainly about how data flows between generalised entities (think
> > "devices").
> >
> > So no, if ITU received a more governing role of the internet, that would
> > not _in itself_ lead to Y.2770 being a "required standard" to implement
> > for all ISPs (and I have no idea how this would happen anyway, given it
> > doesn't concern itself with specififying any actions for ISPs).
> >
> > There are legitimate uses for DPI, though the examples cited in the
> > draft seems to be more about limiting BitTorrent traffic...
> >
> > So basically, the standard is probably going to do mostly these things:
> > a) DPI equipment manufacturers can claim to be "standards compliant"
> >    which is a selling point in some circumstances
> > b) DPI might get more widely accepted as a technique. It is up to us and
> >    other hackers to make sure that censorship and traffic discrimination
> >    is not.
> > c) It might be slightly more easy for surveillance tech to interoperate
> >    between manufacturers, given that the main point of the standard is
> >    to suggest everyone output data and accept rules in a standard way.
> >
> > To be frank, I have been trying to find out what the fuss has been about
> > regarding this standard and come up.. not blank, as it _is_ worrying
> > that ITU is spending time on this shit, but at least I haven't found
> > anything to inspire the absolutely massive shitstorm I have been seeing
> > in certain places (e.g. /.). Is it just because it's the ITU doing it
> > rather than, say, ISO or ANSI?
> >
> > Best
> >
> > /P
> >
> > On 05 December, 2012 - Nicholas Judd wrote:
> >
> >> Hi list, Nick from techPresident here. If I could tap into your hive-mind intelligence for a moment to help me be more precise about explaining why this is an issue, I would appreciate it ...
> >>
> >> Governments, intelligence organizations and assorted nogoodniks already use deep-packet inspection, so the declaration of a standard for DPI comes off as vaguely Orwellian but not news. I'm searching for a way to explain the privacy-advocate position on this is both accurately and concisely.
> >>
> >> The sense I get from CDT's blog post is that there are three reasons why this is more than just creepy in principle:
> >>
> >> 1. The standard outlines ways that, in the ITU's view, ISPs should structure their operations so that highly invasive surveillance can function;
> >> 2. Under current governance, this standard could be as widely ignored as the <blink> tag, but ISPs could be forced to comply if the ITU becomes a must-follow standards-making body for the Internet — meaning all traffic in every ITU member state, in this extreme example, would be vulnerable by design;
> >> 3. On principle, IETF and W3C don't address standards for surveillance, highlighting another way the ITU is ideologically removed from the way the Internet is now governed.
> >>
> >> Am I on target here?
> >>
> >> On Dec 5, 2012, at 12:41 PM, Cynthia Wong wrote:
> >>
> >> > The final version of the standard should show up here... eventually:
> >> >
> >> > http://www.itu.int/en/ITU-T/publications/Pages/latest.aspx
> >> >
> >> > http://www.itu.int/dms_pages/itu-t/rec/T-REC-RSS.xml
> >> >
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: liberationtech-bounces at lists.stanford.edu [mailto:liberationtech-bounces at lists.stanford.edu] On Behalf Of Asher Wolf
> >> > Sent: Wednesday, December 05, 2012 7:38 AM
> >> > To: liberationtech at lists.stanford.edu
> >> > Subject: Re: [liberationtech] /. ITU Approves Deep Packet Inspection
> >> >
> >> > From http://committee.tta.or.kr :
> >> > Revision of Y.2770 Requirements for #DPI in Next Generation Networks http://bit.ly/Yx0Sya (via @BetweenMyths)
> >> >
> >> > On 5/12/12 9:25 PM, Andre Rebentisch wrote:
> >> >> Am 05.12.2012 10:27, schrieb Eugen Leitl:
> >> >>> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-pack
> >> >>> et-inspection
> >> >>>
> >> >>>
> >> >>> ITU Approves Deep Packet Inspection
> >> >>>
> >> >>> Posted by Soulskill on Tuesday December 04, @08:19PM
> >> >>>
> >> >>> from the inspect-my-encryption-all-you'd-like dept.
> >> >>>
> >> >>> dsinc sends this quote from Techdirt about the International
> >> >>> Telecommunications Union's ongoing conference in Dubai that will have
> >> >>> an effect on the internet everywhere:
> >> >> The WCIT is a "diplomatic conference" for the rules governing the ITU,
> >> >> the ITRs. It seems wrong to mix that with ongoing specific
> >> >> standardisation work of the ITU.
> >> >>
> >> >> Anyway, interesting discussions over at circleid.com:
> >> >> http://www.circleid.com/posts/20121203_wcit_off_to_a_flying_start/
> >> >> Apparently ITU fellows are disgruntled that they cannot control the
> >> >> media coverage and complain about all the "misinformation".
> >> >>
> >> >> Best,
> >> >> André
> >> >>
> >> >>
> >> >> --
> >> >> Unsubscribe, change to digest, or change password at:
> >> >> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> >> >
> >> > --
> >> > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
> >> > --
> >> > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
> >>
> >> --
> >> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
> >
> > --
> > Petter Ericson (pettter at acc.umu.se)
> >
> > Telecomix Sleeper Jellyfish
> > --
> > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> 
> 
> -- 
> ---------------------------------------------------------------------------------------------------
> I try to respond to emails at 9:30 and 1:30pm daily (PST).
> ---------------------------------------------------------------------------------------------------
> 
> Fenwick McKelvey
> Postdoctoral Fellow
> Visiting Scholar, University of Washington
> http://fenwickmckelvey.com
> --
> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

-- 
Petter Ericson (pettter at acc.umu.se)

Telecomix Sleeper Jellyfish



More information about the liberationtech mailing list