Re: hosted PBX/VOIP thru VPN?
On Nov 11, 2008, at 6:17 PM, Lorell Hathcock wrote: All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? The implementation of a VPN indeed would probably not result in an improvement of your customer' RTP packet delivery, either for jitter or packet loss. If you wish to see if RTP is being meddled with, try changing the RTP port numbers on the ATA or on the remote side to something less typical of the RTP port range - try something <1. While some deep-packet inspections will dig through each packet to categorize and stomp on RTP voice audio, it is probably not the case that anyone in the path you describe is applying anything other than port number and protocol (UDP/TCP) inspections, if they are doing any such punitive QOS at all. I would be very interested to learn if you or anyone does know of a transit carrier who is de-pref'ing RTP packets as a peered transit provider (or non-paid peering partner.) This doesn't mean static "end customers" - I'm really talking about traffic that is ingress/egress from some other ASN, even if that ASN is paying for transit. This would be a fairly major departure from any type of QOS or de- preferencing that I've seen before, and I'm sure the list would be interested in any results as well. The root cause of the problem your customer describes also needs to be identified - that will tell you a lot. Wireshark a few calls and see what you can see on the RTP packet path. Without more specifics on the "bad performance", it will be difficult to determine if this is even a network issue at all - maybe it's just a sub-standard ITSP, gateway, or even PSTN path on the far side of the equation. A very slight chance exists that due to round-robin routing you are getting out-of-order packets in one or both directions of the media stream. RTP does not recover well from OOO packets. Try some traceroutes in the RTP port range to see what happens. You can see one direction for the traceroute UDP outbound and watch for multi- pathing, and you can see the other direction with wireshark on inbound OOO RTP streams to your customer. If the problem is out-of-order RTP packets, then there are some things that a GRE tunnel plus some creative route announcements/static routes might be able to solve, and those are left as an exercise for the reader. But a "VPN" is almost always going to be the wrong answer for VoIP performance increases - GRE is better suited for encapsulating UDP, and I run VoIP connections over GRE all the time due to the perverse and unfortunate routing situation for my home network, which resides at the end of a consumer- grade cable IP connection. I would not recommend even GRE as a matter of course for VoIP RTP transport; I merely say that it is possible, and in some fringe cases the only solution available. FWIW: Snom (a SIP-based desk phone) now includes a built-in IPSEC tunnel protocol stack so the phone can securely establish connections back to the PBX or other endpoints. The reasons for doing this are not clearly not performance-oriented - they are security-oriented. It even will encapsulate traffic from any hosts attached to the one-port switch on the back. Desk phones are getting pretty scary. I'm waiting for "sh ip bgp" for my Cisco 7960... http://wiki.snom.com/VPN http://www.snom.com/en/products/snom-370-voip-phone/ JT
Re: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd)
Since 11/5, my spam load has dropped from about 400,000 attempts per day to less than 40,000 ! And most of this I had noted was comming from what looked like compromised web hosts - eg: same host/domain name representing 10 or 20 addresses in any given range). I am shocked at the sudden and dramatic downtick but also equally delighted! Way to go! Gadi Evron wrote: Via Security Fix. [snip] A U.S. based Web hosting firm that security experts say was responsible for facilitating more than 75 percent of the junk e-mail blasted out each day globally has been knocked offline following reports from Security Fix on evidence gathered about criminal activity emanating from the network.
RE: hosted PBX/VOIP thru VPN?
Yes, dissuade him. If anything a VPN will add latency unless possibly gear is replaced to provide the VPN that is significantly greater than current. But... if a provider en-route decided to "slow down" competing voice traffic, the VPN would hide it from the filters which might make it seem like voice traffic was speeding up. Of course that is a major "if". Shouldn't take much to lab it, and show the customer the difference in quality, if any. Regardless, if the customer insists, it's billable so why not you than someone else. Just make sure said customer knows that you are not recommending the solution and why. If you implement the VPN and voice quality does not improve, you are covered. -- Tim Sanderson, network administrator [EMAIL PROTECTED] -Original Message- From: Lorell Hathcock [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2008 9:17 PM, if any To: nanog@nanog.org Subject: hosted PBX/VOIP thru VPN? All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | [EMAIL PROTECTED] ocbannerjoomla
[funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd)
-- Forwarded message -- Date: Tue, 11 Nov 2008 18:22:42 -0800 From: Paul Ferguson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Via Security Fix. [snip] A U.S. based Web hosting firm that security experts say was responsible for facilitating more than 75 percent of the junk e-mail blasted out each day globally has been knocked offline following reports from Security Fix on evidence gathered about criminal activity emanating from the network. For the past four months, Security Fix has been gathering data from the security industry about McColo Corp., a San Jose, Calif., based Web hosting service whose client list experts say includes some of the most disreputable cyber-criminal gangs in business today. On Monday, Security Fix contacted the Internet providers that manage more than 90 percent of the company's connection to the larger Internet, sending them information about badness at McColo as documented by the security industry. [snip] More: http://voices.washingtonpost.com/securityfix/2008/11/major_source_of_online _scams_a.html Also, more details will become available real soon now... - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJGj2hq1pz9mNUZTMRAsUaAJ4g4AzgLzD+NB9jvtlQu2kWwxY9UgCfakeM RzvY4TKA6HqN8jePb8AJlOY= =r3Oz -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ ___ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Re: hosted PBX/VOIP thru VPN?
On 12/11/2008, at 3:17 PM, Lorell Hathcock wrote: All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Yep. I've done this sort of thing to get around NAT problems, that's about it. Perhaps their theory is that a VPN gives them a "private" network, and they've heard that "private" networks do VoIP better. Obviously, a VPN doesn't give you control of the packets on the wire like a private network does, so that theory doesn't work. -- Nathan Ward
hosted PBX/VOIP thru VPN?
All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | [EMAIL PROTECTED] ocbannerjoomla <>
Cable re-management
Hi, I wondered if any of the NANO's (Specifically NYCNANO's) have ever brought in another company, or offered as a service to the general world cable re-management. I know Hugh O'Kane is a big place that does it, but I'm looking for said services in NYC. I have client datatel closets that REALLY need color coding, cables cut to length, A-B labeling, etc. For an added bonus, they would potentially be able to build out an entire FLOOR of a building from scratch. Private replies please, will summarize to any who ask. Thanks, Tuc/TBOH
Re: Potential Prefix Hijack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, As several people have already observed here, AS 16735 announced almost the whole Internet last night to two of its peers (AS 27664, 174213 routes and AS 22548, 111231 routes). These routes were not propagated to the global Internet--and as Frederico A C Neves has confirmed, it was a localized event. For more detail on what happened, see Frederico's post [0] and the BGPMon site's summary [1]. We also have a slightly more detailed analysis here [2]. - -Martin [0] http://www.merit.edu/mail.archives/nanog/msg12813.html [1] http://bgpmon.net/blog/?p=80 [2] http://www.renesys.com/blog/2008/11/brazil-leak-if-a-tree-falls-in.shtml - -- Martin A. Brown --- Renesys Corporation --- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFJGdmkdXQGngQsWbkRAkEQAKCNUj6C6B0fVf3JOpp3nHnfyBGMYgCg1t6q xAGn9T2yn9FuFeXGXCaBDnU= =2kVx -END PGP SIGNATURE-
Re: Potential Prefix Hijack
Hi Bill, On Mon, Nov 10, 2008 at 07:00:47PM -0800, Bill Woodcock wrote: > On Tue, 11 Nov 2008, Mark Tinka wrote: > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). > > Have you tried CERT-BR? Uh... I was about to say "they're usually very > responsive, and good at coordinating this sort of thing." And then their > web site failed to load, because the prefix it's in is flapping. Hm. > > Fred, you still awake? Not at the time of the event :-( AFAIK the event was local to CTBC (AS16735) and their customers. This is our case and as we host RRC15 at PTTMetro São Paulo, and feed it with a full routing BGP feed it triggered the reports from bgpmon [1]. CTBC is still pending to explain the event, > -Bill Fred [1] http://bgpmon.net/blog/?p=80
Re: Potential Prefix Hijack
Hi! That's not true, as not all our prefixes were hijacked nor leaked, since they were originating them. If they were leaking them you might be able to see further AS's on the AS-PATH, incluiding the legitimate AS for originating those prefixes. We have seen issues like this also when a customer was leaking full routes, and his router ws not able to coop with the BGP tables. This gave really really strange things, simmilar like here, some prefixes were there and some not. Completely random. Am i seeing things in a blur way ? or this is supposed to happen as wind flows ? Upstreams should filter things properly. Thats a sure thing. OR max prefix limit customers like that Bye, Raymond.
Re: Potential Prefix Hijack
That's not true, as not all our prefixes were hijacked nor leaked, since they were originating them. If they were leaking them you might be able to see further AS's on the AS-PATH, incluiding the legitimate AS for originating those prefixes. My point here is also about peers and upstreams to set properly filter or max-prefix settings to avoid those nasty things. Am i seeing things in a blur way ? or this is supposed to happen as wind flows ? regards, --- Nuno Vieira nfsi telecom, lda. [EMAIL PROTECTED] Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - "Raymond Dijkxhoorn" <[EMAIL PROTECTED]> wrote: > Hi! > > > We were hijacked aswell, by 27664 16735 > > > > Our affected prefixes were: > > > > 94.46.0.0/16 > > 194.88.142.0/23 > > 194.11.23.0/24 > > 82.102.0.0/18 > > 195.246.238.0/23 > > 194.107.127.0/24 > > 81.92.192.0/19 > > 193.227.238.0/23 > > > > We are trying to contact them in order to get some feedback, and > some good explanation for this. > > The obviously were leaking full routing, are we all gonna annnounce > 'my > prefix was in there also?' > > Bye, > Raymond.
Re: Potential Prefix Hijack
Hi! 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. The obviously were leaking full routing, are we all gonna annnounce 'my prefix was in there also?' ACTUALLY They didn't hijack ALL my netblocks... I have 3. One was completely untouched, 1 was only hijacked by 1 site, and the last was hijacked by 2 different sites. :) So their router had most likely a hard time and stuff was flapping, i see something like that in the BGPLay output also. Bye, Raymond.
Re: Potential Prefix Hijack
> > Hi! > > > We were hijacked aswell, by 27664 16735 > > > > Our affected prefixes were: > > > > 94.46.0.0/16 > > 194.88.142.0/23 > > 194.11.23.0/24 > > 82.102.0.0/18 > > 195.246.238.0/23 > > 194.107.127.0/24 > > 81.92.192.0/19 > > 193.227.238.0/23 > > > > We are trying to contact them in order to get some feedback, and some good > > explanation for this. > > The obviously were leaking full routing, are we all gonna annnounce 'my > prefix was in there also?' > ACTUALLY They didn't hijack ALL my netblocks... I have 3. One was completely untouched, 1 was only hijacked by 1 site, and the last was hijacked by 2 different sites. :) Tuc
Re: Potential Prefix Hijack
Possibly silly question: If a small ISP is leaking a full table and you cannot reach them, why not contact their upstreams? Can't really check a router from here, but I saw (for instance) Verio mentioned. I am certain as2914 runs a 24/7 NOC and is responsive. -- TTFN, patrick
Re: Potential Prefix Hijack
Hi! We were hijacked aswell, by 27664 16735 Our affected prefixes were: 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. The obviously were leaking full routing, are we all gonna annnounce 'my prefix was in there also?' Bye, Raymond.
Re: Potential Prefix Hijack
Howdy, We were hijacked aswell, by 27664 16735 Our affected prefixes were: 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. In the meanwhile, there are lots of evidence spread around (thanks to RIS RIPE, Routeviews, BGPmon and others) http://www.ris.ripe.net/dashboard/27664 http://www.ris.ripe.net/dashboard/16735 In the meanwhile we are sending notices to the Upstreams of those ASN's, in order for them to apply proper filtering to their downstream customers to avoid situations like this. On the List i was able to found: AS8167 - TELESC AS6762 - SEABONE AS12956 - TELEFONICA AS3549 - GLOBAL CROSSING AS17379 - Interlig I welcome others to do the same, in order to avoid replicas for this situation. Regards, --- Nuno Vieira nfsi telecom, lda. [EMAIL PROTECTED] Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - "Network Fortius" <[EMAIL PROTECTED]> wrote: > Same problems here, for AS26028 > Stefan > > On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka > <[EMAIL PROTECTED]>wrote: > > > Hi all. > > > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > > > e.g., > > > > > > Possible Prefix Hijack (Code: 11) > > 1 number of peer(s) detected this updates for your prefix > > 61.11.208.0/20: > > Update details: 2008-11-11 02:24 (UTC) > > 61.11.208.0/20 > > Announced by: AS16735 (Companhia de Telecomunicacoes do > > Brasil Central) > > Transit AS: 27664 (CTBC Multimídia) > > ASpath: 27664 16735 > > = > > > > RIPE's RIS BGPlay confirms the same, for about the last > > hour. > > > > E-mails to them won't get there (of course), so our NOC are > > contacting them via Gmail/Yahoo. > > > > All help appreciated. > > > > Cheers, > > > > Mark. > >
Re: Potential Prefix Hijack
> > On Tue, 11 Nov 2008, Mark Tinka wrote: > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). > > Have you tried CERT-BR? Uh... I was about to say "they're usually very > responsive, and good at coordinating this sort of thing." And then their > web site failed to load, because the prefix it's in is flapping. Hm. > > Fred, you still awake? > > -Bill > > Odd, we were just hijacked too, one match to the same AS: Prefix: 64.193.164.0/24 AS Path: 27664 16735 Seen by Route Collector: 15 Peer IP: 200.219.130.21 Peer AS Number: 27664 Timestamp (GMT): 1:56, Nov 11 2008 And a match from other AS's Prefix: 192.136.64.0/24 AS Path: 22548 16735 Seen by Route Collector: 15 Peer IP: 200.160.0.130 Peer AS Number: 22548 Timestamp (GMT): 1:59, Nov 11 2008 Prefix: 64.193.164.0/24 AS Path: 22548 16735 Seen by Route Collector: 15 Peer IP: 200.160.0.130 Peer AS Number: 22548 Timestamp (GMT): 1:56, Nov 11 2008 Tuc
RE: Potential Prefix Hijack
We too saw this issue. 2008-11-11 01:56:36 GMT they took over one of our /20's ... Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: [EMAIL PROTECTED] web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 > -Original Message- > From: Mark Tinka [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 11, 2008 2:54 AM > To: nanog@nanog.org > Subject: Potential Prefix Hijack > > Hi all. > > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > e.g., > > > Possible Prefix Hijack (Code: 11) > 1 number of peer(s) detected this updates for your prefix > 61.11.208.0/20: > Update details: 2008-11-11 02:24 (UTC) > 61.11.208.0/20 > Announced by: AS16735 (Companhia de Telecomunicacoes do > Brasil Central) > Transit AS: 27664 (CTBC Multimdia) > ASpath: 27664 16735 > = > > RIPE's RIS BGPlay confirms the same, for about the last > hour. > > E-mails to them won't get there (of course), so our NOC are > contacting them via Gmail/Yahoo. > > All help appreciated. > > Cheers, > > Mark. >
