unsub=scribe please [carl gough] founder and CEO +61 425 266 764 mobsource.com On 17/01/13 11:00 PM, "nanog-request@nanog.org" <nanog-request@nanog.org> wrote:
Send NANOG mailing list submissions to nanog@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@nanog.org
You can reach the person managing the list at nanog-owner@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@gmail.com> Cc: "North American Network Operators' Group" <nanog@nanog.org> Subject: Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6 Message-ID: <CACg3zYF65y2kHi18N2AZEzbvARExYCuBznCGA8KiPyTsDz+3Xw@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@gsp.org> To: nanog@nanog.org Subject: Re: Notice: Fradulent RIPE ASNs Message-ID: <20130117103334.GA7155@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@ripe.net> To: Shrdlu <shrdlu@deaddrop.org> Cc: nanog@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@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 *************************************