RE: SIP trunking providers

[Nathan Anderson]

Maybe I'm missing something here, but what does it matter if the RTP from your 
perspective ends in Chicago or not?  If it does end in Chicago, that only means 
they are proxying the audio before sending it on to the actual media gateway 
for that call where it finally drops onto the PSTN.  So all that happens is 
that the audio latency remains the same (or worse, because of the additional, 
unnecessary proxy) AND that the actual media gateway remains hidden from you.  
You won't be able to actually test and see the latency to the MG, and you will 
be under the (false) impression that latency across all calls is equally "good" 
because you are only measuring RTT to a specific and common media proxy.  By 
sending the audio directly to an MG closer to the point of exit from IP-land, 
it is taking a more direct route to the callee than you are seemingly asking 
for.

If you're not talking about adding a proxy to the equation, are you expecting 
to find a provider in Chicago that immediately goes from IP to PSTN within 
Chicago, regardless of the actual destination of the call?  Circuit-switched 
TDM is not a no-latency connection.  Physics is involved here.  The farther 
apart the caller is from the callee, the more latency there will be, regardless 
of the medium.  All other things being equal (similar network path, etc.), I 
doubt IP packet switching significantly increases the latency over and above 
TDM call trunking.  But I'm not an expert, and again, if I'm missing something 
here, I would love to be proven wrong.

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com


From: NANOG [nanog-boun...@nanog.org] On Behalf Of Mike Hammett 
[na...@ics-il.net]
Sent: Sunday, July 19, 2015 1:04 PM
Cc: nanog@nanog.org
Subject: Re: SIP trunking providers

I too am looking for the Chicago area. Low volume. I'm looking for people whose 
SIP and RTP hit the end of the road in Chicago. Not interested in someone whose 
SIP servers are in LA , but will redirect me to the nearest gateway... without 
telling me where said gateway is.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -

From: "Rafael Possamai" 
To: nanog@nanog.org
Sent: Friday, June 19, 2015 4:40:48 PM
Subject: SIP trunking providers

Would anyone in the list be able to recommend a SIP trunk provider in the
Chicago area? Not a VoIP expert, so just looking for someone with previous
experience.


Thanks,
Rafael

Re: SIP trunking providers

[Mike Hammett]

I want the gateway in Chicago as well. 

I am Chicago based. The end users are Chicago based. Therefore the origination 
would be coming from a Chicago area gateway. Half of the calls (inbound would 
be guaranteed to be local as they'd be coming in through a local tandem anyway. 
Most of the termination traffic would again be to local numbers, therefore 
would again have to be through local tandems. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message -

From: "Nathan Anderson"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Monday, July 20, 2015 4:11:37 AM 
Subject: RE: SIP trunking providers 

Maybe I'm missing something here, but what does it matter if the RTP from your 
perspective ends in Chicago or not? If it does end in Chicago, that only means 
they are proxying the audio before sending it on to the actual media gateway 
for that call where it finally drops onto the PSTN. So all that happens is that 
the audio latency remains the same (or worse, because of the additional, 
unnecessary proxy) AND that the actual media gateway remains hidden from you. 
You won't be able to actually test and see the latency to the MG, and you will 
be under the (false) impression that latency across all calls is equally "good" 
because you are only measuring RTT to a specific and common media proxy. By 
sending the audio directly to an MG closer to the point of exit from IP-land, 
it is taking a more direct route to the callee than you are seemingly asking 
for. 

If you're not talking about adding a proxy to the equation, are you expecting 
to find a provider in Chicago that immediately goes from IP to PSTN within 
Chicago, regardless of the actual destination of the call? Circuit-switched TDM 
is not a no-latency connection. Physics is involved here. The farther apart the 
caller is from the callee, the more latency there will be, regardless of the 
medium. All other things being equal (similar network path, etc.), I doubt IP 
packet switching significantly increases the latency over and above TDM call 
trunking. But I'm not an expert, and again, if I'm missing something here, I 
would love to be proven wrong. 

-- 
Nathan Anderson 
First Step Internet, LLC 
nath...@fsr.com 

 
From: NANOG [nanog-boun...@nanog.org] On Behalf Of Mike Hammett 
[na...@ics-il.net] 
Sent: Sunday, July 19, 2015 1:04 PM 
Cc: nanog@nanog.org 
Subject: Re: SIP trunking providers 

I too am looking for the Chicago area. Low volume. I'm looking for people whose 
SIP and RTP hit the end of the road in Chicago. Not interested in someone whose 
SIP servers are in LA , but will redirect me to the nearest gateway... without 
telling me where said gateway is. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message - 

From: "Rafael Possamai"  
To: nanog@nanog.org 
Sent: Friday, June 19, 2015 4:40:48 PM 
Subject: SIP trunking providers 

Would anyone in the list be able to recommend a SIP trunk provider in the 
Chicago area? Not a VoIP expert, so just looking for someone with previous 
experience. 


Thanks, 
Rafael 

Re: SIP trunking providers

[Owen DeLong]

Why not set up a small Asterisk box in a local datacenter and only trunk out 
the non-local calls?

Owen

> On Jul 20, 2015, at 03:36 , Mike Hammett  wrote:
> 
> I want the gateway in Chicago as well. 
> 
> I am Chicago based. The end users are Chicago based. Therefore the 
> origination would be coming from a Chicago area gateway. Half of the calls 
> (inbound would be guaranteed to be local as they'd be coming in through a 
> local tandem anyway. Most of the termination traffic would again be to local 
> numbers, therefore would again have to be through local tandems. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> - Original Message -
> 
> From: "Nathan Anderson"  
> To: "Mike Hammett"  
> Cc: nanog@nanog.org 
> Sent: Monday, July 20, 2015 4:11:37 AM 
> Subject: RE: SIP trunking providers 
> 
> Maybe I'm missing something here, but what does it matter if the RTP from 
> your perspective ends in Chicago or not? If it does end in Chicago, that only 
> means they are proxying the audio before sending it on to the actual media 
> gateway for that call where it finally drops onto the PSTN. So all that 
> happens is that the audio latency remains the same (or worse, because of the 
> additional, unnecessary proxy) AND that the actual media gateway remains 
> hidden from you. You won't be able to actually test and see the latency to 
> the MG, and you will be under the (false) impression that latency across all 
> calls is equally "good" because you are only measuring RTT to a specific and 
> common media proxy. By sending the audio directly to an MG closer to the 
> point of exit from IP-land, it is taking a more direct route to the callee 
> than you are seemingly asking for. 
> 
> If you're not talking about adding a proxy to the equation, are you expecting 
> to find a provider in Chicago that immediately goes from IP to PSTN within 
> Chicago, regardless of the actual destination of the call? Circuit-switched 
> TDM is not a no-latency connection. Physics is involved here. The farther 
> apart the caller is from the callee, the more latency there will be, 
> regardless of the medium. All other things being equal (similar network path, 
> etc.), I doubt IP packet switching significantly increases the latency over 
> and above TDM call trunking. But I'm not an expert, and again, if I'm missing 
> something here, I would love to be proven wrong. 
> 
> -- 
> Nathan Anderson 
> First Step Internet, LLC 
> nath...@fsr.com 
> 
>  
> From: NANOG [nanog-boun...@nanog.org] On Behalf Of Mike Hammett 
> [na...@ics-il.net] 
> Sent: Sunday, July 19, 2015 1:04 PM 
> Cc: nanog@nanog.org 
> Subject: Re: SIP trunking providers 
> 
> I too am looking for the Chicago area. Low volume. I'm looking for people 
> whose SIP and RTP hit the end of the road in Chicago. Not interested in 
> someone whose SIP servers are in LA , but will redirect me to the nearest 
> gateway... without telling me where said gateway is. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> - Original Message - 
> 
> From: "Rafael Possamai"  
> To: nanog@nanog.org 
> Sent: Friday, June 19, 2015 4:40:48 PM 
> Subject: SIP trunking providers 
> 
> Would anyone in the list be able to recommend a SIP trunk provider in the 
> Chicago area? Not a VoIP expert, so just looking for someone with previous 
> experience. 
> 
> 
> Thanks, 
> Rafael 
> 
> 

Re: SIP trunking providers

[Joe Greco]

> Why not set up a small Asterisk box in a local datacenter and only trunk =
> out the non-local calls?

And do what with the local calls, then?  You're still left with the
problem of getting calls to and from the PSTN.

Not everyone wants to deal with the hassle of dealing with POTS or T1
gatewaying.  In general, it isn't practical to do on a small scale any
more, especially as one looks forward a few years to the inevitable
dismantling of the legacy POTS network.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: SIP trunking providers

[Owen DeLong]

> On Jul 20, 2015, at 06:21 , Joe Greco  wrote:
> 
>> Why not set up a small Asterisk box in a local datacenter and only trunk =
>> out the non-local calls?
> 
> And do what with the local calls, then?  You're still left with the
> problem of getting calls to and from the PSTN.
> 
> Not everyone wants to deal with the hassle of dealing with POTS or T1
> gatewaying.  In general, it isn't practical to do on a small scale any
> more, especially as one looks forward a few years to the inevitable
> dismantling of the legacy POTS network.

If you’re going to the PSTN, who gives a shit where you do the interconnect as
long as its within 100ms.

If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense
to set up a box and just send the external calls out to the trunking provider 
where
you no longer really care where they are.

Absent significant network  suckage, there’s no place in the contiguous US that
isn’t within 100 ms of any other place in the contiguous US these days.

Owen

RE: SIP trunking providers

[Naslund, Steve]

End to end delay is not the most limiting factor.  Jitter is the issue and 
packet drops are the other issue that matters (more importantly the 
distribution of drops).  I think the best reason to select the local provider 
over the distant one is that the sooner he gets off the IP network the less 
impairments he will run into.  The TDM network as antiquated as it is, is less 
susceptible to congestion and call impairments than an IP backbone network is.  
I can tell you from running a bunch of International VOIP networks that they 
are just not as reliable as TDM.  The average internet connection just does not 
meet the reliability standards that the TDM voice network has achieved.  IP 
networks are affected by congestion and routing issues whereas the TDM network 
seldom has these type of problems.  An outage on a TDM circuit rarely affects 
other TDM circuits so they see a lot less higher level outages.  I can 
understand why he does not want to haul his voice cross country over IP when he 
is exiting locally most of the time.

Yes, I understand that the carrier might very well be hauling that traffic via 
IP even after he gets to his gateway point but at that point it becomes their 
problem to deal with. 

Steven Naslund
Chicago IL


>If you’re going to the PSTN, who gives a shit where you do the interconnect as 
>long as its within 100ms.
>
>If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense 
>to set up a box and just send the external calls out to the trunking provider 
>where >you no longer really care where they are.
>
>Absent significant network  suckage, there’s no place in the contiguous US 
>that isn’t within 100 ms of any other place in the contiguous US these days.
>
>Owen

Re: SIP trunking providers

[Rafael Possamai]

When I originally posted the thread, I had asked Chicago due to physical
proximity, and my assumption being the lesser the number of hops, the lower
the probability of running into issues (latency, jitter and congestion). On
the other hand, one of my sandboxes are out of Las Vegas and I haven't had
any issues yet, but the number of test calls I've ran aren't enough to say
with confidence that distance and hops don't matter (indirect ways of
measuring latency, etc).

Another thing is, having your packets stay in Chicago and in Chicago only
is a nice thing, the efficiency of your overall system would be higher for
what it's worth, but as an example, the 2nd hop this e-mail is taking to
get delivered to Nanog is about 100 miles, who knows about the other ones.



On Mon, Jul 20, 2015 at 8:49 AM, Naslund, Steve 
wrote:

> End to end delay is not the most limiting factor.  Jitter is the issue and
> packet drops are the other issue that matters (more importantly the
> distribution of drops).  I think the best reason to select the local
> provider over the distant one is that the sooner he gets off the IP network
> the less impairments he will run into.  The TDM network as antiquated as it
> is, is less susceptible to congestion and call impairments than an IP
> backbone network is.  I can tell you from running a bunch of International
> VOIP networks that they are just not as reliable as TDM.  The average
> internet connection just does not meet the reliability standards that the
> TDM voice network has achieved.  IP networks are affected by congestion and
> routing issues whereas the TDM network seldom has these type of problems.
> An outage on a TDM circuit rarely affects other TDM circuits so they see a
> lot less higher level outages.  I can understand why he does not want to
> haul his voice cross country over IP when he is exiting locally most of the
> time.
>
> Yes, I understand that the carrier might very well be hauling that traffic
> via IP even after he gets to his gateway point but at that point it becomes
> their problem to deal with.
>
> Steven Naslund
> Chicago IL
>
>
> >If you’re going to the PSTN, who gives a shit where you do the
> interconnect as long as its within 100ms.
> >
> >If most of your calls are VOIP<->VOIP within Chicago, then it makes some
> sense to set up a box and just send the external calls out to the trunking
> provider where >you no longer really care where they are.
> >
> >Absent significant network  suckage, there’s no place in the contiguous
> US that isn’t within 100 ms of any other place in the contiguous US these
> days.
> >
> >Owen
>
>

RE: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers

[Drew Weaver]

Is this also why you can't login to wells fargo online using firefox?

Neat. =)



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of 
tqr2813d376cjozqa...@tutanota.com
Sent: Sunday, July 19, 2015 11:03 PM
To: Will M. 
Cc: nanog@nanog.org
Subject: Re: Re: SEC webpages inaccessible due to Firefox blocking servers with 
weak DH ciphers

17. Jul 2015 21:06 by will.mcderm...@sjsu.edu:


> Load balancers can also be used like this, while maintaining 
> redundancy (assuming HA LB config). Terminate SSL/TLS on the LB and 
> run plain-text to the application/appliance. As long as the load 
> balancer is in an acceptable part of the network.
>




Hm, that seems familiar... https://i.imgur.com/ZhQLJmG.jpg

20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Drew Weaver]

Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming 
from China being sent towards IP addresses which provide VoIP services?

I'm talking in the 20-30Gbps range?

The first incident was yesterday at around 13:00 EST, the second incident was 
today at 09:00 EST.

I'm assuming this is just another DDoS like all others, but I would be 
interested to hear if I am not the only one seeing this.

On list or off-list is fine.

Thanks,
-Drew

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Jared Mauch]

I’m sure this is just the extension of all the UDP amplification attacks that 
are ongoing.  My experience is that 1720/CUCM should not be connected to a 
public network as those devices are often not well maintained or patched.

If it’s of value I can look at adding this to the set of things that are 
enumerated as part of the general UDP amplification problems that we continue 
to face due to the lack of SAV.

- Jared

> On Jul 20, 2015, at 11:57 AM, Drew Weaver  wrote:
> 
> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming 
> from China being sent towards IP addresses which provide VoIP services?
> 
> I'm talking in the 20-30Gbps range?
> 
> The first incident was yesterday at around 13:00 EST, the second incident was 
> today at 09:00 EST.
> 
> I'm assuming this is just another DDoS like all others, but I would be 
> interested to hear if I am not the only one seeing this.
> 
> On list or off-list is fine.
> 
> Thanks,
> -Drew

Re: SIP trunking providers

[Chris Garrett]

Might try OneSourceNetworks. 

They have a primary hub out of Chicago and do SIP very well. 

http://www.onesourcenetworks.com/ 

Been a while since I have had any dealings with them, but good folk all the way 
around. 


> On Jul 19, 2015, at 4:04 PM, Mike Hammett  wrote:
> 
> I too am looking for the Chicago area. Low volume. I'm looking for people 
> whose SIP and RTP hit the end of the road in Chicago. Not interested in 
> someone whose SIP servers are in LA , but will redirect me to the nearest 
> gateway... without telling me where said gateway is. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> - Original Message -
> 
> From: "Rafael Possamai"  
> To: nanog@nanog.org 
> Sent: Friday, June 19, 2015 4:40:48 PM 
> Subject: SIP trunking providers 
> 
> Would anyone in the list be able to recommend a SIP trunk provider in the 
> Chicago area? Not a VoIP expert, so just looking for someone with previous 
> experience. 
> 
> 
> Thanks, 
> Rafael 
> 
> 

RE: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Drew Weaver]

Ah, alright. I've seen the "general" amplification attacks SNMP/DNS/NTP/you 
name it, plenty but this is the first one I've ever seen one that targeted 
1720/5060 and as its mitigated in one place it keeps moving from dst to dst 
fairly rapidly until none of the dst ips are available.

-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net] 
Sent: Monday, July 20, 2015 12:06 PM
To: Drew Weaver 
Cc: nanog@nanog.org
Subject: Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 
24 hours

I’m sure this is just the extension of all the UDP amplification attacks that 
are ongoing.  My experience is that 1720/CUCM should not be connected to a 
public network as those devices are often not well maintained or patched.

If it’s of value I can look at adding this to the set of things that are 
enumerated as part of the general UDP amplification problems that we continue 
to face due to the lack of SAV.

- Jared

> On Jul 20, 2015, at 11:57 AM, Drew Weaver  wrote:
> 
> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming 
> from China being sent towards IP addresses which provide VoIP services?
> 
> I'm talking in the 20-30Gbps range?
> 
> The first incident was yesterday at around 13:00 EST, the second incident was 
> today at 09:00 EST.
> 
> I'm assuming this is just another DDoS like all others, but I would be 
> interested to hear if I am not the only one seeing this.
> 
> On list or off-list is fine.
> 
> Thanks,
> -Drew

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

route block china range whole of and/or firewall block china range whole of

then contact gov and tell them trade talks need to involve china engaging with 
incident teams and abuse teams

colin
Sent from my iPhone

> On 20 Jul 2015, at 16:57, Drew Weaver  wrote:
> 
> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic coming 
> from China being sent towards IP addresses which provide VoIP services?
> 
> I'm talking in the 20-30Gbps range?
> 
> The first incident was yesterday at around 13:00 EST, the second incident was 
> today at 09:00 EST.
> 
> I'm assuming this is just another DDoS like all others, but I would be 
> interested to hear if I am not the only one seeing this.
> 
> On list or off-list is fine.
> 
> Thanks,
> -Drew
> 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Valdis . Kletnieks]

On Mon, 20 Jul 2015 19:04:27 +0100, Colin Johnston said:
> route block china range whole of and/or firewall block china range whole of

Do you have an authoritative list of *all* IP blocks that end up routed into 
China?

For bonus points, IPv6 blocks too. :)


pgpKvTqvdD5J4.pgp
Description: PGP signature

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Bryan Tong]

My network also saw 30gbps+ originating from the same region on multiple
occasions beginning last night around 2300EST.
On Jul 20, 2015 12:20 PM,  wrote:

> On Mon, 20 Jul 2015 19:04:27 +0100, Colin Johnston said:
> > route block china range whole of and/or firewall block china range whole
> of
>
> Do you have an authoritative list of *all* IP blocks that end up routed
> into China?
>
> For bonus points, IPv6 blocks too. :)
>

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

see below for china ranges I believe, ipv4 and ipv6


1.0.1.0/24
1.0.2.0/23
1.0.8.0/21
1.0.32.0/19
1.1.0.0/24
1.1.2.0/23
1.1.4.0/22
1.1.8.0/21
1.1.16.0/20
1.1.32.0/19
1.2.0.0/23
1.2.2.0/24
1.2.4.0/22
1.2.8.0/21
1.2.16.0/20
1.2.32.0/19
1.2.64.0/18
1.3.0.0/16
1.4.1.0/24
1.4.2.0/23
1.4.4.0/22
1.4.8.0/21
1.4.16.0/20
1.4.32.0/19
1.4.64.0/18
1.8.0.0/16
1.10.0.0/21
1.10.8.0/23
1.10.11.0/24
1.10.12.0/22
1.10.16.0/20
1.10.32.0/19
1.10.64.0/18
1.12.0.0/14
1.24.0.0/13
1.34.0.0/32
1.45.0.0/16
1.48.0.0/14
1.56.0.0/13
1.68.0.0/14
1.80.0.0/12
1.116.0.0/14
1.180.0.0/14
1.184.0.0/15
1.188.0.0/14
1.192.0.0/13
1.202.0.0/15
1.204.0.0/14
14.0.0.0/21
14.0.12.0/22
14.1.0.0/22
14.16.0.0/12
14.102.128.0/22
14.102.156.0/22
14.103.0.0/16
14.104.0.0/13
14.112.0.0/12
14.130.0.0/15
14.134.0.0/15
14.144.0.0/12
14.192.60.0/22
14.192.76.0/22
14.196.0.0/15
14.204.0.0/15
14.208.0.0/12
27.8.0.0/13
27.16.0.0/12
27.34.232.0/21
27.36.0.0/14
27.40.0.0/13
27.50.40.0/21
27.50.128.0/17
27.54.72.0/21
27.54.152.0/21
27.54.192.0/18
27.98.208.0/20
27.98.224.0/19
27.99.128.0/17
27.103.0.0/16
27.106.128.0/18
27.106.204.0/22
27.109.32.0/19
27.112.0.0/18
27.112.80.0/20
27.113.128.0/18
27.115.0.0/17
27.116.44.0/22
27.121.72.0/21
27.121.120.0/21
27.128.0.0/15
27.131.220.0/22
27.144.0.0/16
27.148.0.0/14
27.152.0.0/13
27.184.0.0/13
27.192.0.0/11
27.224.0.0/14
31.220.30.224/27
36.0.0.0/22
36.0.8.0/21
36.0.16.0/20
36.0.32.0/19
36.0.64.0/18
36.0.128.0/17
36.1.0.0/16
36.4.0.0/14
36.16.0.0/12
36.32.0.0/14
36.36.0.0/16
36.37.0.0/19
36.37.36.0/23
36.37.39.0/24
36.37.40.0/21
36.37.48.0/20
36.40.0.0/13
36.48.0.0/15
36.51.0.0/16
36.56.0.0/13
36.96.0.0/11
36.128.0.0/10
36.192.0.0/11
36.248.0.0/14
36.254.0.0/16
37.153.134.0/25
37.156.6.0/25
39.0.0.0/24
39.0.2.0/23
39.0.4.0/22
39.0.8.0/21
39.0.16.0/20
39.0.32.0/19
39.0.64.0/18
39.0.128.0/17
39.64.0.0/11
39.96.0.1/32
39.96.0.2/31
39.96.0.4/30
39.96.0.8/29
39.96.0.16/28
39.96.0.32/27
39.96.0.64/26
39.96.0.128/25
39.96.1.0/24
39.96.2.0/23
39.96.4.0/22
39.96.8.0/21
39.96.16.0/20
39.96.32.0/19
39.96.64.0/18
39.96.128.0/17
39.97.0.0/16
39.98.0.0/15
39.100.0.0/14
39.104.0.0/14
39.108.0.0/16
39.128.0.0/10
42.0.0.0/22
42.0.8.0/21
42.0.16.0/21
42.0.24.0/22
42.0.32.0/19
42.0.128.0/17
42.1.0.0/19
42.1.32.0/20
42.1.48.0/21
42.1.56.0/22
42.1.128.0/17
42.4.0.0/14
42.48.0.0/13
42.56.0.0/14
42.62.0.0/17
42.62.128.0/19
42.62.160.0/20
42.62.180.0/22
42.62.184.0/21
42.63.0.0/16
42.80.0.0/15
42.83.64.0/20
42.83.80.0/22
42.83.88.0/21
42.83.96.0/19
42.83.128.0/17
42.84.0.0/14
42.88.0.0/13
42.96.64.0/19
42.96.96.0/21
42.96.108.0/22
42.96.112.0/20
42.96.128.0/17
42.97.0.0/16
42.99.0.0/18
42.99.64.0/19
42.99.96.0/20
42.99.112.0/22
42.99.120.0/21
42.100.0.0/14
42.120.0.0/15
42.122.0.0/16
42.123.0.0/19
42.123.36.0/22
42.123.40.0/21
42.123.48.0/20
42.123.64.0/18
42.123.128.0/17
42.128.0.0/12
42.156.0.0/19
42.156.36.0/22
42.156.40.0/21
42.156.48.0/20
42.156.64.0/18
42.156.128.0/17
42.157.0.0/16
42.158.0.0/15
42.160.0.0/12
42.176.0.0/13
42.184.0.0/15
42.186.0.0/16
42.187.0.0/18
42.187.64.0/19
42.187.96.0/20
42.187.112.0/21
42.187.120.0/22
42.187.128.0/17
42.192.0.0/13
42.201.0.0/17
42.202.0.0/15
42.204.0.0/14
42.208.0.0/12
42.224.0.0/12
42.240.0.0/16
42.242.0.0/15
42.244.0.0/14
42.248.0.0/13
43.224.12.0/22
43.224.24.0/22
43.224.44.0/22
43.224.52.0/22
43.224.56.0/22
43.224.64.0/21
43.224.72.0/22
43.224.80.0/22
43.224.100.0/22
43.224.140.0/22
43.224.144.0/22
43.224.160.0/22
43.224.176.0/22
43.224.184.0/22
43.224.200.0/21
43.224.208.0/21
43.224.216.0/22
43.224.224.0/22
43.224.240.0/22
43.225.76.0/22
43.225.84.0/22
43.225.120.0/21
43.225.140.0/22
43.225.172.0/22
43.225.180.0/22
43.225.184.0/22
43.225.208.0/22
43.225.216.0/21
43.225.224.0/20
43.225.240.0/21
43.225.252.0/22
43.226.32.0/19
43.226.64.0/19
43.226.96.0/20
43.226.112.0/21
43.226.120.0/22
43.226.128.0/18
43.226.192.0/20
43.226.208.0/21
43.226.236.0/22
43.226.240.0/20
43.227.0.0/21
43.227.8.0/22
43.227.28.0/22
43.227.32.0/19
43.227.64.0/19
43.227.96.0/21
43.227.104.0/22
43.227.136.0/21
43.227.144.0/22
43.227.152.0/21
43.227.160.0/20
43.227.176.0/21
43.227.188.0/22
43.227.192.0/19
43.227.232.0/22
43.227.248.0/21
43.228.0.0/18
43.228.64.0/21
43.228.76.0/22
43.228.100.0/22
43.228.116.0/22
43.228.120.0/22
43.228.132.0/22
43.228.136.0/22
43.228.148.0/22
43.228.152.0/22
43.228.180.0/22
43.228.188.0/22
43.228.204.0/22
43.228.240.0/22
43.229.16.0/22
43.229.40.0/22
43.229.48.0/22
43.229.56.0/22
43.229.96.0/22
43.229.108.0/22
43.229.120.0/22
43.229.136.0/21
43.229.144.0/22
43.229.168.0/21
43.229.176.0/20
43.229.192.0/21
43.229.216.0/21
43.229.232.0/21
43.230.20.0/22
43.230.32.0/22
43.230.68.0/22
43.230.72.0/22
43.230.84.0/22
43.230.124.0/22
43.230.136.0/22
43.230.168.0/22
43.230.220.0/22
43.230.224.0/19
43.231.32.0/20
43.231.80.0/20
43.231.96.0/20
43.231.136.0/21
43.231.144.0/20
43.231.160.0/20
43.231.176.0/21
43.236.0.0/15
43.238.0.0/16
43.239.0.0/19
43.239.32.0/20
43.239.48.0/22
43.240.0.0/22
43.240.48.0/22
43.240.56.0/21
43.240.68.0/22
43.240.72.0/21
43.240.84.0/22
43.240.124.0/22
43.240.128.0/21
43.240.13

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Roland Dobbins]

On 20 Jul 2015, at 18:12, Drew Weaver wrote:

Ah, alright. I've seen the "general" amplification attacks 
SNMP/DNS/NTP/you name it, plenty but this is the first one I've ever 
seen one that targeted 1720/5060 and as its mitigated in one place it 
keeps moving from dst to dst fairly rapidly until none of the dst ips 
are available.


What source ports and breadth of purported source IPs?  I'm not sure 
this is reflection/amplification attack, it may be a straight packeting 
of H.323 systems.


---
Roland Dobbins 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Valdis . Kletnieks]

On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:
> see below for china ranges I believe, ipv4 and ipv6

You may believe... but are you *sure*?  (Over the years, we've seen
*lots* of "block China" lists that accidentally block chunks allocated
to Taiwan or Australia or other Pacific Rim destinations).

And remember - asking the NIC doesn't help, because there are almost
certainly blocks allocated that the registration points to Korea or
someplace, but the provider routes a sub-block to China.  And let's
not even get started on blocks allocated by ARIN or RIPE

(Yes, it *was* a trick question :)



pgpkcjX2H0ZK7.pgp
Description: PGP signature

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

in war you take information at face value and use it if needed to mitigate 
risk, if there is legit traffic in blocked ranges then excemption procedure in 
place to unblock.

colin

Sent from my iPhone

> On 20 Jul 2015, at 19:57, valdis.kletni...@vt.edu wrote:
> 
> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:
>> see below for china ranges I believe, ipv4 and ipv6
> 
> You may believe... but are you *sure*?  (Over the years, we've seen
> *lots* of "block China" lists that accidentally block chunks allocated
> to Taiwan or Australia or other Pacific Rim destinations).
> 
> And remember - asking the NIC doesn't help, because there are almost
> certainly blocks allocated that the registration points to Korea or
> someplace, but the provider routes a sub-block to China.  And let's
> not even get started on blocks allocated by ARIN or RIPE
> 
> (Yes, it *was* a trick question :)
> 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[ML]

On 7/20/2015 2:57 PM, valdis.kletni...@vt.edu wrote:

On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:

see below for china ranges I believe, ipv4 and ipv6

You may believe... but are you *sure*?  (Over the years, we've seen
*lots* of "block China" lists that accidentally block chunks allocated
to Taiwan or Australia or other Pacific Rim destinations).



If you really wanted to go the route of blocking all/almost all China.  
Isn't there a short list of ASNs that provide transit to China 
citizens/networks?

I'm referring to AS4134, AS4837, etc
Wouldn't blackholing any prefix with those ASNs in the AS path 
accomplish the goal and stay up to date with a new prefixes originated 
from China?

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

new idea to free up network ranges for arin and ripe
give a class c to china firewall, then put all the existing china ranges back 
in allocation pool and reallocate to new customers.
anounce these new ranges with a higher pref than china ranges and then watch 
china start to cooperate at the nic level and abuse level

colin

Sent from my iPhone

> On 20 Jul 2015, at 20:40, ML  wrote:
> 
>> On 7/20/2015 2:57 PM, valdis.kletni...@vt.edu wrote:
>> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:
>>> see below for china ranges I believe, ipv4 and ipv6
>> You may believe... but are you *sure*?  (Over the years, we've seen
>> *lots* of "block China" lists that accidentally block chunks allocated
>> to Taiwan or Australia or other Pacific Rim destinations).
> 
> If you really wanted to go the route of blocking all/almost all China.  Isn't 
> there a short list of ASNs that provide transit to China citizens/networks?
> I'm referring to AS4134, AS4837, etc
> Wouldn't blackholing any prefix with those ASNs in the AS path accomplish the 
> goal and stay up to date with a new prefixes originated from China?
> 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Valdis . Kletnieks]

On Mon, 20 Jul 2015 15:40:09 -0400, ML said:

> If you really wanted to go the route of blocking all/almost all China.
> Isn't there a short list of ASNs that provide transit to China
> citizens/networks?
> I'm referring to AS4134, AS4837, etc
> Wouldn't blackholing any prefix with those ASNs in the AS path
> accomplish the goal and stay up to date with a new prefixes originated
> from China?

What do you do if AS4134 has customers in Australia as well?

And how do you even *tell* if they do or not, if the space hasn't been
SWIP'ed or otherwise noted as customer space?





pgpnDPu_TYqxB.pgp
Description: PGP signature

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Valdis . Kletnieks]

On Mon, 20 Jul 2015 20:18:46 +0100, Colin Johnston said:
> in war you take information at face value and use it if needed to mitigate
> risk, if there is legit traffic in blocked ranges then excemption procedure in
> place to unblock.

So how does Joe Aussie-Sixpack notify you that you goofed, when you've
blocked his IP range?


pgplXCo9PjBR9.pgp
Description: PGP signature

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

> On 20 Jul 2015, at 21:04, valdis.kletni...@vt.edu wrote:
> 
> On Mon, 20 Jul 2015 20:18:46 +0100, Colin Johnston said:
>> in war you take information at face value and use it if needed to mitigate
>> risk, if there is legit traffic in blocked ranges then excemption procedure 
>> in
>> place to unblock.
> 
> So how does Joe Aussie-Sixpack notify you that you goofed, when you've
> blocked his IP range?

source user to use phone contact and or postal service to establish contact 
instead to build trust and then enable internet unblock depending on outcome. 
Sad fact it has come to this since engagement with China folks goes no where, 
always open to dialogue though to engage on this further.

Colin

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Scott Weeks]

--- valdis.kletni...@vt.edu wrote:
On Mon, 20 Jul 2015 20:18:46 +0100, Colin Johnston said:
> in war you take information at face value and use it 
> if needed to mitigate risk, if there is legit traffic 
> in blocked ranges then excemption procedure in place to 
> unblock.

:: So how does Joe Aussie-Sixpack notify you that you 
:: goofed, when you've blocked his IP range?
-


He doesn't.  This is war and us amuricans're gonna
make them change their culture to fit our expectations, 
too.  >;-)

scott

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Valdis . Kletnieks]

On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said:
> source user to use phone contact and or postal service to establish contact

And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack
is likely to be able to find?

(Hint 1: If it's on your website, they can't find it.)

(Hint 2: Mortal users have never heard of WHOIS or similar services)

And what are the chances that after 3-4 days of unreachable, the user will
simply conclude you've gone out of business and you've lost a customer/reader
to a competitor?


pgpmBR2CGXvLW.pgp
Description: PGP signature

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

blocking to mitigate risk is a better trade off gaining better percentage legit 
traffic against a indventant minor valid good network range.


Sent from my iPhone

> On 20 Jul 2015, at 21:20, valdis.kletni...@vt.edu wrote:
> 
> On Mon, 20 Jul 2015 21:12:33 +0100, Colin Johnston said:
>> source user to use phone contact and or postal service to establish contact
> 
> And your phone and postal addresses are listed *where* that Joe Aussie-Sixpack
> is likely to be able to find?
> 
> (Hint 1: If it's on your website, they can't find it.)
> 
> (Hint 2: Mortal users have never heard of WHOIS or similar services)
> 
> And what are the chances that after 3-4 days of unreachable, the user will
> simply conclude you've gone out of business and you've lost a customer/reader
> to a competitor?

Re: SIP trunking providers

[Owen DeLong]

FWIW, I don’t know where their  root nodes are or where their proxies are
located, but I’ve had excellent service from CallCentric for several years.

They’ve just plain worked everywhere I’ve tried in first-world countries and
generally fairly well even in places that were network challenged like Rwanda
~5 years ago, Haiti ~3 years ago, Suriname, Morocco ~6 years ago, etc.

They’ve even worked pretty well from most of the hotel WiFi networks where
I have attempted to use them.

I given them $1.95 per month and something around a penny per minute
on the rare occasion when I use the service. This gets me a DID number,
as well as outgoing service with customized caller-ID mapping. Admittedly
this is for a single-line rather than SIP trunking, but I believe they also 
offer
trunking services.

Owen

> On Jul 20, 2015, at 08:21 , Rafael Possamai  wrote:
> 
> When I originally posted the thread, I had asked Chicago due to physical
> proximity, and my assumption being the lesser the number of hops, the lower
> the probability of running into issues (latency, jitter and congestion). On
> the other hand, one of my sandboxes are out of Las Vegas and I haven't had
> any issues yet, but the number of test calls I've ran aren't enough to say
> with confidence that distance and hops don't matter (indirect ways of
> measuring latency, etc).
> 
> Another thing is, having your packets stay in Chicago and in Chicago only
> is a nice thing, the efficiency of your overall system would be higher for
> what it's worth, but as an example, the 2nd hop this e-mail is taking to
> get delivered to Nanog is about 100 miles, who knows about the other ones.
> 
> 
> 
> On Mon, Jul 20, 2015 at 8:49 AM, Naslund, Steve 
> wrote:
> 
>> End to end delay is not the most limiting factor.  Jitter is the issue and
>> packet drops are the other issue that matters (more importantly the
>> distribution of drops).  I think the best reason to select the local
>> provider over the distant one is that the sooner he gets off the IP network
>> the less impairments he will run into.  The TDM network as antiquated as it
>> is, is less susceptible to congestion and call impairments than an IP
>> backbone network is.  I can tell you from running a bunch of International
>> VOIP networks that they are just not as reliable as TDM.  The average
>> internet connection just does not meet the reliability standards that the
>> TDM voice network has achieved.  IP networks are affected by congestion and
>> routing issues whereas the TDM network seldom has these type of problems.
>> An outage on a TDM circuit rarely affects other TDM circuits so they see a
>> lot less higher level outages.  I can understand why he does not want to
>> haul his voice cross country over IP when he is exiting locally most of the
>> time.
>> 
>> Yes, I understand that the carrier might very well be hauling that traffic
>> via IP even after he gets to his gateway point but at that point it becomes
>> their problem to deal with.
>> 
>> Steven Naslund
>> Chicago IL
>> 
>> 
>>> If you’re going to the PSTN, who gives a shit where you do the
>> interconnect as long as its within 100ms.
>>> 
>>> If most of your calls are VOIP<->VOIP within Chicago, then it makes some
>> sense to set up a box and just send the external calls out to the trunking
>> provider where >you no longer really care where they are.
>>> 
>>> Absent significant network  suckage, there’s no place in the contiguous
>> US that isn’t within 100 ms of any other place in the contiguous US these
>> days.
>>> 
>>> Owen
>> 
>> 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[mikea]

On Mon, Jul 20, 2015 at 09:50:44PM +0100, Colin Johnston wrote:
> blocking to mitigate risk is a better trade off gaining better percentage 
> legit traffic against a indventant minor valid good network range.

That may be your call, or your management's call, but that doesn't make it
*my* call or my management's call. Reasonable people can disagree about this.

-- 
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin 

RE: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Tony Wicks]

> 
> :: So how does Joe Aussie-Sixpack notify you that you
> :: goofed, when you've blocked his IP range?
> -
> 
> 
> He doesn't.  This is war and us amuricans're gonna
> make them change their culture to fit our expectations,
> too.  >;-)
> 

Hahaha... Could not have said it better. But seriously as a new Zealand based 
engineer who has 20+ years in the internet industry the number of times I have 
had to deal with arrogant *** who block ip ranges that affect my customers 
while thinking they are taking a swipe at China is a sad reflection on the 
attitude of some people. Then people wonder why the rest of the world does not 
trust the good old USA to run the Internet by itself.

Re: SIP trunking providers

[Owen DeLong]

The TDM network is rapidly being eliminated. The major telcos have been moving 
their backbones to VOIP and higher levels of oversubscription as a result for 
years now because of the very large cost savings that can be achieved.

International TDM may still be pretty common, but domestic TDM is rapidly 
becoming as popular as a Strowger.

Owen

> On Jul 20, 2015, at 06:49 , Naslund, Steve  wrote:
> 
> End to end delay is not the most limiting factor.  Jitter is the issue and 
> packet drops are the other issue that matters (more importantly the 
> distribution of drops).  I think the best reason to select the local provider 
> over the distant one is that the sooner he gets off the IP network the less 
> impairments he will run into.  The TDM network as antiquated as it is, is 
> less susceptible to congestion and call impairments than an IP backbone 
> network is.  I can tell you from running a bunch of International VOIP 
> networks that they are just not as reliable as TDM.  The average internet 
> connection just does not meet the reliability standards that the TDM voice 
> network has achieved.  IP networks are affected by congestion and routing 
> issues whereas the TDM network seldom has these type of problems.  An outage 
> on a TDM circuit rarely affects other TDM circuits so they see a lot less 
> higher level outages.  I can understand why he does not want to haul his 
> voice cross country over IP when he is exiting locally most of the time.
> 
> Yes, I understand that the carrier might very well be hauling that traffic 
> via IP even after he gets to his gateway point but at that point it becomes 
> their problem to deal with. 
> 
> Steven Naslund
> Chicago IL
> 
> 
>> If you’re going to the PSTN, who gives a shit where you do the interconnect 
>> as long as its within 100ms.
>> 
>> If most of your calls are VOIP<->VOIP within Chicago, then it makes some 
>> sense to set up a box and just send the external calls out to the trunking 
>> provider where >you no longer really care where they are.
>> 
>> Absent significant network  suckage, there’s no place in the contiguous US 
>> that isn’t within 100 ms of any other place in the contiguous US these days.
>> 
>> Owen
> 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Colin Johnston]

a gentle talk to china folks from neighbours/asia associated areas might help 
to pursude china to do the right thing and tackle abuse and tackle direct 
network attacks.

colin

Sent from my iPhone

On 20 Jul 2015, at 22:31, "Tony Wicks"  wrote:

>> 
>> :: So how does Joe Aussie-Sixpack notify you that you
>> :: goofed, when you've blocked his IP range?
>> -
>> 
>> 
>> He doesn't.  This is war and us amuricans're gonna
>> make them change their culture to fit our expectations,
>> too.  >;-)
> 
> Hahaha... Could not have said it better. But seriously as a new Zealand based 
> engineer who has 20+ years in the internet industry the number of times I 
> have had to deal with arrogant *** who block ip ranges that affect my 
> customers while thinking they are taking a swipe at China is a sad reflection 
> on the attitude of some people. Then people wonder why the rest of the world 
> does not trust the good old USA to run the Internet by itself.
> 

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Ca By]

Folks, it may be time to  take the next step and admit that UDP is too
broken to support

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

Your comments have been requested



On Mon, Jul 20, 2015 at 8:57 AM, Drew Weaver  wrote:

> Has anyone else seen a massive amount of illegitimate UDP 1720 traffic
> coming from China being sent towards IP addresses which provide VoIP
> services?
>
> I'm talking in the 20-30Gbps range?
>
> The first incident was yesterday at around 13:00 EST, the second incident
> was today at 09:00 EST.
>
> I'm assuming this is just another DDoS like all others, but I would be
> interested to hear if I am not the only one seeing this.
>
> On list or off-list is fine.
>
> Thanks,
> -Drew
>
>

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Christopher Morrow]

On Mon, Jul 20, 2015 at 3:18 PM, Colin Johnston  wrote:
> in war you take information at face value and use it if needed to mitigate 
> risk, if there is legit traffic in blocked ranges then excemption procedure 
> in place to unblock.
>

it's not clear how blocking any list of addresse stops the 20-30gbps
of packets from arriving at your doorstep, but if you feel you're
doing the right thing for your network, I can only echo the words of
another: "I encourage my competitors to do this"


> colin
>
> Sent from my iPhone
>
>> On 20 Jul 2015, at 19:57, valdis.kletni...@vt.edu wrote:
>>
>> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:
>>> see below for china ranges I believe, ipv4 and ipv6
>>
>> You may believe... but are you *sure*?  (Over the years, we've seen
>> *lots* of "block China" lists that accidentally block chunks allocated
>> to Taiwan or Australia or other Pacific Rim destinations).
>>
>> And remember - asking the NIC doesn't help, because there are almost
>> certainly blocks allocated that the registration points to Korea or
>> someplace, but the provider routes a sub-block to China.  And let's
>> not even get started on blocks allocated by ARIN or RIPE
>>
>> (Yes, it *was* a trick question :)
>>

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Christopher Morrow]

On Mon, Jul 20, 2015 at 5:40 PM, Colin Johnston  wrote:
> a gentle talk to china folks from neighbours/asia associated areas might help 
> to pursude china to do the right thing and tackle abuse and tackle direct 
> network attacks.

it's confusing to me that you think china (the gov't or the ISPs) care
a whit about what you think is going on?

I suppose after ~15 yrs of this if you keep on doing it eventually
they'll listen?
the definition of crazy is...

Re: SIP trunking providers

[James Cloos]

> "MH" == Mike Hammett  writes:

MH> I too am looking for the Chicago area. Low volume. I'm looking for
MH> people whose SIP and RTP hit the end of the road in Chicago. Not
MH> interested in someone whose SIP servers are in LA , but will redirect
MH> me to the nearest gateway... without telling me where said gateway is.

I know that voip.ms has sip/rtp nodes in Chicago.

I don't know what the next hop is (whether is is tdm or something like
sip/rtp orver a dedicated ethernet to a clec or an ixc or what), but I
find the latency minimal.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: another tilt at the Verizon FIOS IPv6 windmill

[Ricky Beam]

On Sat, 18 Jul 2015 06:45:43 -0400, Seth Mos  wrote:
For now, all the customers with the Ubee in bridge mode are SOL. It's  
not clear what the reason is, but Ubee in bridge mode with IPv6 is  
listed on the road map. If that's intentional policy or that the  
firmware isn't ready yet is not clear at this point.


Even in bridge mode, it's router is still active (and consuming an address  
-- which TWC eventually "fixed" by upping the number of allowed devices by  
one.) In TWC-BC land, the customer has no access to the CPE, so we cannot  
see anything beyond the login screen.


("user" -- non-priv account -- can be accessed on some of them, which is  
how I know the router is still active, but I cannot do anything about it.)


The Arris DG1670A is passing IPv6 through properly. (I'm told it is "known  
broken", but it's the *one* out of three that works.) The Arris CM820A --  
used for their hotspot -- doesn't appear to work correctly; my (win7)  
laptop got a DHCP ::/128 but then couldn't get anywhere. (IPv4 worked fine)


[For the record, TWC-BC hands out a /56 no matter what you ask for.]

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[John Weekes]

Ca,


Folks, it may be time to  take the next step and admit that UDP is too
broken to support

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

Your comments have been requested


My comment would be that UDP is still widely used for game server 
traffic. This is unlikely to change in the near future because TCP (by 
default) is not well-suited for highly time-sensitive data, as even a 
small amount of packet loss causes significant delays.


In light of this, it is a bad idea for network operators to apply 
overall rate-limits to UDP traffic right now. Rate-limiting specific UDP 
/ports/ that are frequently seen in reflection attacks -- such as 19, 
123, and 1900 -- is a more reasonable practice, however, and it is 
becoming more common/.


/UDP-based application protocols can be implemented correctly, such that 
they also have handshakes that limit their ability to be used for 
reflection attacks, and modern services (including modern game servers) 
do this.


TCP and UDP can both be spoofed and used for direct attacks; we see this 
all the time. UDP is preferred due to many applications protocols' 
susceptibility to amplification attacks, but spoofed TCP attacks are 
often a bit thornier to deal with from the standpoint of a host 
attempting to externally mitigate, because tracking the three-way 
handshake requires keeping state.


I spoke with Drew earlier and his attacks do not appear to be reflected, 
so this is orthogonal to his concern today. He is seeing 
directly-generated traffic, which could use any protocol.


-John

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Ca By]

On Monday, July 20, 2015, John Weekes  wrote:

> Ca,
>
>  Folks, it may be time to  take the next step and admit that UDP is too
>> broken to support
>>
>> https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00
>>
>> Your comments have been requested
>>
>
> My comment would be that UDP is still widely used for game server traffic.
> This is unlikely to change in the near future because TCP (by default) is
> not well-suited for highly time-sensitive data, as even a small amount of
> packet loss causes significant delays.
>
> First, thanks for feedback. Opsec mailer in the ietf is a good place for
detailed feedback.

TCP packets travel at the same speed as udp.

In fact nearly all video is delivered as tcp (youtube, netflix)

Your level of tcp window pacing is relevant to your congestion algo.  There
is also sctp 


> In light of this, it is a bad idea for network operators to apply overall
> rate-limits to UDP traffic right now. Rate-limiting specific UDP /ports/
> that are frequently seen in reflection attacks -- such as 19, 123, and 1900
> -- is a more reasonable practice, however, and it is becoming more common/.
>
>
I noticed you did not include today's reported udp1720. Somebody took it on
the chin because they did not rate limit that port. Tomorrow it will be a
different port.

Going back to the draft, it states that you should create a basline and
understand it.


> /UDP-based application protocols can be implemented correctly, such that
> they also have handshakes that limit their ability to be used for
> reflection attacks, and modern services (including modern game servers) do
> this.
>
>
Agreed. The issue is that there is so much broken ntp / chargen / ssdp 
That udp is a threat and "your udp app" will be collateral damage at some
point (now, or in the future)


> TCP and UDP can both be spoofed and used for direct attacks; we see this
> all the time. UDP is preferred due to many applications protocols'
> susceptibility to amplification attacks, but spoofed TCP attacks are often
> a bit thornier to deal with from the standpoint of a host attempting to
> externally mitigate, because tracking the three-way handshake requires
> keeping state.
>
>
What is the attack bandwidth volume ratio you see between tcp and udp?
Mine is nearly 100% udp, but i have an eyeball network


> I spoke with Drew earlier and his attacks do not appear to be reflected,
> so this is orthogonal to his concern today. He is seeing directly-generated
> traffic, which could use any protocol.
>
> -John
>

But it is udp, so it is not orthogonal and would hit the bitbucket on
protocol level policer without anyone opening a ticket or getting pages.

This draft is not trying to deperecate udp. It is simply illuminating a
situation and a trend and providing advice.  As a network operator, my
concern is that protocols doing cool things like quic and webrtc will grow
very quickly on udp and the signal will mix with ddos noise in such a way
that i cannot tease them apart.

Today, i rate limit udp with a sledge hammer just to keep the network up.
If you say i have to rate limit with a scalpel, that probably wont work.

CB

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[James Milko]

On Mon, Jul 20, 2015 at 3:40 PM, ML  wrote:

> On 7/20/2015 2:57 PM, valdis.kletni...@vt.edu wrote:
>
>> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:
>>
>>> see below for china ranges I believe, ipv4 and ipv6
>>>
>> You may believe... but are you *sure*?  (Over the years, we've seen
>> *lots* of "block China" lists that accidentally block chunks allocated
>> to Taiwan or Australia or other Pacific Rim destinations).
>>
>>
> If you really wanted to go the route of blocking all/almost all China.
> Isn't there a short list of ASNs that provide transit to China
> citizens/networks?
> I'm referring to AS4134, AS4837, etc
> Wouldn't blackholing any prefix with those ASNs in the AS path accomplish
> the goal and stay up to date with a new prefixes originated from China?
>
>
That would prevent you from responding to their traffic (assuming DFZ),
 but their traffic would still have a valid route to your network.

JM

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[John]

TCP packets travel at the same speed as udp.


I will go into more detail.

TCP is designed to be a reliable protocol. When a packet is lost, TCP 
reduces the transfer rate and retransmits the packet. If enough packets 
are lost, the connection is reset entirely. This is not desirable with a 
video game, where game state is being constantly refreshed already; 
retransmissions are redundant, and the developer wants to control when 
the connection is considered unsalvageable. There are also other factors.


A game developer could go into more detail with you on this (I am not 
involved with such decisions), but the simple fact is that UDP is used 
almost exclusively with fast-action video games. That definitely won't 
change for already-released games and it's unlikely to change in the 
near future for new games.


Your level of tcp window pacing is relevant to your congestion algo.  
There is also sctp 


Yes, but the game developers want to control the way that congestion is 
handled, without trying to turn global knobs in the OS that may not even 
be exposed.



 I noticed you did not include today's reported udp1720.


UDP port 1720 was the destination port here, not the source port. As I 
understand it, the attack did not involve reflection and this is not a 
common target. His problem was mostly that a botnet was sending him 
attack traffic, not that it was using a specific protocol or port (those 
are just variables that the attacker could adjust -- and botnet users 
certainly will adjust to TCP if UDP starts seeing more rate-limiting).


Blocking a destination service port like this would be akin to blocking 
TCP port 80 in response to an attack that involves spoofed TCP SYN 
traffic to port 80. That might be appropriate in some circumstances, 
such as if the victim is not a webserver, but it's not generally a good 
idea to limit it globally, and it's even less of a good idea to limit 
TCP overall.


Somebody took it on the chin because they did not rate limit that 
port. Tomorrow it will be a different port.


It is not the case that high-amplification-factor UDP services are 
discovered on a daily basis -- or anything close to that.


What is the attack bandwidth volume ratio you see between tcp and 
udp?  Mine is nearly 100% udp, but i have an eyeball network


Attackers usually turn to UDP first, and if they use a spoofing traffic 
source, the preferred vector will usually be amplification using one of 
the big three -- NTP, DNS, or SSDP. When this fails, they will often 
turn to TCP attacks, or application-specific attacks. Those with botnets 
often use TCP SYN or small UDP packets to start.


My networks have a large component of game server traffic, so at least 
75% of legitimate traffic that we see is also UDP. I would expect to see 
most attacks here also use UDP, just because attackers frequently choose 
the protocol vector to match the service.


But it is udp, so it is not orthogonal and would hit the bitbucket on 
protocol level policer without anyone opening a ticket or getting pages.


A policer would degrade any UDP application and he'd probably have even 
more trouble tickets from customers than he would from just immediately 
null-routing the target IP addresses. Such tickets would could be a bit 
more complicated to troubleshoot, as staff and customers may not expect 
a UDP rate-limit to be the cause.


My main point is that an overall UDP rate-limit is not a good idea for 
most networks -- and certainly not eyeball networks -- and we don't want 
to encourage it.  Rate-limits (or other rules) on specific ports that 
are used in amplification attacks, however, might make a lot of sense, 
depending on the network. Potentially, an overall UDP rate-limit on 
individual users might also make sense (if those users are known to not 
need to use UDP).


This draft is not trying to deperecate udp. It is simply illuminating 
a situation and a trend and providing advice.  As a network operator, 
my concern is that protocols doing cool things like quic and webrtc 
will grow very quickly on udp and the signal will mix with ddos noise 
in such a way that i cannot tease them apart.


My concerns with this document, and the sentiment behind it, are 
primarily twofold.


1. Network operators may see it and think that an overall network-wide 
rate-limit UDP is a good idea, when there are much smarter mitigation 
options available.
2. Developers may read the document, consider UDP deprecated, and start 
to redevelop their libraries to use other protocols that may not be the 
right fit or might have a higher cost to develop. This unnecessarily 
burdens them.


Right now, I haven't heard a lot of organizations tell me that they're 
rate-limiting UDP overall, thankfully. I really don't want it to start, 
and I hate to think that this sort of exposure might encourage that 
decision to be made more widely.


Network operators reading this, please don't blanket rate-limit UDP 
across your network!

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[ITechGeek]

On Mon, Jul 20, 2015 at 5:31 PM, Tony Wicks  wrote:

> Hahaha... Could not have said it better. But seriously as a new Zealand
> based engineer who has 20+ years in the internet industry the number of
> times I have had to deal with arrogant *** who block ip ranges that
> affect my customers while thinking they are taking a swipe at China is a
> sad reflection on the attitude of some people. Then people wonder why the
> rest of the world does not trust the good old USA to run the Internet by
> itself.


And I thought it was because of the NSA.

---
-ITG (ITechGeek)
i...@itechgeek.com
https://itg.nu/
GPG Keys: https://itg.nu/contact/gpg-key
Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net

RE: SIP trunking providers

[Nathan Anderson]

Okay, sure.  But I think we might be talking past each other here.  My whole 
response was predicated on the assumption that the media gateway that a given 
term call is sent to is picked based on its geographic proximity to either the 
ratecenter/CO or tandem of the callee.  It doesn't really make sense for a 
provider to do anything otherwise, AFAICT, so I doubt that they would.  If my 
assumption is correct, you gain no advantage by having your long-distance term 
calls go through a Chicago MG (which was my original argument to begin with), 
and any local Chicago calls would be sent to a local Chicago MG anyway, so 
you're sweating bullets over nothing.  And, like you said, origination for your 
end users would be hitting a Chicago MG already.

Soo...problem solved?

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com


From: NANOG [nanog-boun...@nanog.org] On Behalf Of Mike Hammett 
[na...@ics-il.net]
Sent: Monday, July 20, 2015 3:36 AM
To: nanog@nanog.org
Subject: Re: SIP trunking providers

I want the gateway in Chicago as well.

I am Chicago based. The end users are Chicago based. Therefore the origination 
would be coming from a Chicago area gateway. Half of the calls (inbound would 
be guaranteed to be local as they'd be coming in through a local tandem anyway. 
Most of the termination traffic would again be to local numbers, therefore 
would again have to be through local tandems.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -

From: "Nathan Anderson" 
To: "Mike Hammett" 
Cc: nanog@nanog.org
Sent: Monday, July 20, 2015 4:11:37 AM
Subject: RE: SIP trunking providers

Maybe I'm missing something here, but what does it matter if the RTP from your 
perspective ends in Chicago or not? If it does end in Chicago, that only means 
they are proxying the audio before sending it on to the actual media gateway 
for that call where it finally drops onto the PSTN. So all that happens is that 
the audio latency remains the same (or worse, because of the additional, 
unnecessary proxy) AND that the actual media gateway remains hidden from you. 
You won't be able to actually test and see the latency to the MG, and you will 
be under the (false) impression that latency across all calls is equally "good" 
because you are only measuring RTT to a specific and common media proxy. By 
sending the audio directly to an MG closer to the point of exit from IP-land, 
it is taking a more direct route to the callee than you are seemingly asking 
for.

If you're not talking about adding a proxy to the equation, are you expecting 
to find a provider in Chicago that immediately goes from IP to PSTN within 
Chicago, regardless of the actual destination of the call? Circuit-switched TDM 
is not a no-latency connection. Physics is involved here. The farther apart the 
caller is from the callee, the more latency there will be, regardless of the 
medium. All other things being equal (similar network path, etc.), I doubt IP 
packet switching significantly increases the latency over and above TDM call 
trunking. But I'm not an expert, and again, if I'm missing something here, I 
would love to be proven wrong.

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com


From: NANOG [nanog-boun...@nanog.org] On Behalf Of Mike Hammett 
[na...@ics-il.net]
Sent: Sunday, July 19, 2015 1:04 PM
Cc: nanog@nanog.org
Subject: Re: SIP trunking providers

I too am looking for the Chicago area. Low volume. I'm looking for people whose 
SIP and RTP hit the end of the road in Chicago. Not interested in someone whose 
SIP servers are in LA , but will redirect me to the nearest gateway... without 
telling me where said gateway is.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -

From: "Rafael Possamai" 
To: nanog@nanog.org
Sent: Friday, June 19, 2015 4:40:48 PM
Subject: SIP trunking providers

Would anyone in the list be able to recommend a SIP trunk provider in the
Chicago area? Not a VoIP expert, so just looking for someone with previous
experience.


Thanks,
Rafael

RE: SIP trunking providers

[Nathan Anderson]

Okay, fair enough.  I guess I made the assumption somehow that Mike was 
concerned solely about latency, which if that's all he is concerned about, then 
the points you bring up would largely be strawmen.  But I just re-read Mike's 
post, and he doesn't state his reasons for wanting the local gateway.  It must 
have been Dovid's reply that planted the seed of the idea in my mind that Mike 
was primarily concerned about latency.

-- Nathan


From: NANOG [nanog-boun...@nanog.org] On Behalf Of Naslund, Steve 
[snasl...@medline.com]
Sent: Monday, July 20, 2015 6:49 AM
To: nanog@nanog.org
Subject: RE: SIP trunking providers

End to end delay is not the most limiting factor.  Jitter is the issue and 
packet drops are the other issue that matters (more importantly the 
distribution of drops).  I think the best reason to select the local provider 
over the distant one is that the sooner he gets off the IP network the less 
impairments he will run into.  The TDM network as antiquated as it is, is less 
susceptible to congestion and call impairments than an IP backbone network is.  
I can tell you from running a bunch of International VOIP networks that they 
are just not as reliable as TDM.  The average internet connection just does not 
meet the reliability standards that the TDM voice network has achieved.  IP 
networks are affected by congestion and routing issues whereas the TDM network 
seldom has these type of problems.  An outage on a TDM circuit rarely affects 
other TDM circuits so they see a lot less higher level outages.  I can 
understand why he does not want to haul his voice cross country over IP when he 
is exiting locally most of the time.

Yes, I understand that the carrier might very well be hauling that traffic via 
IP even after he gets to his gateway point but at that point it becomes their 
problem to deal with.

Steven Naslund
Chicago IL


>If you’re going to the PSTN, who gives a shit where you do the interconnect as 
>long as its within 100ms.
>
>If most of your calls are VOIP<->VOIP within Chicago, then it makes some sense 
>to set up a box and just send the external calls out to the trunking provider 
>where >you no longer really care where they are.
>
>Absent significant network  suckage, there’s no place in the contiguous US 
>that isn’t within 100 ms of any other place in the contiguous US these days.
>
>Owen