- Test - lists.nanog.org

AS47860 - 93.175.240.0/20 - Wiskey Tango Foxtrot
by Ronald F. Guilmette 07 Oct '16

07 Oct '16

My analysis: Serious and apparently long-lived bogosity, with a clear history of substantial spamming aactivity. But you be the judge. Looks to me like an unregistered RIPE AS announcing a route to a /20 worth of unregistered RIPE IPv4 space. And this didn't exactly crop up just yesterday. Looks like this has been ongoing for one hell of a long time: https://stat.ripe.net/widget/routing-history#w.resource=AS47860 Of course, it's not even nearly as much of an issue -now- as it was, say, about 1 year ago, in October of 2015, when the /20 was apparently populated by a huge boat load of snowshoe spammer domains. Sadly, Spamhaus has a bad habit of consistantly failing to ever put any helpful date information on any of its listings, otherwise I'd be able to see when -they- first noticed this absurd mess. https://www.spamhaus.org/pbl/query/PBL1626432 Anyway, it's rather annoying to me personally... and I hope I'm not the only one who feels that way... to know that this has gone mostly unnoticed for so long, that nobody within the RIPE region has ever bothered to -do- anything about it, and that the AS and the bogus route are still being announced, even as we speak. Assuming the thing remains in play, how long will be be before the spammers return to use and abuse it yet again? Maybe they were just waiting for a full year to go by so that they might have some hopes of this /20 being automatically aged off some blacklists. Regards, rfg P.S. This crap appears to be be brought to us courtesy of AS29632, NetAssist, LLC: http://new.netassist.ua/ So anyway, where are the grownups?

4 5

EDNS compliance and BIND 9.11.0
by Mark Andrews 07 Oct '16

07 Oct '16

BIND 9.11.0 was released this week. BIND 9.11.0 and BIND 9.10.4 implement EDNS COOKIES. They are on by default in BIND 9.11.0 and BIND 9.10.4 Windows. For the non Windows builds of BIND 9.10.4 they need to be enabled at configure time. If your nameservers are not EDNS compliant, especially for unknown EDNS options, you could be seeing issues ranging from additional traffic, slow DNS lookups to full blown lookup failures. If you having fixed your servers already you need to fix them now. You can test your servers at https://ednscomp.isc.org/ednscomp/ to see if they are EDNS compliant. You can see EDNS compliance trends and list of failing servers at https://ednscomp.isc.org. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

1 0

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension
by Larry Sheldon 07 Oct '16

07 Oct '16

On 10/6/2016 15:26, Jesse McGraw wrote: > (This is me scratching an itch of my own and hoping that sharing it > might be useful to others on this list. Apologies if it isn't) > > When I'm trying to comprehend a new or complicated Cisco router, > switch or firewall configuration an old pet-peeve of mine is how > needlessly difficult it is to follow deeply nested logic in route-maps, > ACLs, QoS policy-maps etc etc A dim, weak voice from the past. Has advantages of the plan proposed here. > > To make this a bit simpler I’ve been working on a perl script to convert > these text-based configuration files into HTML with links between the > different elements (e.g. To an access-list from the interface where it’s > applied, from policy-maps to class-maps etc), hopefully making it easier > to to follow the chain of logic via clicking links and using the forward > and back buttons in your browser to go back and forth between command > and referenced list. We used to (using a HB lead in a draftsman' lead holder and a stack for Forms SN 457* (Blank Spread Sheet, 11 x 17) sorted all of the requests, demands and other requirements into logical packages. Then, using the blank back side of the spread sheet, we drew "flow diagrams depicting how we would code the requirements. If a section got a little complicated and tedious, we'd put a symbol on the diagram, a title that made sense and a page number. On a new sheet, we wrote that title and that page number and drew the flow diagram for that messy bit of business. Then we would "desk check" the flow diagrams and in the process, note on the requirements sheet (s) the diagram number (and entry point if there was more than one) where the requirement was satisfied. Then we would start with a new sheet working from the flow diagrams, write the code for the machine (noting on the flow diagram the page and line number in the code where the operation on the flow diagram occurred. There are several advantages to this approach--hard to leave important stuff out, hard to include code that is never exercised, hard to make changes to the code because you don't know how to make HTML depict it correctly. No need to lecture me on the folly of the old ways--it is why I got fired for being too old. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account.

1 0

Questions re: VPN protocols globally
by Eric Germann 05 Oct '16

05 Oct '16

I’ve been charged with building a global VPN as an overlay on top of a certain 3 letter company who also sells lots of stuff. We’re looking at US East US West US Central (eventually) Brazil Singapore Frankfurt Ireland Sydney Maybe Canada Maybe India (outsourcesrs) In the planning stages now and wondering if there are any protocols I need to stay away from ITAR wise with this list of countries. Contemplating Suite B with GCM, etc and AES acceleration. Any land mines? Thanks in advance EKG

5 6

Re: Legislative proposal sent to my Congressman
by Anne Mitchell 05 Oct '16

05 Oct '16

(Interesting and inarguably well-intentioned, and possibly even sound, idea snipped, but noted.) There are a handful of reasons that this will never happen (well, I'm 98% certain it will never happen, nothing is every 100% sure when it comes to the law, and legislation)... among them the manufacturer's lobby is much more well-girded than is the 'home internet security' lobby; the cyber-security concerns of the Federal government are focussed on other things (whether they should be or not, they are); and for the most part legislators are still fairly unsavvy about tech in general, and these things make their eyes glaze over. That said, there are already tort (negligence, etc.) laws and precedents under which such manufacturers can be sued, along with things like breach of contract between the manufacturer and consumer, and breach of implied warranty of fitness for a particular purpose and breach of implied warranty of merchantability. A couple of winning lawsuits against manufacturers under these laws and theories - which judges *already understand* - is, I think, not only a more likely, but a much faster, route to industry reform. All that said, much of this faces the same issues that spam lawsuits faced - the people who care the most about it are not the ones who can afford to finance such lawsuits. Anne Anne P. Mitchell, Attorney at Law Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Asilomar Microcomputer Workshop Committee Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop

3 2

Re: Legislative proposal sent to my Congressman
by Larry Sheldon 05 Oct '16

05 Oct '16

On 10/3/2016 13:58, Stephen Satchell wrote: > In thinking over the last DDos involving IoT devices, I think we don't > have a good technical solution to the problem. Cutting off people with > defective devices they they don't understand, and have little control > over, is an action that makes sense, but hurts the innocent. "Hey, > Grandma, did you know your TV set is hurting the Internet?" > > It's the people who foist bad stuff on the people who need to take the > responsibility. Indeed, with enough moxie, we could avoid the net > saturation problem in the first place. > > My proposal, as I sent it to my US House Representative: > [much snipping] > Why not nip the IoT problem in the bud? Why not, indeed? (Full disclosure: I am not and have not for some years been active in management of any networks, and I AM woefully behind the state of the arts.) Having said that, it occurs to me that Mr. Satchell's proposal (and most of the others I have read about here and elsewhere lately) are doomed to the same failure as Chicago's plan for reducing illegal deaths by firearm, and for much the same reason (discussion of which here I will spare you. Back in the day, I was fighting a problem that I summarized (then and now) as trying to stop the use and abuse of the University's (that employed me) 56kb Frame Relay link to the Internet. Then as now I defined "abuse" as the use of our facilities for purposes that no stretch of imagination or definition could be said to be to the University's benefit. Through some experimentation I concluded that there were several clearly identifiable sources of abuse. I disremember the ordering by severity but they included: Outright attacks on the University and others. Myriad "scans" for a variety of reasons. The first of these two I remember as being the worst (in terms of item-count AND in terms of packet-size. I also recall it being the easiest to fix, if anybody want to fix it. (The dominant reasons given where that it would cost money without a revenue stream, and it would reduce traffic that WAS in the revenue stream. The fix I proposed: Require (by law) that every service provider and every origination customer of a service provider would under penalty of law, block the transmission of a packet whose source address could not be reached via the link upon which it was found. The Myriad scans problem was a little harder (for among other reasons--the argument that they were good for us, even though they accounted for something like 60% of the traffic on that link). The solution I tried but ran out of dollars on was to detect somebody scanning and route them to the Loopback interface of the boundary router. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account.

2 1

10G tester recommendations?
by Bryan Holloway 05 Oct '16

05 Oct '16

We're in the market for a hand-held 10G ethernet tester, and I was curious if the NANOG community had any recommendations or experiences they would be willing to share, negative or positive. Currently we're looking at the EXFO MAX-800 and NetScout's AT 10G, but we're open to other suggestions. Thank you! - bryan

5 6

Re: Level 3 voice outage
by Mel Beckman 04 Oct '16

04 Oct '16

Just so. We are just speculating, but in light of recent GRE attack developments, the ddos possibility is worth considering. -mel beckman On Oct 4, 2016, at 12:54 PM, Shawn Ritchie <shawnritchie(a)gmail.com<mailto:shawnritchie@gmail.com>> wrote: Well, Level3 has by no means said that this was the result of a DDoS, that's just speculation on behalf of folks who do not work at Level3 so far. On Tue, Oct 4, 2016 at 2:49 PM Marco Teixeira <admin(a)marcoteixeira.com<mailto:admin@marcoteixeira.com>> wrote: I won't believe a company like Level3 would not deploy backplane protection/policing on routers. Also, 1Tb/s aggregated DDoS towards OVH network didn't pause or rebooted routers. And i guess both companies have had their share of (D)DoS in the past, so they had the time to get up to the challenge. Now... there where times where one malformed IP packet would cause a memory leak leading to a router reboot... :)? On Tue, Oct 4, 2016 at 8:23 PM, Mel Beckman <mel(a)beckman.org<mailto:mel@beckman.org>> wrote: > 765 Gbps per second directed at a router's interface IP might give the > router pause, so to speak :) > > -mel > > On Oct 4, 2016, at 12:10 PM, Marco Teixeira <admin(a)marcoteixeira.com<mailto:admin@marcoteixeira.com>> > wrote: > > Multiple reboots across several markets... Does not seem something that > full pipes would trigger. Had it been an approved chance it would have been > rolled back i guess... On the other hand, a zero day could apply... > > Em 04/10/2016 19:54, "Mel Beckman" <mel(a)beckman.org<mailto:mel@beckman.org>> escreveu: > >> Sure. The recent release of the IoT DDoS attack code in the wild. >> >> -mel >> >> > On Oct 4, 2016, at 11:42 AM, Valdis.Kletnieks(a)vt.edu<mailto:Valdis.Kletnieks@vt.edu> wrote: >> > >> > On Tue, 04 Oct 2016 18:14:54 -0000, Mel Beckman said: >> > >> >> This could be DoS attack. >> > >> > Or a missing comma in a code update. >> > >> > Or a fumble-fingered NOC monkey. >> > >> > Or.... >> > >> > You have any reason to suspect a DoS attack rather than all the other >> > possibilities? >> >> > -- -- Shawn

1 0

Level 3 voice outage
by Mark Stevens 04 Oct '16

04 Oct '16

Is anyone noticing issue with Level 3 voice? I can't even call their 800 number using one of my other carriers. Mark

17 22

Legislative proposal sent to my Congressman
by Stephen Satchell 04 Oct '16

04 Oct '16

In thinking over the last DDos involving IoT devices, I think we don't have a good technical solution to the problem. Cutting off people with defective devices they they don't understand, and have little control over, is an action that makes sense, but hurts the innocent. "Hey, Grandma, did you know your TV set is hurting the Internet?" It's the people who foist bad stuff on the people who need to take the responsibility. Indeed, with enough moxie, we could avoid the net saturation problem in the first place. My proposal, as I sent it to my US House Representative: > Fixing the security of the Internet of Things: Now we have had > several distributed denial of service attacks — generating > eye-popping amounts of network traffic to bury a web site or gamer — > arguably traced to botnets-for-sale of "hacked" common devices with > Internet connectivity. It's time to look at the problem bad product > design can cause. Not being "computers", many of those devices — > cameras, televisions, light bulbs, to name a few — don't have > tough-enough security moxie baked in. And it's not enough to solve > today's attacks, they have to survive new attacks down the road. > > Some of these household items didn't conform to today's Best > Practices, taught in Security 101, with the rules learned (painfully) > over the last 30 years. And then there is the question of installing > security fixes: "Hey, Joe, you have to install an update to your > thermostat and washing machine." Right. > > This is nothing new. What is new is the tsunami of Internet-capable > devices hitting the market and the Internet...and doing it badly. By > sheer numbers, the situation rises to a whole new level of risk to the > nation's communications infrastructure. The magnitude of the problem? > Think how many light bulbs are in the typical house or apartment, and > you get the idea. > > This note comes a little late to the game, but I thought that one > wayto stem the flood of garbage from compromised household stuff is to > treat vulnerabilities that cause spew as design defects, defects as > serious as the exploding batteries in the Samsung Galaxy Note 7. So, > looking at the procedures already in place for dealing with merchandise > that can cause harm, this suggestion. > > Proposed: GIVEN > > * any Internet-connected device, > * "pwned" by cybercriminals, > * that cause significant harm, > * the manufacturer received notice of the defect, and > * did not, or cannot, provide a timely, zero-cost update > > THEREFORE the Consumer Product Safety Commission shall require that > the manufacturer provide a security update to the device within 30 day > of first notice; or failing that, to issue a complete recall of the > defective devices. > > I don't care if it's a television, camera, refrigerator, light bulb, > thermostat, washing machine, wireless access router, smart phone, > desktop computer, server, you-name-it...if it's broke, and can't (or > won't) be fixed, it gets recalled. > > That's the only way manufacturers will take Internet security > seriously. If they have to upgrade the stuff they sell, without > exception, the manufacturers will find a method that will keep their > expense for upgrades down. Upgrades should not be charged to the > customer — the manufacturer screwed up, they should fix the problem, at > their expense. I further suggest that security testing should be > specifically permitted under law, not be considered part of "reverse > engineering", or other shrink-wrap or copyright restriction. > > The CSPC should develop guidelines for product with embedded computers > that connect to the Internet at large, either directly or indirectly. > > There are a number of things to consider, when building such a > regulation, that come into play that complicated things > > * orphaned devices, > * devices made by companies that have gone out of business, > * imported stuff, > * methods of notification, and > * enforcement > > This is an off-the-top-of-my-head idea. I think it's worth > consideringover other "solutions" I've seen proposed. There is precedent for this with radio and the FCC. According to current law, the owner/operator of the radio equipment is ultimately responsible for non-interference by any transmitter used in the United States. This includes so-called unlicensed transmitters. To help the people who are not radio gurus, the FCC also has a type acceptance program, in which radios have to meet certain requirements as built by the manufacturer. There is another possible wrinkle: if there were legal consequences with selling IoT equipment, businesses making the stuff would take out insurance against claims against them. The underwriters would then take notice, and require that policyholders meet some minimum standards. Remember, we are talking about the "underwriters" who form the first part of the name "Underwriters Laboratories". From UL's web page: > UL is a global independent safety science company with more than a > century of expertise innovating safety solutions from the public > adoption of electricity to new breakthroughs in sustainability, > renewable energy and nanotechnology. Dedicated to promoting safe > living and working environments, UL helps safeguard people, products > and places in important ways, facilitating trade and providing peace > of mind. We could build on these existing frameworks to the advantage of the Internet by mandating certain minimum requirements for equipment sold to the general public. I would suspect that the IETF would need to become involved in this effort, because the standards would have to come from SOMEWHERE. Which is why they are included in the header. There are other people on the Cc: list that might be interested...or might not. Why not nip the IoT problem in the bud?

11 17