<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Discuss away, were all riveted with antici......<br>
<br>
:) <br>
<br>
<div class="moz-cite-prefix">On 8/18/2014 7:52 PM, Anthony Orlando
via VoiceOps wrote:<br>
</div>
<blockquote
cite="mid:A36987BC-1458-4185-8A08-4CE854FF0991@yahoo.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div>All </div>
<div> I might have a solution that I'd like to talk to the group
about. It can not only detect but could use your switch API to
take action. Who's interested in discussing it!</div>
<div><br>
<br>
Sent from my iPhone</div>
<div><br>
On Aug 18, 2014, at 9:59 PM, Tim Jackson <<a
moz-do-not-send="true" href="mailto:jackson.tim@gmail.com">jackson.tim@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<p dir="ltr">I think Ryan's point here is getting data on
in-progress calls into it instead of completed calls..</p>
<p dir="ltr">AFAIK CPM basically watches the real time call
logs from the CFS, and only knows about calls once they
complete.</p>
<div class="gmail_quote">On Aug 18, 2014 6:04 PM, "Simon
Dredge" <<a moz-do-not-send="true"
href="mailto:Simon.Dredge@metaswitch.com">Simon.Dredge@metaswitch.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Heya, Ryan - It's SAS-like - But proactive analysis rather
than reactive analytics. It'll trigger immediately (in
real-time) on an anomaly, informing the operator that
action is required so they can take necessary action.<br>
<br>
Cheers,<br>
<br>
<br>
Simon.<br>
<br>
-----Original Message-----<br>
From: Ryan Delgrosso [mailto:<a moz-do-not-send="true"
href="mailto:ryandelgrosso@gmail.com">ryandelgrosso@gmail.com</a>]<br>
Sent: Monday, August 18, 2014 4:32 PM<br>
To: Simon Dredge<br>
Cc: <a moz-do-not-send="true"
href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>
Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...<br>
<br>
Simon,<br>
I think the gotcha with CPM in this scenario is its a
great tool for determining "this has happened" but not so
great for building a mitigation solution.<br>
<br>
Is CPM driven off of CDR's or off of the SAS datastream or
some other source?<br>
<br>
If its CDR driven you will be blind to this problem
because you wont be measuring calls that are rejected due
to lack of capacity(no cdr cut).<br>
If its driven off of SAS data you will get the
missed/incomplete call stats but at the cost of speed
(multiple orders of magnitude more data than CDR's)<br>
<br>
It would be interesting to hear if this perhaps uses a
different datasource. Perhaps there is a facility in
perimeta that informs this better than CFS data sources.<br>
<br>
-Ryan<br>
<br>
On 8/18/2014 3:36 PM, Simon Dredge wrote:<br>
> I know many meta-users like the new-ish call pattern
monitor. It uses weighted profiling benchmarking algos
similar to NBAD:<br>
><br>
> <a moz-do-not-send="true"
href="http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-"
target="_blank">http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-</a><br>
> Monitor.pdf<br>
><br>
> Cheers,<br>
><br>
><br>
> Simon.<br>
><br>
><br>
> -----Original Message-----<br>
> From: VoiceOps [mailto:<a moz-do-not-send="true"
href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a>]
On Behalf Of<br>
> Ryan Delgrosso<br>
> Sent: Monday, August 18, 2014 1:53 PM<br>
> To: ECG - Mark Lindsey<br>
> Cc: <a moz-do-not-send="true"
href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>
> Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones
...<br>
><br>
> I dunno that's a slippery slope. Im not a proponent
of putting management of your network services into
someone elses hands, especially things like this where the
service provider should have visibility into what they are
or are not admitting.<br>
><br>
> Agreed on your synopsis of call admission control,
the border should be able to make these decisions rapidly,
freeing up softswitch resources to actually serve
customers.<br>
><br>
> This sounds like good territory for an acme SPL
plugin, possibly in<br>
> conjunction with this enum extension<br>
> <a moz-do-not-send="true"
href="http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00"
target="_blank">http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00</a>
unfortunately i dont see a clear path for this in the TDM
world but my exposure there is limited. It would seem like
a good solution might be using ENUM (with source URI) to
build statistics centrally based on calling/called numbers
and then forcing the ENUM response once thresholds are hit
to illicit an appropriate decline message for flagged
invites with a retry-after interval allowing you to
effectively throttle specific call scenarios assuming your
origination carriers will behave correctly.<br>
><br>
> 2 of the examples we discussed previously were:<br>
><br>
> 1: Social media death star. Justin biebers (or anyone
else with millions of rabid followers) twitter account
(53.7M followers) gets hacked and attacker tweets "Call
this number for free tickets" or similar.<br>
><br>
> 2: T-DOS using stolen sip accounts effectively
turning other service providers into a death star. More
damage per source number (higher CPS than social media per
attacker but less distributed source). This one seems much
easier to create given the ease with which stolen sip
accounts can be acquired, and harder to mitigate if the
stolen accounts support callerID spoofing.<br>
><br>
> Both of these situations are exacerbated by LCR
resellers creating at times 10-20 invites from 1 due to
route advancing when the destination is truly congested,
which gets worse when the LCR resellers in turn have
resellers in route etc etc.<br>
><br>
> Of course any solution needs to have provisions for
conveying congestion control to the originating network so
they stop route advancing.<br>
><br>
><br>
> I think this has commercial viability for access
providers protecting<br>
> their customers business interests and for
implementers designing<br>
> solutions but perhaps not so much in a carrier to
carrier capacity<br>
> (beyond appropriate support of signaling congestion
control).<br>
><br>
><br>
> On 8/18/2014 12:48 PM, Mark R Lindsey wrote:<br>
>> Ryan, does it seem as though TDoS will be most
effectively addressed by the origination companies? i.e.,
the guys with the TDM trunks to the local tandems, such as
incumbents, Verizon, Level(3).<br>
>><br>
>> It seems to me that some use of statistics could
probably make reasonable guesses about whether a given
PSTN origination call is likely to be legitimate (for a
call from A to B). For example, I'll bet you could make a
good start looking at numbers and geographic areas:<br>
>><br>
>> -- Has telephone number A called to
telephone number B before? Or B->A ?<br>
>><br>
>> -- Has GeographicArea(A) called to telephone
number B before? Or GeographicArea(B) -> A?<br>
>><br>
>> The more you know about telephone numbers A and
B, the more you could guess about the likelihood that a
given call is legitimate.<br>
>><br>
>> And getting good at this should be a competitive
advantage, just as effective anti-spam is an advantage
elsewhere. Vendors that build the edge gear -- in
particular, the SBC and TDM SS7 gateway vendors -- should
be leading the way.<br>
>><br>
>> And wholesale carriers could take some advantage
and make it broadly available. For example, let's say
Verizon came along and said, "Here's a reason to port your
numbers from Level(3) to us: When you're under attack,
we're going to be smart about the ways we selectively
admit calls to your network."<br>
>><br>
>><br>
>><br>
>>>>> <a moz-do-not-send="true"
href="mailto:mark@ecg.co">mark@ecg.co</a> <a
moz-do-not-send="true" href="tel:%2B1-229-316-0013"
value="+12293160013">+1-229-316-0013</a> <a
moz-do-not-send="true" href="http://ecg.co/lindsey"
target="_blank">http://ecg.co/lindsey</a><br>
>> On Aug 18, 2014, at 13:52 , Ryan Delgrosso <<a
moz-do-not-send="true"
href="mailto:ryandelgrosso@gmail.com">ryandelgrosso@gmail.com</a>>
wrote:<br>
>><br>
>>> IP DDOS and TDOS are really two different
problems but yes we as ITSP's and CLECs living in the IP
space are absolutely susceptible to both.<br>
>>><br>
>>> Ive done a fair amount of research into both
of these topics and we have seen varying cases of both,
but usually IP DDOS steals the spotlight because the
numbers are bigger and the effects are usually more
widespread whereas a TDOS attack is rarely felt by anyone
that doesn't live in the affected region or isn't actively
trying to call the victim, and usually telcos keep these
issues pretty close to the chest.<br>
>>><br>
>>> I expect this sort of attack is going to
increase in magnitude in the coming 24-36 months as
attackers figure out how to wield it. Mark Collier gave a
very interesting talk at one of the CFCA events on this
topic, though the focus was on the enterprise victim, but
the lessons are really the same. There just arent really
any good tools to mitigate this sort of attack today,
especially at the carrier level.<br>
>>><br>
>>> -Ryan<br>
>>><br>
>>> On 8/18/2014 6:30 AM, Matt Yaklin wrote:<br>
>>>> It seems like almost every telephone
company can be hit like that<br>
>>>> except the ?largest?...<br>
>>>><br>
>>>> A denial of service attack by simply
calling so many times it fills<br>
>>>> up their main trunks.<br>
>>>><br>
>>>> And we saw how the large IP colo
providers handle this for<br>
>>>> customers who get dos'd. The amount of
bandwidth they have is<br>
>>>> staggering and they still cannot
guarantee you will stay up if a<br>
>>>> ?skilled? attacker wants you down. So you
keep throwing money at it<br>
>>>> until you are so well established online
that you look at your<br>
>>>> monthly bill and want to puke.<br>
>>>><br>
>>>> matt<br>
>>>><br>
>>>> On Mon, 18 Aug 2014, Frank Bulk wrote:<br>
>>>><br>
>>>>> <a moz-do-not-send="true"
href="http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-"
target="_blank">http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-</a><br>
>>>>> Clay-County-271463051.html?ref=051<br>
>>>>><br>
>>>>> Painful issue for Big River
Telephone!<br>
>>>>><br>
>>>>> Frank<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>
_______________________________________________<br>
>>>> VoiceOps mailing list<br>
>>>> <a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
>>>> <a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>
_______________________________________________<br>
>>> VoiceOps mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
>>> <a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
> _______________________________________________<br>
> VoiceOps mailing list<br>
> <a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
> <a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>VoiceOps mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a></span><br>
<span><a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a></span><br>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<br>
</body>
</html>