Re: BCP38 tester?
On 3/31/13, Karl Auer ka...@biplane.com.au wrote: On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote: In message 1364787851.2136.7.camel@karl, Karl Auer writes: A side effect of NAT is to clamp the source address range It depends on how the nat is configured. OK - how does one configure NAT so that the source addresses of outbound packets are NOT clamped to a configured range on the outside of the NAT device? Given this general scenario, of course: He said it depends on how NAT is configured; but really, before it depends on that -- it first depends on what kind of device is used, and what kind of NAT is being implemented. In some implementations, only certain ranges of source IP addresses are subject to translation.They might be NAT'ing based on network, interface, or access-list. Inside Outside Nasty spoofing scum NAT --- helpless victims Outbound --- It occurs that if the CPE are /truly/ clamping the Source address space, then essence, BCP38 is essentially happening at the CPE. If your packet source address is clamped, then, by definition a host can't spoof a packet, right; so maybe that's not a host that needs to be tested further (the upstream provider might still have no BCP38, it's just not exposed to that particular host). Unless, of course, there are protocols your NAT device passes unaltered such as possibly ICMP, or ICMPv6, in case NAT only applies to IPv4, a host behind the NAT might still be able to spoof IPv6 source addresses. -- -JH
Re: BCP38 tester?
On Apr 1, 2013, at 1:31 PM, Jimmy Hess wrote: If your packet source address is clamped, then, by definition a host can't spoof a packet, right; so maybe that's not a host that needs to be tested further (the upstream provider might still have no BCP38, it's just not exposed to that particular host). Folks should implement anti-spoofing southbound of their NATs, using uRPF, ACLs, IP Source Guard, Cable IP Source Verify, or whatever, in order to keep botted hosts attempting to launch outbound/crossbound spoofed DDoS attacks (such as spoofed SYN-floods) from filling up the NAT translation-table and making it fall over, thus creating an outage for everything behind the NAT. I've seen this happen many times, especially in the mobile/fixed wireless space. Likewise, they should implement anti-spoofing northbound, eastbound, and westbound of the NAT (eastbound and westbound assume it's a network of some scope), so that nothing else on their networks can send spoofed packets to external networks. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38 tester?
On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote: On 3/31/13, Karl Auer ka...@biplane.com.au wrote: OK - how does one configure NAT so that the source addresses of outbound packets are NOT clamped to a configured range on the outside of the NAT device? Given this general scenario, of course: He said it depends on how NAT is configured [...] In some implementations, only certain ranges of source IP addresses are subject to translation. Um - if no address translation takes place, then, by definition, NAT has not taken place. So it may well be that a particular device, capable of doing NAT and other things, of NATting some packets but not others, may permit spoofed-because-not-NATted outbound packets, but I remain unconvinced that a spoofed packet can make it through a NAT process and head outbound without getting its source address clamped to a configured range of outside addresses. Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast? Continuing to seek enlightenment... Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Re: BCP38 tester?
On Apr 1, 2013, at 3:02 PM, Karl Auer wrote: Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast? Sure - you just have rules in place which map the destination IPs of incoming packets, based upon classification criteria expressed in the NAT config, to the destination address(es) of choice. Those who ill-advisedly run servers behind NATs use this functionality. You can also turn a NAT with this type of configuration 'upside-down', so that the 'public' side is nearest the traffic sources, if desired. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38 tester?
On 4/1/13, Karl Auer ka...@biplane.com.au wrote: So it may well be that a particular device, capable of doing NAT and other things, of NATting some packets but not others, may permit Yes. Many NAT devices of reasonable quality are fully capable of such things. And skipping NAT or NAT'ing the source IP address on the outgoing interface to the same as the source IP address the packet had on the incoming interface,is the likely default, when NAT has been configured based on source IP address range, on some devices. spoofed-because-not-NATted outbound packets, but I remain unconvinced that a spoofed packet can make it through a NAT process and head outbound without getting its source address clamped to a configured range of outside addresses. Ah, but did you actually test your guess on a reasonably large variety of NAT platforms? It just takes 1 instance of the right platform to be in significant use for something to be different than expected. I remain unconvinced that all CPEs in all common configurations will clamp the source address to a legitimate one in all cases. It would just be way too much luck and convenience for that to happen by coincidence. Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast? Of course there is... in some implementations you may need two NAT rules to define a 1:1; a source NAT rule, and a destination NAT rule; if you define only the Source NAT rule, you just translate the source IP address ranges selected to the translation IP address range(s) selected for outgoing connections, and new incoming connections are not translated; if you define only the DNAT rule, you translate only the WAN interface destination IP for incoming connections, and outgoing connections are not translated. In various implementations you can have full-cone NAT, address-restricted cone NAT, port-restricted cone NAT, symmetric NAT, and various combinations and variations (even different kinds of NAT in different directions), for each of source and destination address, with or without storage of a mapping for return traffic. Different source or destination IP ranges or TCP/UDP ports might be NAT'ed differently or not at all. Not all implementations allow all possible useful NAT configurations. Continuing to seek enlightenment... Regards, K. -- -JH
Re: BCP38 tester?
On 04/01/13 04:02, Karl Auer wrote: On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote: On 3/31/13, Karl Auer ka...@biplane.com.au wrote: OK - how does one configure NAT so that the source addresses of outbound packets are NOT clamped to a configured range on the outside of the NAT device? Given this general scenario, of course: He said it depends on how NAT is configured [...] In some implementations, only certain ranges of source IP addresses are subject to translation. Um - if no address translation takes place, then, by definition, NAT has not taken place. So it may well be that a particular device, capable of doing NAT and other things, of NATting some packets but not others, may permit spoofed-because-not-NATted outbound packets, but I remain unconvinced that a spoofed packet can make it through a NAT process and head outbound without getting its source address clamped to a configured range of outside addresses. Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast? Continuing to seek enlightenment... Regards, K. While I was reading this... thinking that a NAT is a NAT is a NAT... ( I spend some time writing/porting NAT code in my youth ) I'm sad to confirm that my spoof test was successful with a: . SageMCom modem+router, which is used by a big TelCo around my part, for both their residential and commercial ADSL2+, VDSL customers. . 4 well know Tier-2(?) provider :( why I'm wasting time filling up paper LoA if its only going to be used for BGP. But on the other hand... it failed on a: . Cisco (*cought* LinkSys) WRT54G loaded with DD-WRT v2.4-sp2 micro (2010/10/09); . SonicWall 2040 with 4.2.1.3; . Thompson SpeedTouch 516; ( I'm looking around for more CPE I could use, for testing =D ) PS: I'm not promoting the listed vendor, products. Its only a quick test with what I had on my hand during breakfast. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443
Re: BCP38 tester?
I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives. On Mar 31, 2013 6:37 PM, Jason Lixfeld ja...@lixfeld.ca wrote: On 2013-03-31, at 10:48 AM, Jay Ashworth j...@baylink.com wrote: Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering? I'm hoping for something that could be downloaded by users and run, and try to forge a few packets to somewhere useful, which could be logged somehow in conjunction with some unforged packets containing a traceroute, so we could build up a database of leaky networks. On a related topic, while I know GRC Research's Steve Gibson is a bit of a polarizing personality, he does have a fairly sizable consumer audience, and might be a great distribution venue for such a thing. Or, perhaps, is there someone on here from Ookla? Patrick? Could Akamai be persuaded to take an interest in this as a research project? From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period. Most network operators are probably either too inexperienced to understand or too lazy to care. I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?
Re: BCP38 tester?
On Sun, Mar 31, 2013 at 6:50 PM, Jason Lixfeld ja...@lixfeld.ca wrote: Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets. I guess I can see that. You then have a question of implementation. Wouldn't a majority of those customers have a bridged connection with the providers CPE being a transparent bridged modem. So either a customer's cheap router (good luck getting those guys to add a feature) would have to do the check, or the modem would have to check with the router for ip and then do packet inspection. I'm not debating that this would be a good fix and eliminate the effect of botnets, but the home router market isn't going to be influenced by providers. If it sells at a big box electronics store, it will be in circulation. It seems that the only people who would care at the home networking level aren't likely to be contributing to the botnets. On the other hand, any ISP that would want this as a feature in their modems, would find it easier to implement on commercial hardware. It would work and it's a good idea, I just don't see it gaining traction in the right places to be effective. The answer still rests with providers.
Re: BCP38 tester?
On 2013-03-31 08:48, Jay Ashworth wrote: Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering? I don't have a canned solution, but I've had good luck testing with nmap (-S and -e are relevant) while running tcpdump (and filtering for the protocols/ports) on a remote host. I can happily report that someplace upstream of my home connection is doing some filtering -- nice. I still need to test at work. Jima
Re: Open Resolver Problems
On Mar 31, 2013, at 11:16 PM, valdis.kletni...@vt.edu wrote: On Sun, 31 Mar 2013 16:09:35 -0500, Jimmy Hess said: On 3/29/13, Scott Noel-Hemming frogstar...@gmail.com wrote: Some of us have both publicly-facing authoritative DNS, and inward facing recursive servers that may be open resolvers but can't be found via NS entries (so the IP addresses of those aren't exactly publicly available info). Sounds like your making the faulty assumption that an attacker would use normal means to find your servers. A distributed scan of the entire IPv4 SNIP Stop right there. Anybody who is looking at this as an IPv4 issue is woefully misinformed about the nature of the problem. :) IPv4 it's easy to collect an inventory (the math works). IPv6, not nearly as easy. - Jared
Re: BCP38 tester?
Hi, http://spoofer.csail.mit.edu/ is really the best place to certify for BCP38. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 04/01/13 00:36, Jima wrote: On 2013-03-31 08:48, Jay Ashworth wrote: Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering? I don't have a canned solution, but I've had good luck testing with nmap (-S and -e are relevant) while running tcpdump (and filtering for the protocols/ports) on a remote host. I can happily report that someplace upstream of my home connection is doing some filtering -- nice. I still need to test at work. Jima
Re: BCP38 tester?
On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said: I'm sad to confirm that my spoof test was successful with a: . SageMCom modem+router, which is used by a big TelCo around my part, for both their residential and commercial ADSL2+, VDSL customers. You might want to check more carefully exactly what the failure mode was. I'm willing to bet that the router has been configured to assign addresses inside a specific RFC 1918 /24, and will do Something Terrible to spoofed packets in that range, but will figure you know what you're doing and pass them if you source a packet from outside that /24. pgpTY4rY2IPoZ.pgp Description: PGP signature
Re: Open Resolver Problems
On Mar 31, 2013, at 8:46 PM, Jared Mauch wrote: Many thanks to everyone that is treating this as a critical issue to close these hosts. Just back to the office, and started checking my networks. Found one of the resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware available. Anyone have any feeling for what percentage are these types of boxes? --Chris
Re: BCP38 tester?
On 04/01/13 10:09, valdis.kletni...@vt.edu wrote: On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said: I'm sad to confirm that my spoof test was successful with a: . SageMCom modem+router, which is used by a big TelCo around my part, for both their residential and commercial ADSL2+, VDSL customers. You might want to check more carefully exactly what the failure mode was. I'm willing to bet that the router has been configured to assign addresses inside a specific RFC 1918 /24, and will do Something Terrible to spoofed packets in that range, but will figure you know what you're doing and pass them if you source a packet from outside that /24. My test script is very very very basic... but passes. And as per spoofer.csail, which is way more comprehensive in its testing. CPE tested with spoofer this morning. For the SageMCom 2864 with FAST2864_v6740S firmware: Received (at MIT AS3): 1.2.3.4 | x.x.x.x | The IANA unalloced source was successfully received. 6.1.2.3 | x,x,x,x | The spoofed packets were successfully received. There is no ingress or egress source filtering on your network for this IP address. Your host can spoof 16777215 neighboring addresses (within your /8 prefix) For the SpeedTouch 516: Received (at MIT AS3): 1.2.3.4 | x.x.x.x | Source address rewrite. The source address of the probe packets we received differs from the original address. It appears that a Network Address Translation (NAT) device is rewriting your packet headers. 6.1.2.3 | x.x.x.x | same 172.16.1.100 | x.x.x.x | same Your host can spoof 0 neighboring addresses (within your /32 prefix) ^ the /32 is a bit confusing. PS: This was just a few empirical tests and is in no way, shape, or form, a judgement about the quality of the devices tested. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443
AS1239 AS701 IP Transit sales folks
If there are any IP Transit sales folks[1] listening form Sprint or Verizon, please drop me a line off-list. Thanks. [1] No resellers, please.
Re: Open Resolver Problems
On Mon, Apr 1, 2013 at 7:35 AM, Chris Boyd cb...@gizmopartners.com wrote: On Mar 31, 2013, at 8:46 PM, Jared Mauch wrote: Many thanks to everyone that is treating this as a critical issue to close these hosts. Just back to the office, and started checking my networks. Found one of the resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware available. Anyone have any feeling for what percentage are these types of boxes? A lot? :-/ - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: Open Resolver Problems
On Mon, 1 Apr 2013, Chris Boyd wrote: Just back to the office, and started checking my networks. Found one of the resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware available. Anyone have any feeling for what percentage are these types of boxes? If you buy type of box mean small SOHO NAT router which does DNS resolving on the WAN interface then I'd say a lot. Someone does a rollout of new software and configuration and happens to mess up the config file (or the vendor just happens to enable global dns resolving in the new software) and this slips through testing, then you're there. I believe this happens all the time. That's why the publication of these lists are important, in a lot of cases there are a lot of people who are simply not aware of these devices doing this, and they need to be poked to notice. -- Mikael Abrahamssonemail: swm...@swm.pp.se
FW: Open Resolver Problems
Most of our DSL customers have modem/routers that resolve DNS externally. And most of those have no configuration option to stop it. So, we took the unfortunate step of ACL blocking DNS requests to from the DSL network unless the requests are to our DNS servers. Suboptimal, but it stopped the DNS amplification attacks. -Original Message- From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] Sent: Monday, April 01, 2013 11:51 AM To: Chris Boyd Cc: nanog@nanog.org Subject: Re: Open Resolver Problems On Mon, 1 Apr 2013, Chris Boyd wrote: Just back to the office, and started checking my networks. Found one of the resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware available. Anyone have any feeling for what percentage are these types of boxes? If you buy type of box mean small SOHO NAT router which does DNS resolving on the WAN interface then I'd say a lot. Someone does a rollout of new software and configuration and happens to mess up the config file (or the vendor just happens to enable global dns resolving in the new software) and this slips through testing, then you're there. I believe this happens all the time. That's why the publication of these lists are important, in a lot of cases there are a lot of people who are simply not aware of these devices doing this, and they need to be poked to notice. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Open Resolver Problems
On Apr 01, 2013, at 11:55 , Milt Aitken m...@net2atlanta.com wrote: Most of our DSL customers have modem/routers that resolve DNS externally. And most of those have no configuration option to stop it. So, we took the unfortunate step of ACL blocking DNS requests to from the DSL network unless the requests are to our DNS servers. Suboptimal, but it stopped the DNS amplification attacks. I was going to suggest exactly this. Don't most broadband networks have a line in their AUP about running servers? Wouldn't a DNS server count as 'a server'? Then wouldn't running one violate the AUP? This gives the provider a hammer to hit the user over the head. Although that is quite unlikely, so the better point is that it also gives the provider cover in case some user complains about the provider filtering. You can always make an exception if the user is extremely loud. -- TTFN, patrick -Original Message- From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] Sent: Monday, April 01, 2013 11:51 AM To: Chris Boyd Cc: nanog@nanog.org Subject: Re: Open Resolver Problems On Mon, 1 Apr 2013, Chris Boyd wrote: Just back to the office, and started checking my networks. Found one of the resolvers is a Netgear SOHO NAT box. EoL'd, no new firmware available. Anyone have any feeling for what percentage are these types of boxes? If you buy type of box mean small SOHO NAT router which does DNS resolving on the WAN interface then I'd say a lot. Someone does a rollout of new software and configuration and happens to mess up the config file (or the vendor just happens to enable global dns resolving in the new software) and this slips through testing, then you're there. I believe this happens all the time. That's why the publication of these lists are important, in a lot of cases there are a lot of people who are simply not aware of these devices doing this, and they need to be poked to notice. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Open Resolver Problems
On Apr 1, 2013, at 11:03 PM, Patrick W. Gilmore wrote: You can always make an exception if the user is extremely loud. It might be a good idea to make pinholes for the Google and OpenDNS recursors, as they're fairly popular. I agree that this is a good idea, similar to the same sort of network access policy as relates to SMTP. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
On Apr 01, 2013, at 12:09 , Dobbins, Roland rdobb...@arbor.net wrote: On Apr 1, 2013, at 11:03 PM, Patrick W. Gilmore wrote: You can always make an exception if the user is extremely loud. It might be a good idea to make pinholes for the Google and OpenDNS recursors, as they're fairly popular. I agree that this is a good idea, similar to the same sort of network access policy as relates to SMTP. Ahhh, silly of me, I read the post form Milt too quickly. I was going to suggest queries _into_ the broadband user space, not out of. If you only block into, OpenDNS, GoogleDNS, etc. are not an issue. Blocking could be done with DPI. It can also be done by blocking UDP port 53. (Don't need to block TCP53 since that removes the amplification problem.) However, there are some (idiotic) name servers that do 5353. Not sure how to handle those, or more importantly, how many broadband customers legitimately use an off-net _and_ brain-dead name server? And even if they do, will they fall back to TCP? Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) -- TTFN, patrick
Re: BCP38 tester?
- Original Message - From: Karl Auer ka...@biplane.com.au On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote: This thought crossed my mind earlier today, when I asked Jeff if IP-forged packets would make it through a NAT, outbound. He said no (I think), but I'm not entirely sure that's right. Welll - the packets might make it out, and be transmitted into the Internet, but they would have a legitimate source address, namely an outside address of the NAT router. A side effect of NAT is to clamp the source address range of outbound packets to the configured NAT outside address range. D'oh. Of course. Hmmm. That says things about the penetration of NAT routers at consumer eyeball connections vs. directly connected PCs that surprise me. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: BCP38 tester?
- Original Message - From: Jimmy Hess mysi...@gmail.com Ah, but did you actually test your guess on a reasonably large variety of NAT platforms? He may not have, but now that I'm thinking (caffeine is a wonder drug), I have: I've worked on, for customers, nearly every brand of consumer router on the market, and all of them do outbound NAT the same way: Pick up a DHCP address from the carrier, and use that as the source IP on all translated outbound packets. I have never found anything for which that's *not* the default config. Upscale things like Snapgears, and routers running -WRT or Tomato, etc, can be configured to do other things, but even on those, that's the default config for outbound NAT. It just takes 1 instance of the right platform to be in significant use for something to be different than expected. Sure, but the question here is is it reasonable to think that the *magnitude* of the problem is substantially reduced because consumer NAT routers are doing much of the work for us and that answer is decidedly yes, it is. Sure, it's egress filtering, and a bad actor can get around it, if only by *not using a router*. But a *trojan* likely cannot, and that helps us a lot too; 4-6 orders of magnitude, depending on your opinion of the penetration of consumer edge routers. I remain unconvinced that all CPEs in all common configurations will clamp the source address to a legitimate one in all cases. All? Yeah, probably not. But I think we're getting 99%, and you know what? I'll take that. It would just be way too much luck and convenience for that to happen by coincidence. Once in a while, you win. Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast? Of course there is... in some implementations you may need two NAT rules to define a 1:1; a source NAT rule, and a destination NAT rule; if you define only the Source NAT rule, you just translate the source IP address ranges selected to the translation IP address range(s) selected for outgoing connections, and new incoming connections are not translated; if you define only the DNAT rule, you translate only the WAN interface destination IP for incoming connections, and outgoing connections are not translated. In various implementations you can have full-cone NAT, address-restricted cone NAT, port-restricted cone NAT, symmetric NAT, and various combinations and variations (even different kinds of NAT in different directions), for each of source and destination address, with or without storage of a mapping for return traffic. Different source or destination IP ranges or TCP/UDP ports might be NAT'ed differently or not at all. Not all implementations allow all possible useful NAT configurations. And the majority, by implementation count, don't allow *any* of those. They allow outbound-SNAT, and configurable inbound-DNAT, maybe. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Open Resolver Problems
For filtering to/from client-only networks, here's the filtering rules (in pseudo-code, convert to appropriate code for whatever devices you operate), for DNS. The objective here is: - prevent spoofed-source DNS reflection attacks from your customers, from leaving your network - prevent your customers' open DNS servers (regardless of what they are) from being used in reflection attacks - permit normal DNS usage by clients, regardless of whether they are talking to an external DNS resolver, or doing their own local resolution (e.g. local DNS resolver on a host, or SOHO router) from client: permit source=client-subnet dest=any port=53 proto=TCP (TCP only works if reaches established, i.e. spoofing is irrelevant, but we stop spoofed SYN here) permit source=client-subnet dest=any port=53 proto=UDP QR=0 (first/highest bit of 3rd octet of DNS packet payload of UDP) deny port=53 (regardless of source/dest - either spoofed source, or QR=1, if reached this rule) to client: permit dest=any source=any port=53 proto=TCP permit dest=any source=any port=53 QR=1 (first/highest bit of 3rd octet of DNS packet payload of UDP) deny port=53 proto=UDP (QR=0 which is what we want to avoid) (We don't have to check dest==client-subnet, since routing handles this requirement) If you have eyeball networks, please apply liberally. Brian
Re: Open Resolver Problems
On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote: Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) ; It's easy enough to construct ACLs to restrict the broadband consumer access networks from doing so. Additional egress filtering would catch any reflected attacks, per your previous comments. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: alexandria cable cutters?
On Mar 28, 2013, at 2:17 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: - Welding Gear is expensive, underwater gear is insanely expensive. - Welding is pretty difficult.. - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water. ...going after a specific cable with a welder sounds like someone had a real reason. ...the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant Warren: I think I missed a step here. Where is the reference to the welding equipment coming from? The photos show three scuba tanks and a float. I don't see any mention of welding equipment in the NYT or Guardian pieces, or in the Egyptian Navy's statement or photos. -Bill
Re: alexandria cable cutters?
This was in reply to a posting that brought up the possible usage of a Thermal Lance. On 4/1/13 9:55 AM, Bill Woodcock wo...@pch.net wrote: On Mar 28, 2013, at 2:17 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: - Welding Gear is expensive, underwater gear is insanely expensive. - Welding is pretty difficult.. - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water. ...going after a specific cable with a welder sounds like someone had a real reason. ...the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant Warren: I think I missed a step here. Where is the reference to the welding equipment coming from? The photos show three scuba tanks and a float. I don't see any mention of welding equipment in the NYT or Guardian pieces, or in the Egyptian Navy's statement or photos. -Bill
Re: alexandria cable cutters?
Thermal Lances can be started with various heat sources. Some are self contained for emergency use. On Mon, Apr 1, 2013 at 1:04 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: This was in reply to a posting that brought up the possible usage of a Thermal Lance. On 4/1/13 9:55 AM, Bill Woodcock wo...@pch.net wrote: On Mar 28, 2013, at 2:17 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: - Welding Gear is expensive, underwater gear is insanely expensive. - Welding is pretty difficult.. - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water. ...going after a specific cable with a welder sounds like someone had a real reason. ...the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant Warren: I think I missed a step here. Where is the reference to the welding equipment coming from? The photos show three scuba tanks and a float. I don't see any mention of welding equipment in the NYT or Guardian pieces, or in the Egyptian Navy's statement or photos. -Bill -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
GlobalCrossing looking glass problem
Hi all, Someone is getting access to the GlobalCrossing the looking glass? # telnet route-server.gblx.net Trying 67.17.81.28... telnet: connect to address 67.17.81.28: Connection refused Thanks. -- Eduardo Schoedler
Re: Open Resolver Problems
- Original Message - From: Roland Dobbins rdobb...@arbor.net On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote: Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) ; It's easy enough to construct ACLs to restrict the broadband consumer access networks from doing so. Additional egress filtering would catch any reflected attacks, per your previous comments. So, how would Patrick's caveat affect me, whose recursive resolver *is on my Linux laptop*? Would not that recursor be making queries he advocates blocking? Or don't I remember DNS well enough? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Open Resolver Problems
On Mon, 01 Apr 2013 14:19:16 -0400, Jay Ashworth said: So, how would Patrick's caveat affect me, whose recursive resolver *is on my Linux laptop*? Would not that recursor be making queries he advocates blocking? You're sending queries, not replies. That's why DPI is needed to do the blocking, rather than just by port. pgpbFCCcuzApr.pgp Description: PGP signature
RE: GlobalCrossing looking glass problem
The route-server is accessible again. Sorry for the inconvenience. Dave -Original Message- From: Eduardo Schoedler [mailto:lis...@esds.com.br] Sent: Monday, April 01, 2013 12:07 PM To: NANOG Subject: GlobalCrossing looking glass problem Hi all, Someone is getting access to the GlobalCrossing the looking glass? # telnet route-server.gblx.net Trying 67.17.81.28... telnet: connect to address 67.17.81.28: Connection refused Thanks. -- Eduardo Schoedler
Re: Open Resolver Problems
Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu On Mon, 01 Apr 2013 14:19:16 -0400, Jay Ashworth said: So, how would Patrick's caveat affect me, whose recursive resolver *is on my Linux laptop*? Would not that recursor be making queries he advocates blocking? You're sending queries, not replies. That's why DPI is needed to do the blocking, rather than just by port. Aha. Right. Got it. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Open Resolver Problems
On Mon, 1 Apr 2013, valdis.kletni...@vt.edu wrote: You're sending queries, not replies. That's why DPI is needed to do the blocking, rather than just by port. What queries are sourced from port 53 nowadays? I'd imagine it's pretty safe to block Internet-customer UDP/53 packets. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Open Resolver Problems
On 2013-04-01, at 14:19, Jay Ashworth j...@baylink.com wrote: From: Roland Dobbins rdobb...@arbor.net On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote: Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) ; It's easy enough to construct ACLs to restrict the broadband consumer access networks from doing so. Additional egress filtering would catch any reflected attacks, per your previous comments. So, how would Patrick's caveat affect me, whose recursive resolver *is on my Linux laptop*? Would not that recursor be making queries he advocates blocking? The badness that Patrick is talking about blocking are DNS responses being sent from consumer devices to the Internet, answering DNS queries being sent from the Internet towards consumer devices. (I think. This thread is sufficiently circular that I feel a bit dizzy, and could be mistaken.) The DNS traffic outbound from your laptop will be DNS queries (not responses) and the inbound traffic will be DNS responses (not queries). The traffic profiles are different. The case where infected consumer devices originate source-spoofed queries towards open resolvers, feeding a query stream to an amplifier for delivery to a victim, is mitigated by preventing those consumer devices from spoofing their source address, so BCP38. The case where infected consumer devices originate non-source-spoofed queries towards DNS servers in order to overwhelm the servers themselves with perfectly legitimate-looking queries is a harder problem to solve at the edge, and is most easily mitigated for DNS server operators by the approach ensure great headroom. Joe
Re: Open Resolver Problems
On 1 Apr 2013, at 14:44, Jared Mauch ja...@puck.nether.net wrote: On Mar 31, 2013, at 11:16 PM, valdis.kletni...@vt.edu wrote: Anybody who is looking at this as an IPv4 issue is woefully misinformed about the nature of the problem. :) IPv4 it's easy to collect an inventory (the math works). IPv6, not nearly as easy. You should be able to get a reasonable sample of IPv6 resolvers from the query logs of a popular authoritative server. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/
RE: BCP38 tester?
The good news is that source address spoofing does seem to fail with most CPE's NAT. At the end of the day, just turn on uRPF and/or use ACLs. It's amazing how much destination 192.168.0.0/24 and 192.168.1.0/24 our ACLs also block. Frank -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Sunday, March 31, 2013 9:35 PM To: NANOG Subject: Re: BCP38 tester? - Original Message - From: Alain Hebert aheb...@pubnix.net An easy target would be anti-virus/trojan/security software providers that could add a BCP38 check to their software =D Yes, but penetration is a problem, which is why I was thinking about people like YouTube, Ookla, and the like. Any Flash app that lots of people run frequently. Assuming those apps could generate the packets, which, on reflection, I would bet they can't. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Open Resolver Problems
On Mon, 01 Apr 2013 19:40:03 +0100, Tony Finch said: You should be able to get a reasonable sample of IPv6 resolvers from the query logs of a popular authoritative server. Hopefully, said logs are not easily accessible to the miscreants. (I still expect the most feasible method for the miscreants is to start a botnet and see what boxes get handed an IPv6 DNS via dhcp6). pgpOO4C6N9fev.pgp Description: PGP signature
Re: alexandria cable cutters?
On Mon, Apr 1, 2013 at 1:08 PM, Andrew Latham lath...@gmail.com wrote: Thermal Lances can be started with various heat sources. Some are self contained for emergency use. either way, there's no mention of such a device in the reporting... or picts. right? On Mon, Apr 1, 2013 at 1:04 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: This was in reply to a posting that brought up the possible usage of a Thermal Lance. On 4/1/13 9:55 AM, Bill Woodcock wo...@pch.net wrote: On Mar 28, 2013, at 2:17 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: - Welding Gear is expensive, underwater gear is insanely expensive. - Welding is pretty difficult.. - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water. ...going after a specific cable with a welder sounds like someone had a real reason. ...the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant Warren: I think I missed a step here. Where is the reference to the welding equipment coming from? The photos show three scuba tanks and a float. I don't see any mention of welding equipment in the NYT or Guardian pieces, or in the Egyptian Navy's statement or photos. -Bill -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: Open Resolver Problems
On 4/1/13 11:59 AM, valdis.kletni...@vt.edu wrote: On Mon, 01 Apr 2013 19:40:03 +0100, Tony Finch said: You should be able to get a reasonable sample of IPv6 resolvers from the query logs of a popular authoritative server. Hopefully, said logs are not easily accessible to the miscreants. Miscreants with popular zones clearly can do that. Reverse-lookups for spam originating machines might for example be a sufficient source of queries if you control the reverse zone. The DNS makes it's own gravy. (I still expect the most feasible method for the miscreants is to start a botnet and see what boxes get handed an IPv6 DNS via dhcp6).
Re: Open Resolver Problems
On Apr 01, 2013, at 11:55 , Milt Aitken m...@net2atlanta.com wrote: Most of our DSL customers have modem/routers that resolve DNS externally. And most of those have no configuration option to stop it. So, we took the unfortunate step of ACL blocking DNS requests to from the DSL network unless the requests are to our DNS servers. Suboptimal, but it stopped the DNS amplification attacks. Wow. Glad I'm not a customer of yours. * patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:04 CEST]: I was going to suggest exactly this. Don't most broadband networks have a line in their AUP about running servers? Huh? No. Thankfully. Not all of us are mindless consumers. -- Niels.
Re: Open Resolver Problems
* patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]: Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) You're joking, right? Should they also use only the telco-approved search engine, via the telco-hosted portal? -- Niels.
Re: Open Resolver Problems
On Apr 1, 2013, at 4:19 PM, Niels Bakker niels=na...@bakker.net wrote: On Apr 01, 2013, at 11:55 , Milt Aitken m...@net2atlanta.com wrote: Most of our DSL customers have modem/routers that resolve DNS externally. And most of those have no configuration option to stop it. So, we took the unfortunate step of ACL blocking DNS requests to from the DSL network unless the requests are to our DNS servers. Suboptimal, but it stopped the DNS amplification attacks. Wow. Glad I'm not a customer of yours. I would say this is the wrong solution. Prevent your customers from spoofing is the first step, then ask them to fix their broken CPE. If NETGEAR is listening on the WAN side vs the LAN/INSIDE they need to step up and issue fixed firmware, even if the device is older. Should be a simple fix. * patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:04 CEST]: I was going to suggest exactly this. Don't most broadband networks have a line in their AUP about running servers? Huh? No. Thankfully. Not all of us are mindless consumers. I think it's easier to just classify an open-resolver similar to an open-relay without having to invoke the consumer mindset. - Jared
Re: Open Resolver Problems
* ja...@puck.nether.net (Jared Mauch) [Mon 01 Apr 2013, 22:24 CEST]: I would say this is the wrong solution. Prevent your customers from spoofing is the first step, then ask them to fix their broken CPE. I daresay that after ten years of discussion NANOG has reached consensus that implementing BCP38 is a good thing and that all networks should be encouraged to do so. Net neutrality has not been discussed completely to death yet but I'm pretty confident in stating that squeezing consumer connections further down each time some blog hypes up yet another The Internet is melting! threat won't scale. If NETGEAR is listening on the WAN side vs the LAN/INSIDE they need to step up and issue fixed firmware, even if the device is older. Should be a simple fix. I don't think anybody would disagree with this statement. Netgear did get into action when they DDoS'ed a university's NTP servers; perhaps similar sticks can be shaken in this case. (Is Netgear one of the brands involved? Usually they're better. Pardon me for not reading the whole thread and the other five) I think it's easier to just classify an open-resolver similar to an open-relay without having to invoke the consumer mindset. Two posts up in this thread we were talking about net-wide blocks without individual proof of open relay or equivalent status. -- Niels.
Eastern Canadian Wireless ISP Resources
All: I am seeking a wireless internet service provider to help with an off-shore project on the eastern coast of Canada. I am seeking to pump up to 400 GB per day back to shore from vessels at sea. Are there any wireless operators on this list that may be able to steer me in the right direction? Sincerely, Lorell Hathcock
NAPA link from Latin America
hello all, would like to politely ask if there are any folks from the NAPA here. Would you be so kind as to contact me off-list. many thanks, -Beavis -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/
Re: Eastern Canadian Wireless ISP Resources
Lorell, Try wispa.org. They also have a mailing list you can join (like NANOG) and you can post there to see if there are any operators over in those neck of the woods. How far off of the coast are the stations? -Mike Lyon On Mon, Apr 1, 2013 at 2:39 PM, Lorell Hathcock lor...@hathcock.org wrote: All: I am seeking a wireless internet service provider to help with an off-shore project on the eastern coast of Canada. I am seeking to pump up to 400 GB per day back to shore from vessels at sea. Are there any wireless operators on this list that may be able to steer me in the right direction? Sincerely, Lorell Hathcock -- Mike Lyon 408-621-4826 mike.l...@gmail.com http://www.linkedin.com/in/mlyon
Providers with RTBH capability?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, team. Apologies to those of you seeing this in multiple forums. I'm looking for a list of transit providers who have well-supported, customer-enabled (not ring the NOC) RTBH [0][1] capability. I'm not yet looking for sales calls, just the facts, please. If you are one of those providers, or you've had a good experience with providers with RTBH capability, please let me know. Off-list replies are fine, and I'm happy to summarize once I've assembled the list. [0] http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd80313fac.pdf [1] http://tools.ietf.org/html/rfc5635 Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru https://www.team-cymru.org/ Say little and do much. M Avot 1:15 -BEGIN PGP SIGNATURE- iQCVAwUBUVoFKlkX3QAo5sgJAQLzWAP+KnDgvSQo9iXkKOpEE190DRqIu0CDP8Kh 8Lkj0Mt37vo1oIiANMVNt+JJh5g5dJSNp1vTrC4mAcFMCDEZ+ZIKDoH8aGadhbTZ IlPvODQ+ig1V94f2bD/07/hcMTbjhlFMA0nxZX3uzmVFrYTpAn1351FDOorpx2eG jlkbBZscUv4= =dxnH -END PGP SIGNATURE-
RE: Open Resolver Problems
And only the telco approved web sites are accessible, and the only protocol supported is the telco approved http and then only to port 80 ... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org -Original Message- From: Niels Bakker [mailto:niels=na...@bakker.net] Sent: Monday, 01 April, 2013 14:22 To: nanog@nanog.org Subject: Re: Open Resolver Problems * patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]: Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) You're joking, right? Should they also use only the telco-approved search engine, via the telco-hosted portal? -- Niels.
Re: BCP38 tester?
On Mon, Apr 01, 2013 at 12:31:05PM -0400, Jay Ashworth wrote: From: Jimmy Hess mysi...@gmail.com Ah, but did you actually test your guess on a reasonably large variety of NAT platforms? He may not have, but now that I'm thinking (caffeine is a wonder drug), I have: I've worked on, for customers, nearly every brand of consumer router on the market, and all of them do outbound NAT the same way: Pick up a DHCP address from the carrier, and use that as the source IP on all translated outbound packets. The key issue at hand (I believe; please correct me if I'm wrong) is that all translated outbound packets may not equal all outbound packets. Depending on how a NAT device is configured, it may pass some packets *untranslated*, and that allows a malicious actor behind the NAT device to still get their spoofed traffic out. To relate it back to something concrete, imagine this iptables rule in an otherwise fully open configuration: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wan -j MASQUERADE Now, spoof a packet from behind this NAT box as coming from 192.0.2.12... what happens? It gets passed through the NAT box, *without* being NATed. Oops. Of course, it isn't hard to stop this sort of thing... iptables -A INPUT ! -s 192.168.1.0/24 -i lan -j DROP (or any number of other equivalent rules) The question is, how many in-common-use CPEs have considered this attack vector and are actually doing something functionally equivalent to the DROP rule above? I don't know, because I haven't tried it, but I'd only be surprised if the answer was none or all of them. - Matt
New Product Launch from 2600hz
Hello, Normally I wouldn't bother the respected members of NANOG with a product launch email, but this is such a unique application that I felt it was necessary. 2600hz is saying goodbye to SMS, Voice and even Video. Today we're launching a service we'd like to call BrainRTC. It's going to completely revolutionize communications. Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-video-are-dead-heres-the-future Cheers, Joshua Joshua Goldbard VP of Marketing, 2600hz 116 Natoma Street, Floor 2 San Francisco, CA, 94104 415.886.7923 | j...@2600hz.commailto:j...@2600hz.com
Re: Open Resolver Problems
Subject: Re: Open Resolver Problems Date: Mon, Apr 01, 2013 at 10:21:42PM +0200 Quoting Niels Bakker (niels=na...@bakker.net): * patr...@ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]: Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :) You're joking, right? Should they also use only the telco-approved search engine, via the telco-hosted portal? Far too many (perhaps not Patrick) in this thread are not joking. Laughter gets stuck in my throat, as we say in Sweden. Having proper Internet access is more and more a privilege for the Internet gentry that are clued and able to pay for a box in a colo or similar. The unwashed masses are left with broadband We can't call it Internet because there are a few raving graybeards that claim they invented it and intended it to be two-way instead of stuffing .flv down peoples facebook-viewing devices while also supplanting cable TV with demand streaming. /rant What percentage of the SOHO NAT boxes actually are full-service resolvers? I was under the impression that most were mere forwarders; just pushing queries on toward the DHCP'd full service resolvers of the ISP. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Everywhere I look I see NEGATIVITY and ASPHALT ... signature.asc Description: Digital signature
Re: New Product Launch from 2600hz
--- j...@2600hz.com wrote: From: Joshua Goldbard j...@2600hz.com It's going to completely revolutionize communications. --- Ummm, yeah. Lemme know how that goes for you... scott (but not on NANOG)
Re: New Product Launch from 2600hz
Goes in the same category as this bit of news: IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly announced that IPv4 would no longer be supported on the global internet after 1/1/2014. Those wishing to continue using the internet in 2014 and beyond should move to IPv6. Owen On Apr 1, 2013, at 4:09 PM, Joshua Goldbard j...@2600hz.com wrote: Hello, Normally I wouldn't bother the respected members of NANOG with a product launch email, but this is such a unique application that I felt it was necessary. 2600hz is saying goodbye to SMS, Voice and even Video. Today we're launching a service we'd like to call BrainRTC. It's going to completely revolutionize communications. Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-video-are-dead-heres-the-future Cheers, Joshua Joshua Goldbard VP of Marketing, 2600hz 116 Natoma Street, Floor 2 San Francisco, CA, 94104 415.886.7923 | j...@2600hz.commailto:j...@2600hz.com
Speedtest Results speedtest.net vs Mikrotik bandwidth test
All: I am having some speedtest results that are difficult to interpret. I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX. I am running BGP with each with 100 Mbps+ on each link. Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results. My network is Mikrotik based and as such, I have access to Mikrotik's built-in bandwidth testing. With a laptop on site, running against speedtest.net (which kicked me over to the Comcast speedtest server instance) I can only get 4 Mbps up and 1.5 Mbps down. That is consistent on their desktops too. We eliminated their routing equipment and other consumers of the bandwidth and tested and got similar results. But when we run the Mikrotik bandwidth tests (even to off-net Mikrotik devices in Hawaii and Mission, TX) we get 25+ Mbps synchronous. We have run traceroutes to various traceroute servers and they go through Cogent and/or Level 3. For the most part it does not seem to matter which path it takes, the bandwidth seems to be about the same going both routes. When we run the laptop-based btest.exe against Mikrotik bandwidth test servers, the laptop got significantly better results (14 Mbps) , but not 25+ Mbps. It is almost like there is a Java based problem with speedtest.net. Thoughts? Thanks, Lorell Hathcock
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On Mon, 1 Apr 2013, Lorell Hathcock wrote: I am having some speedtest results that are difficult to interpret. Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results. Take the speedtest results with a grain of salt. Once traffic leaves your network, you no longer have (much) control over how packets flow across the 'rest of the internet'. Did the customers report when the issue started? Are they seeing other performance problems (latency/jitter/packet loss)? Are you sure no internal links/routers are being saturated, even for brief periods of time? jms
Re: New Product Launch from 2600hz
Haha, strange this comes out on April 1st On Mon, Apr 1, 2013 at 6:06 PM, Owen DeLong o...@delong.com wrote: Goes in the same category as this bit of news: IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly announced that IPv4 would no longer be supported on the global internet after 1/1/2014. Those wishing to continue using the internet in 2014 and beyond should move to IPv6. Owen On Apr 1, 2013, at 4:09 PM, Joshua Goldbard j...@2600hz.com wrote: Hello, Normally I wouldn't bother the respected members of NANOG with a product launch email, but this is such a unique application that I felt it was necessary. 2600hz is saying goodbye to SMS, Voice and even Video. Today we're launching a service we'd like to call BrainRTC. It's going to completely revolutionize communications. Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-video-are-dead-heres-the-future Cheers, Joshua Joshua Goldbard VP of Marketing, 2600hz 116 Natoma Street, Floor 2 San Francisco, CA, 94104 415.886.7923 | j...@2600hz.commailto:j...@2600hz.com -- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
RFC 1149
Given we are moving into the hurricanes season in a few months, I was wondering if this is now an accepted standard. I haven't seen many updates - it appears to be complete as is. Thanks,
Re: New Product Launch from 2600hz
On 1 April 2013 17:06, Owen DeLong o...@delong.com wrote: Goes in the same category as this bit of news: IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly announced that IPv4 would no longer be supported on the global internet after 1/1/2014. Those wishing to continue using the internet in 2014 and beyond should move to IPv6. Also same as the http://BXR.SU/ announcement on FreeBSD-hackers@ earlier today. We've declared 2013-04-04 as an IPv4 day. We'll publish some A records temporarily on April 4; permanently on April 14; and we will finally publish IPv4 glue records for bxr.su on 2013-04-24. http://lists.freebsd.org/pipermail/freebsd-hackers/2013-April/042334.html We're concerned that some systems have misconfigured NAT or other infrastructure, so, we're delaying IPv4 rollout in order to make sure that our IPv6 customers are not affected by any kind of IPv4 mishaps. C.
Re: Open Resolver Problems
In message 44ecd7b5-d9a4-408b-a132-29241de3a...@ianai.net, Patrick W. Gilmore writes: On Apr 01, 2013, at 11:55 , Milt Aitken m...@net2atlanta.com wrote: Most of our DSL customers have modem/routers that resolve DNS externally. And most of those have no configuration option to stop it. So, we took the unfortunate step of ACL blocking DNS requests to from the DSL network unless the requests are to our DNS servers. Suboptimal, but it stopped the DNS amplification attacks. I was going to suggest exactly this. Don't most broadband networks have a line in their AUP about running servers? Wouldn't a DNS server count as 'a server'? Then wouldn't running one violate the AUP? This gives the provider a hammer to hit the user over the head. Although that is quite unlikely, so the better point is that it also gives the provider cover in case some user complains about the provider filtering. You can always make an exception if the user is extremely loud. -- TTFN, patrick Actually a lot don't have such a line. Such lines are tantamount to extortion especially if the ISP supplies commercial grade lines. That said blocking by default with the option to open it up on request, the same as smtp is opened on request, might be viable. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Open Resolver Problems
On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote: Such lines are tantamount to extortion especially if the ISP supplies commercial grade lines. Patrick's talking about consumer broadband access. Such AUP stipulations are quite common. This is in no way 'tantamount to extortion'. Folks can either accept the AUP, or choose not to enter into a contract for the service in question under those conditions; there is no compulsion or coercion to do so. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
In message cf4e9f59-4a9e-4e03-8eb4-469c3db15...@arbor.net, Dobbins, Roland writes: On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote: Such lines are tantamount to extortion especially if the ISP supplies commercial grade lines. Patrick's talking about consumer broadband access. Such AUP stipulations are quite common. I know and I would still argue that they are tantamount to extortion. This is in no way 'tantamount to extortion'. Folks can either accept the AUP, or choose not to enter into a contract for the service in question under those conditions; there is no compulsion or coercion to do so. So the home user that want to run a server now has to pay for COLO or pay the ISP for it commercial line that is delivered over the same physical circuit for extra dollars which gets what? Maybe a upgraded SLA and maybe some static addresses. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Open Resolver Problems
On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote: I know and I would still argue that they are tantamount to extortion. There is no coercion involved, so, by definition, it can't be called 'extortion'. If you don't like the AUP, don't sign up for the service - simple as that. Hyperbole isn't generally helpful. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
On Apr 1, 2013, at 6:38 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote: I know and I would still argue that they are tantamount to extortion. There is no coercion involved, so, by definition, it can't be called 'extortion'. If you don't like the AUP, don't sign up for the service - simple as that. Hyperbole isn't generally helpful. In an oligopoly situation, that's hardly a valid set of choices and is tantamount to extortion. Owen
Re: Open Resolver Problems
On Mon, Apr 1, 2013 at 6:45 PM, Owen DeLong o...@delong.com wrote: On Apr 1, 2013, at 6:38 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote: I know and I would still argue that they are tantamount to extortion. There is no coercion involved, so, by definition, it can't be called 'extortion'. If you don't like the AUP, don't sign up for the service - simple as that. Hyperbole isn't generally helpful. In an oligopoly situation, that's hardly a valid set of choices and is tantamount to extortion. Yeah, I thought so, too, but apparently the FCC and the SEC hasn't seen it that way for the past 20 years. Go figure. :-) - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: Open Resolver Problems
On Apr 2, 2013, at 8:45 AM, Owen DeLong wrote: In an oligopoly situation, that's hardly a valid set of choices There's enough choice in most US markets (not all) to provide for a variety of services offered, AUPs, and price points. Wireless has brought an additional option to many previously underserved areas. and is tantamount to extortion. Again, hyperbole doesn't help. Another solution is to move to an area with more/better connectivity options, as some folks move in order to be zoned within a particular school district. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
On Apr 2, 2013, at 8:52 AM, Paul Ferguson wrote: Yeah, I thought so, too, but apparently the FCC and the SEC hasn't seen it that way for the past 20 years. Go figure. :-) The situation is gradually getting better, not worse - and that's progress, even if it isn't as fast as we'd all like. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: RFC 1149
--- esch...@comcast.net wrote: From: Ed Schweitzer esch...@comcast.net Given we are moving into the hurricanes season in a few months, I was wondering if this is now an accepted standard. I haven't seen many updates - it appears to be complete as is. Itty bitty rocket motors. One on each wing tip. Just have to make sure they're balanced, so they don't go into routing loops. WMAP (wing motor aggregation protocol? :) scott
Re: Open Resolver Problems
Yeah, I thought so, too, but apparently the FCC and the SEC hasn't seen it that way for the past 20 years. Go figure. :-) The FCC doesn't understand that 4Mbps customer-facing speed on the tail circuit alone does NOT define broadband in a meaningful way. The SEC does not understand that IPv4 risk and the lack of an IPv6 strategy should be a required risk consideration in a Sarbanes Oxley filing. I have little hope that these particular federal agencies will ever agree with me about such nuanced issues. Owen
Re: Open Resolver Problems
On Apr 1, 2013, at 6:54 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Apr 2, 2013, at 8:45 AM, Owen DeLong wrote: In an oligopoly situation, that's hardly a valid set of choices There's enough choice in most US markets (not all) to provide for a variety of services offered, AUPs, and price points. Wireless has brought an additional option to many previously underserved areas. With all due respect, sir, you are mistaken. Even in such populous areas as San Jose, there is a limited selection to a majority of the customers, especially if they want more than 1.5Mbps. In the majority of the US where it is rural, there is even less choice. Even where there are multiple providers, they often all provide the same limitations in their AUP unless you go to higher priced services. and is tantamount to extortion. Again, hyperbole doesn't help. If all of the choices to eliminate unreasonable restrictions on how you use the bandwidth you pay for involve paying more money for roughly the same service, then that is not hyperbole. Such is the case for a very large fraction of subscribers in the US. Another solution is to move to an area with more/better connectivity options, as some folks move in order to be zoned within a particular school district. It is an option when you live in a neighborhood with a protection racket operating to move out of the neighborhood as well. This does not change the fact that a protection racket is extortion. Owen
Re: RFC 1149
Make sure you don't miss the QoS implementation of RFC 2549 (and make sure that you're ready to implement RFC 6214). You'll be highly satisfied with the results (presuming you and your packets end up in one of the higher quality classes). I'd also suggest a RFC 2322 compliant DHCP server for devices inside the hurricane zone, but modified by implementing zip ties such that the C47s aren't released under heavy (wind or water) loads. - Eric
Re: RFC 1149
On 4/1/2013 10:15 PM, Eric Adler wrote: Make sure you don't miss the QoS implementation of RFC 2549 (and make sure that you're ready to implement RFC 6214). You'll be highly satisfied with the results (presuming you and your packets end up in one of the higher quality classes). I'd also suggest a RFC 2322 compliant DHCP server for devices inside the hurricane zone, but modified by implementing zip ties such that the C47s aren't released under heavy (wind or water) loads. Actually, given recent events, I'd emphasize and advocate RFC3514 (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue for adoption. The implementation would forego most of the currently debated topics as related to network abuse or misuse :) Jeff
Re: RFC 1149
Packets, shmackets. I'm just upset that my BGP over Semaphore Towers routing protocol extension hasn't been experimentally validated yet. Whoever you are who keeps flying pigeons between my test towers, you can't deliver packets without proper routing updates! Knock it off long enough for me to converge the #@$#$@ routing table... On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/1/2013 10:15 PM, Eric Adler wrote: Make sure you don't miss the QoS implementation of RFC 2549 (and make sure that you're ready to implement RFC 6214). You'll be highly satisfied with the results (presuming you and your packets end up in one of the higher quality classes). I'd also suggest a RFC 2322 compliant DHCP server for devices inside the hurricane zone, but modified by implementing zip ties such that the C47s aren't released under heavy (wind or water) loads. Actually, given recent events, I'd emphasize and advocate RFC3514 (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue for adoption. The implementation would forego most of the currently debated topics as related to network abuse or misuse :) Jeff -- -george william herbert george.herb...@gmail.com
Re: Open Resolver Problems
On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote: With all due respect, sir, you are mistaken. Even in such populous areas as San Jose, there is a limited selection to a majority of the customers, especially if they want more than 1.5Mbps. I lived in San Jose for several years, and had several choices for broadband - the one I chose was much faster than 1mb/sec, had an AUP which specifically allowed me to run a server, and didn't try to cap my bandwidth, or disable the use of p2p apps, or whatever. I moved away from San Jose in at the tail-end of 2007. It seems likely that at least the same level of choice prevails there today . . . --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote: In the majority of the US where it is rural, there is even less choice. Largest in geography largest in population. Even where there are multiple providers, they often all provide the same limitations in their AUP unless you go to higher priced services. If you don't like the pricing, that's quite different from claiming extortion. Look, I'm no fan of semi-monopolies, 'unlimited' capacity which isn't, and so forth. But there *are* choices in most US broadband markets; maybe not the choices which we'd find ideal, maybe at a price-point higher than we think is fair, but the point is that there are choices, and nobody is forcing anyone to spend money for services he doesn't wish to purchase. I'd like to see UK-style structural separation in the US, as that would greatly increase opportunities to compete. I doubt it will ever happen, though. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
On Mon, Apr 1, 2013 at 7:38 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote: Even in such populous areas as San Jose, there is a limited selection to a majority of the customers, especially if they want more than 1.5Mbps. I lived in San Jose for several years, and had several choices for broadband - the one I chose was much faster than 1mb/sec, had an AUP which specifically allowed me to run a server, and didn't try to cap my bandwidth, or disable the use of p2p apps, or whatever. I moved away from San Jose in at the tail-end of 2007. It seems likely that at least the same level of choice prevails there today . . . So, I lived in San Jose, too, for many years, and I had fewer choices there than I do here now in the Pacific Northwest. In any event, depending on where you are in the U.S., many consumers have a choice between bad and worse. :-) - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: Open Resolver Problems
On Apr 2, 2013, at 9:48 AM, Paul Ferguson wrote: In any event, depending on where you are in the U.S., many consumers have a choice between bad and worse. :-) I certainly do agree with that general sentiment. Living abroad, I have more choices in terms of both wired broadband and wireless. And 'unlimited' really means unlimited. If I ever moved back to the US, one of the things I would miss the most is complete freedom in terms of wireless network choice, service level, and traffic tiering. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Open Resolver Problems
On Tue, 2 Apr 2013, Måns Nilsson wrote: What percentage of the SOHO NAT boxes actually are full-service resolvers? I was under the impression that most were mere forwarders; just pushing queries on toward the DHCP'd full service resolvers of the ISP. What does that help? They can still be amplifiers, it's just that now the ISP resolver will see the resolving load as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se
