January 2013 - Test - lists.nanog.org

GPS attack vector
by Jay Ashworth 17 Jan '13

17 Jan '13

Do you use GPS to provide any mission critical services (like time of day) in your network? Have you already see this? (I hadn't) http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-… Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)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

3 2

Re: NANOG Digest, Vol 60, Issue 54
by carl gough [mobsource] 17 Jan '13

17 Jan '13

unsub=scribe please [carl gough] founder and CEO +61 425 266 764 mobsource.com On 17/01/13 11:00 PM, "nanog-request(a)nanog.org" <nanog-request(a)nanog.org> wrote: >Send NANOG mailing list submissions to > nanog(a)nanog.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog >or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > >You can reach the person managing the list at > nanog-owner(a)nanog.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of NANOG digest..." > > >Today's Topics: > > 1. Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT > Instead of IPv6 ( .) > 2. Re: Notice: Fradulent RIPE ASNs (Rich Kulawiec) > 3. Re: Suggestions for the future on your web site: (was > cookies, and before that Re: Dreamhost hijacking my prefix...) >(john) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 17 Jan 2013 11:06:54 +0100 >From: " ." <oscar.vives(a)gmail.com> >Cc: "North American Network Operators' Group" <nanog(a)nanog.org> >Subject: Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT > Instead of IPv6 >Message-ID: > <CACg3zYF65y2kHi18N2AZEzbvARExYCuBznCGA8KiPyTsDz+3Xw(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >i am not network engineer, but I follow this list to be updated about >important news that affect internet stability. > >NAT is already a problem for things like videogames. You want people >to be able to host a multiplayer game, and have his friends to join >the game. A free to play MMO may want to make a ban for a bad person >permanent, and for this banning a IP is useful, if a whole range of >players use a ip, it will be harder to stop these people from >disrupting other people fun. Players that can't connect to the other >players whine on the forums, and ask the game devs to fix the problem, >costing these people money. People that can't connect to other >players, for a problem that is not in his side, or under his control, >get frustrated. This type of problems are hard to debug for users. > >The people on this list have a influence in how the Internet run, hope >somebody smart can figure how we can avoid going there, because there >is frustrating and unfun. > > >-- >-- >?in del ?ensaje. > > > >------------------------------ > >Message: 2 >Date: Thu, 17 Jan 2013 05:33:34 -0500 >From: Rich Kulawiec <rsk(a)gsp.org> >To: nanog(a)nanog.org >Subject: Re: Notice: Fradulent RIPE ASNs >Message-ID: <20130117103334.GA7155(a)gsp.org> >Content-Type: text/plain; charset=us-ascii > >On Wed, Jan 16, 2013 at 11:39:14AM -0500, William Herrin wrote: >> 1. Has SPAMHAUS attempted to feed relevant portions of their knowledge >> into ARIN's reporting system for fraudulent registrations and, > >I don't know the answer to that. > >> 2. Understanding that ARIN can only deal with fraudulent >> registrations, not any other kind of bad-actor behavior, are there >> improvements to ARIN's process which would help SPAMHAUS and similar >> organizations feed ARIN actionable knowledge? > >Yes. > >All ARIN (public) data should be immediately downloadable in bulk by >anyone >who wishes to access it. No registration, no limits, no nothing. As I >pointed out here a couple of weeks ago (see below), query rate-limiting >measures such as RIPE currently employs are not only pointless but >counterproductive: the bad guys already have (or can have) the data any >time they wish, but the good guys can't. I suggest a daily rsync'able >snapshot of the whole enchilada in whatever form(s) is/are appropriate: >text, XML, tarball, etc. > >Of course I was responding to something from RIPE, but this applies >everywhere. It's 2013. The bad guys have had the means to easily >bypass stuff like this for about a decade, if not longer. It's not only >silly to keep pretending they don't, but it's limiting: some of the best >techniques we have for spotting not only fraudulent registrations, but >other patterns of abuse, work best when given as much data as possible. >(It's really quite impressive what you can find with "grep", if you >have enough data in the right form.) > >(Incidentally, the same thing is true of all domain registration data. >The namespace, like network space, is a public resource, therefore >anyone using any of it must be publicly accountable.) > >Here's what I said at the time, generalize/modify appropriately: > >> Subject: Re: RIPE Database Proxy Service Issues >> >> On Wed, Jan 02, 2013 at 05:00:14PM +0100, Axel Pawlik wrote: >> > To prevent the automatic harvesting of personal information (real >> > names, email addresses, phone numbers) from the RIPE Database, there >> > are PERSON and ROLE object query limits defined in the RIPE Database >> > Acceptable Use Policy. This is set at 1,000 PERSON or ROLE objects >> > per IP address per day. Queries that result in more than 1,000 >> > objects with personal data being returned result in that IP address >> > being blocked from carrying out queries for that day. >> >> 1. The technical measures you've outlined will not prevent, and have >> not prevented, anyone from automatically harvesting the entire thing. >> Anyone who owns or rents, for example, a 2M-member botnet, could easily >> retrieve the entire database using 1 query per IP address, spread out >> over a day/week/month/whatever. (Obviously more sophisticated >>approaches >> immediately suggest themselves.) >> >> Of course a simpler approach might be to buy a copy from someone who >> already has. >> >> I'm not picking on you, particularly: all WHOIS operators need to stop >> pretending that they can protect their public databases via >>rate-limiting. >> They can't. The only thing that they're doing is preventing NON-abusers >> from acquiring and using bulk data. >> >> 2. This presumes that the database is actually a target for abusers. >> I'm sure for some it is. But as a source, for example, of email >> addresses, it's a poor one: the number of addresses per thousand records >> is relatively small and those addresses tend to belong to people with >> clue, making them rather suboptimal choices for spamming/phishing/etc. >> >> Far richer targets are available on a daily basis simply by following >> the dataloss mailing list et.al. and observing what's been posted on >> pastebin or equivalent. These not only include many more email >>addresses, >> but often names, passwords (encrypted or not), and other personal >>details. >> And once again, the simpler approach of purchasing data is available. >> >> 3. Of course answering all those queries no doubt imposes significant >> load. Happily, one of the problems that we seem to have pretty much >> figured out how to solve is "serving up many copies of static >> content" because we have tools like web servers and rsync. >> >> So let me suggest that one way to make this much easier on yourselves is >> to export a (timestamped) static snapshot of the entire database once >> a day, and let the rest of the Internet mirror the hell out of it. >> Spreads out the load, drops the pretense that rate-limiting >> accomplishes anything useful, makes all the data available to everyone >> equally, and as long as everyone is aware that it's a snapshot and not >> a real-time answer, would probably suffice for most uses. (It would >> also come in handy during network events which render your service >> unreachable/unusable in whole or part, e.g., from certain parts of >> the world. Slightly-stale data is way better than no data.) > > > >------------------------------ > >Message: 3 >Date: Thu, 17 Jan 2013 11:51:33 +0100 >From: john <jbond(a)ripe.net> >To: Shrdlu <shrdlu(a)deaddrop.org> >Cc: nanog(a)nanog.org >Subject: Re: Suggestions for the future on your web site: (was > cookies, and before that Re: Dreamhost hijacking my prefix...) >Message-ID: <50F7D7B5.2090403(a)ripe.net> >Content-Type: text/plain; charset=UTF-8 > >On 1/16/13 8:36 PM, Shrdlu wrote: >> On 1/16/2013 9:40 AM, john wrote: >> >>> I took a look at this site and unfortunately the use of cookies is very >>> ingrained into the code. Removing the requirement breaks all >>> functionality of www.ris.ripe.net and changing the functionality would >>> require a rewrite of the site. >> >> Sooner or later, you'll get to a place where you consider a major >> update, and perhaps then you'll consider emulating NANOG's site. >>However... >just for clarity, i believe that the issues with requiring cookies only >affects www.ris.ripe.net and not the entire *.ripe.net site(s). Im not >one of the developers however i believe they endeavour to keep the use >of cookies to a minimum with current and future development. >> >> I was curious, and I went to look at it. Please consider using some >> other color than lovely amber yellow you've chosen. It's very pretty, >> and exhausting to look at for any length of time. I'm a HUGE fan of gray >> scales, and of text. I see that you want a cookie when I want to look at >> one of the videos, but blocking it doesn't hurt me. Here's where you did >> something right. The video plays on my (pretty old) Firefox, which has >> no Flash (hooray!). >> >> The cookie stays around for a YEAR (if I let it), and has the following >> stuff: >> >> Name: stat-csrftoken >> Content: 7f12a95b8e274ab940287407a14fc348 >> Host: stat.ripe.net >> Path: / >> Send For: Any type of connection >> Expires: Wednesday, January 15, 2014 11:29:34 AM >> >> To your credit, you only ask once, but you ought to ask zero times. >> >> The site's not bad, but please consider changing the yellow to black. >> Less beauty, more utility. >> > >Thank you for this feedback, i'll pass it onto to the developers. > >Regards >John > > > >End of NANOG Digest, Vol 60, Issue 54 >*************************************

1 0

How are operators using IRR?
by ML 17 Jan '13

17 Jan '13

How are operators using the data available in the various IRRs? Using an example: AS1 is your customer AS1 has AS2, AS3 and AS4 described as customers in an IRR Also assume AS2 has IRR data describing AS1000 and AS2000 as it's customers. Are operators building AS path regexes such as the following automatically from IRR and applying that to your BGP sessions? ---- AS1{1,} AS1{1,} AS2{1,} AS1{1,} AS3{1,} AS1{1,} AS2{1,} AS1000{1,} AS1{1,} AS2{1,} AS2000{1,} ---- I would imagine most operators that are building policy from IRR are building prefix lists to limit what they are accepting. Is this being paired with some AS path filtering? Are operators just traversing an AS-SET as far as it will go and building prefix lists to represent all intended prefixes to be heard on a session regardless of who originates them? Is the possibility of AS1000 hijacking AS2000 prefixes towards AS2 a problem you as the upstream to AS1 need to consider? (Last question assumes AS2 made a mistake and wasn't filtering properly on it's own customers and AS1 is just accepting all prefixes under the cone of AS2) Thanks

3 2

Notice: Fradulent RIPE ASNs
by Ronald F. Guilmette 17 Jan '13

17 Jan '13

After a careful investigation, I am of the opinion that each of the following 18 ASNs was registered (via RIPE) with fradulent information purporting to represent the identity of the true registrant, and that in fact, all 18 of these ASNs were registered by a single party, apparently as part of a larger scheme to provide IP space to various snowshoe spammers. Evidence I have in hand strongly links this scheme and these ASNs and their associated IPv4 route announcements to Jump Network Services, aka JUMP.RO. Furthermore, all of these ASNs are apparently peering with exactly and only the same two other ASNs in all cases, i.e. GTS Telecom SRL (AS5606) and Net Vision Telecom SRL (AS39737). These peers and the fradulent ASNs listed below are all apparently originated out of Romania. AS16011 (fiberwelders.ro) AS28822 (creativitaterpm.ro) AS48118 (telecomhosting.ro) AS49210 (rom-access.ro) AS50659 (grandnethost.com) AS57131 (speedconnecting.ro) AS57133 (nordhost.ro) AS57135 (fastcable.ro) AS57176 (bucovinanetwork.ro) AS57184 (kaboomhost.ro) AS57415 (highwayinternet.ro) AS57695 (effidata.ro) AS57724 (id-trafic.ro) AS57738 (mclick.ro) AS57786 (hosting-www.ro) AS57837 (romtechinnovation.ro) AS57906 (momy.ro) AS57917 (nature-design.ro) At present, the above 18 ASNs are currently announcing routes for a total amount of IP space equal to 1,022 /24s, which is the rough equivalent of an entire /14 block. These IPv4 route announcements are listed below, sorted by IPv4 (32-bit) start address. Additional potentially relevant background information: http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets… http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-bu… http://www.spamhaus.org/sbl/listings/jump.ro Current route announcements: 31.14.30.0/24 31.14.32.0/24 31.14.33.0/24 31.14.34.0/23 31.14.36.0/22 31.14.40.0/22 31.14.44.0/24 31.14.45.0/24 31.14.46.0/23 31.14.48.0/24 31.14.49.0/24 31.14.50.0/23 31.14.52.0/22 31.14.56.0/21 31.14.64.0/24 31.14.65.0/24 31.14.66.0/23 31.14.68.0/22 31.14.72.0/21 31.14.80.0/20 31.14.112.0/20 31.14.144.0/20 37.153.128.0/22 37.153.132.0/22 37.153.140.0/22 37.153.144.0/21 37.153.152.0/22 37.153.160.0/21 37.153.168.0/22 37.153.172.0/23 37.153.174.0/23 37.153.176.0/20 37.156.0.0/22 37.156.4.0/22 37.156.8.0/21 37.156.16.0/23 37.156.18.0/23 37.156.20.0/23 37.156.22.0/23 37.156.24.0/23 37.156.26.0/23 37.156.28.0/23 37.156.30.0/23 37.156.36.0/24 37.156.37.0/24 37.156.38.0/23 37.156.48.0/21 37.156.56.0/22 37.156.100.0/22 37.156.104.0/22 37.156.108.0/22 37.156.112.0/20 37.156.128.0/20 37.156.144.0/22 37.156.148.0/22 37.156.152.0/21 37.156.160.0/21 37.156.168.0/22 37.156.172.0/23 37.156.180.0/23 37.156.184.0/22 37.156.188.0/22 37.156.208.0/22 37.156.216.0/22 37.156.224.0/24 37.156.225.0/24 37.156.226.0/23 37.156.228.0/23 37.156.230.0/23 37.156.232.0/23 37.156.234.0/23 37.156.236.0/23 37.156.238.0/23 37.156.240.0/21 37.156.248.0/22 37.156.252.0/22 46.102.128.0/20 46.102.144.0/20 46.102.160.0/21 77.81.120.0/23 77.81.126.0/24 77.81.160.0/22 84.247.4.0/22 84.247.18.0/23 84.247.40.0/22 85.204.18.0/24 85.204.20.0/23 85.204.30.0/23 85.204.36.0/22 85.204.54.0/23 85.204.64.0/23 85.204.66.0/24 85.204.76.0/23 85.204.96.0/23 85.204.104.0/23 85.204.120.0/24 85.204.121.0/24 85.204.124.0/24 85.204.132.0/23 85.204.152.0/23 85.204.176.0/21 85.204.194.0/23 86.104.0.0/23 86.104.2.0/24 86.104.4.0/24 86.104.9.0/24 86.104.10.0/24 86.104.96.0/21 86.104.115.0/24 86.104.116.0/24 86.104.118.0/23 86.104.121.0/24 86.104.122.0/23 86.104.132.0/23 86.104.192.0/24 86.104.195.0/24 86.104.212.0/23 86.104.215.0/24 86.104.240.0/22 86.104.245.0/24 86.104.248.0/23 86.105.178.0/24 86.105.195.0/24 86.105.196.0/24 86.105.200.0/22 86.105.225.0/24 86.105.227.0/24 86.105.230.0/24 86.105.242.0/23 86.105.248.0/22 86.106.0.0/21 86.106.8.0/23 86.106.10.0/24 86.106.11.0/24 86.106.12.0/24 86.106.24.0/24 86.106.25.0/24 86.106.90.0/24 86.106.95.0/24 86.106.169.0/24 86.107.8.0/21 86.107.28.0/23 86.107.74.0/23 86.107.104.0/24 86.107.195.0/24 86.107.216.0/21 86.107.242.0/23 89.32.122.0/23 89.32.176.0/23 89.32.192.0/23 89.32.196.0/23 89.32.204.0/24 89.33.46.0/23 89.33.108.0/23 89.33.117.0/24 89.33.168.0/21 89.33.233.0/24 89.33.246.0/24 89.33.255.0/24 89.34.16.0/22 89.34.94.0/23 89.34.102.0/23 89.34.112.0/21 89.34.128.0/20 89.34.148.0/23 89.34.200.0/23 89.34.216.0/23 89.34.236.0/22 89.35.32.0/24 89.35.56.0/24 89.35.77.0/24 89.35.133.0/24 89.35.156.0/23 89.35.176.0/23 89.35.196.0/24 89.35.240.0/21 89.36.16.0/23 89.36.32.0/23 89.36.34.0/24 89.36.35.0/24 89.36.96.0/21 89.36.104.0/21 89.36.178.0/23 89.36.182.0/23 89.36.184.0/21 89.36.226.0/23 89.36.236.0/22 89.37.48.0/21 89.37.64.0/22 89.37.76.0/22 89.37.102.0/23 89.37.107.0/24 89.37.129.0/24 89.37.133.0/24 89.37.143.0/24 89.37.240.0/21 89.38.26.0/24 89.38.216.0/22 89.38.220.0/22 89.39.76.0/22 89.39.168.0/22 89.39.180.0/23 89.39.216.0/22 89.40.40.0/24 89.40.66.0/24 89.40.133.0/24 89.40.240.0/21 89.40.254.0/23 89.41.16.0/21 89.41.44.0/22 89.42.27.0/24 89.42.33.0/24 89.42.150.0/23 89.42.208.0/23 89.43.182.0/23 89.43.184.0/23 89.43.216.0/21 89.43.224.0/21 89.44.94.0/23 89.44.115.0/24 89.44.120.0/21 89.44.190.0/23 89.45.11.0/24 89.45.14.0/24 89.45.72.0/21 89.45.126.0/23 89.46.8.0/22 89.46.44.0/23 89.46.47.0/24 89.46.60.0/24 89.46.88.0/22 89.46.192.0/21 89.47.34.0/24 89.47.44.0/22 92.114.36.0/24 92.114.38.0/24 92.114.83.0/24 93.113.216.0/22 93.114.24.0/21 93.114.85.0/24 93.114.86.0/23 93.114.128.0/24 93.114.133.0/24 93.115.32.0/23 93.115.62.0/23 93.115.130.0/23 93.115.134.0/23 93.115.138.0/23 93.115.142.0/23 93.115.192.0/21 93.115.253.0/24 93.117.112.0/21 93.117.120.0/21 93.119.112.0/23 93.119.118.0/23 93.119.120.0/23 93.119.124.0/23 94.176.224.0/20 176.126.168.0/23 176.126.170.0/23 176.126.172.0/23 176.126.174.0/23 176.223.64.0/23 176.223.108.0/24 176.223.111.0/24 176.223.116.0/23 176.223.118.0/24 176.223.167.0/24 176.223.172.0/22 176.223.176.0/24 176.223.177.0/24 176.223.178.0/23 176.223.190.0/24 188.212.22.0/24 188.212.48.0/20 188.213.64.0/20 188.213.112.0/22 188.213.116.0/23 188.213.118.0/24 188.213.119.0/24 188.213.120.0/23 188.213.122.0/23 188.213.124.0/22 188.213.144.0/20 188.213.176.0/22 188.213.180.0/22 188.213.184.0/22 188.213.188.0/22 188.215.18.0/23 188.215.20.0/22 188.215.192.0/19 188.241.188.0/23 188.241.192.0/22 217.19.4.0/24

11 20

Symantec / Message Labs contact?
by Robert Glover 16 Jan '13

16 Jan '13

Hello, We are having a really hard time getting a hold of Symantec / Message Labs regarding one of our mail servers getting a "Connection Refused" when trying to send to any domains hosted with Symantec / Message Labs. Can someone please contact me? Sincerely, Bobby Glover Director of Information Services SVI Incorporated

1 0

Anyone from google networking on this list?
by tglassey 16 Jan '13

16 Jan '13

If there is anyone from Google Networking here on the list can you contact me offlist please. I want to talk about 60 Hudson. Todd Glassey -- Regards TSG "Ex-Cruce-Leo" //Confidential Mailing - Please destroy this if you are not the intended recipient.

1 0

Leasenet Dallas outage yesterday
by Tim Connolly (FC) 16 Jan '13

16 Jan '13

Did anyone else have an outage using LeaseNet in Dallas, TX yesterday? Cleared up at 9:30am local. Equipment is hosted at Equinix/Infomart.

1 0

Re: RIPE cookies [was]: Dreamhost hijacking my prefix...
by Scott Weeks 16 Jan '13

16 Jan '13

--- jbond(a)ripe.net wrote: From: john <jbond(a)ripe.net> ----- On 1/11/13 8:28 PM, Scott Weeks wrote: ----- > RIPE needs to fix on their web site: > "Please turn on the cookies on your browser to view this site." > It doesn't have to be this way... ----------------------------------------- I took a look at this site and unfortunately the use of cookies is very ingrained into the code. Removing the requirement breaks all functionality of www.ris.ripe.net and changing the functionality would require a rewrite of the site. Our intention is that http://stat.ripe.net/ will replace all functionality currently under www.ris.ripe.net. If RIPEstat doesn't provide the functionality you are looking for, please request it by emailing us at stat(a)ripe.net. ---------------------------------------------------------- Hi john, First, thank you for responding. Second, what a bummer that RIPE's code was written that way in the first place. If it's done that way in stat.ripe.net as well, I (and others who are security-minded) will never get to use your site. Maybe give "brian at merit" a holler before writing stat.ripe.net in such a way that one MUST allow cookies just to look at the site. Maybe it's too late already. :-( I haven't looked, yet... scott

1 0

looking glass for Level 3
by Tassos Chatzithomaoglou 16 Jan '13

16 Jan '13

Anyone have any looking glass for Level 3? The following seem not to be working http://www.level3.com/LookingGlass/ http://lg.level3.net/bgp/bgp.cgi http://lookingglass.level3.net/ -- Tassos

7 7

Re: Problem with email to Hawaiilink.net email
by Scott Weeks 16 Jan '13

16 Jan '13

--- royboy(a)umich.edu wrote: From: Roy hockett <royboy(a)umich.edu> http://www.staradvertiser.com/news/breaking/186990051.html --------------------------------------- You just gotta love living in the boonies! ;-) "The Kauai Police Department said they are experiencing intermittent phone outages due to a technical issue with their service provider, Hawaiian Telcom. The department asks that Kauai residents limit 911 calls to emergencies only until the issue is resolved." scott

1 0