[LINK] Resilient Broadband Network needed for Australia

[Glen Turner]

Kim Holburn wrote:

> I can't see how this would stop peer to peer VOIP connections like skype 
> or direct IP to IP connections like iCHAT or other softphones.

It doesn't.  It comes back the the definition of a "service".

If the service provider is providing a telephony service (either PSTN or
VoIP) then they need to provide telephony interception and the warrant
states phone numbers.

If the service provider is providing an IP service then they need to
provide IP packet interception for a customer's link and the warrant
states an IP address.

So if the intercepting agencies want to intercept a Skype call, they
need to go to the trouble of working out one of the IP address endpoints.
Depending upon the protocols involved, determining an IP address which
a future call will be placed on may not be possible. But that is the
requestor's problem, not the ISP's problem.

The interception agencies also bite themselves by their secrecy.
They don't want the service provider to know where their are, so the
interception agency needs to provide the tail from the service provider's
point of interception to whereever the agency is.  That works well for
telephony interception.  For data interception you can imagine the
response of an agency that suddenly realises it has to provision a
10Gbps inter-state link into a POP.

In fact, data interception is actually a poor way of collecting evidence.
Even for a Skype call, simply dropping a traditional bug in the chassis
of the PC returns much, much more data with much less risk of the
evidence being challenged.  For e-mail, getting a warrant for the
user's e-mail spool is more useful than finding e-mails via a data
interception warrant, as you get all the historical e-mails as well.


> How many audio calls are really going to bother your QoS (assuming your 
> calls are limited to networks that honour your QoS)?  Maybe video calls 
> might make a dent, or internet radio and TV perhaps or even youtube.

The issue is preventing misuse. Take a worm which sends data to random
IP addresses at voice priority (eg, a modified SQL Slammer). You want
to discard that traffic. The simplest way to do that is to ensure that
all traffic in the voice QoS class has a matching call establishment
signaling and to place some limit on the number of calls from a
phone or trunk.  That's the job of a SIP session border controller.

If you don't do this policing then the worm will deny service to
the voice QoS class.  Whereas we want the opposite -- for the
voice QoS class to remain working even though a worm is hammering
the best effort class.

That's the real job of QoS -- to keep a service running under
adverse congestion conditions. That congestion can arise from
over-subscription of a link (such as the undersea links to the
USA, which cost so much that the "bandwidth is unlimited so QoS
is unnecessary" argument doesn't fly), from denial of service
attempts, or from unfortunate routing changes (such as a few
1.2Gbps links failing, leaving the old 155Mbps link suddenly
carrying all of the load).

-- 
  Glen Turner