unsub=scribe please
[carl gough] founder and CEO +61 425 266 764 mobsource.com On 17/01/13 11:00 PM, "[email protected]" <[email protected]> wrote: >Send NANOG mailing list submissions to > [email protected] > >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 > [email protected] > >You can reach the person managing the list at > [email protected] > >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: " ." <[email protected]> >Cc: "North American Network Operators' Group" <[email protected]> >Subject: Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT > Instead of IPv6 >Message-ID: > <cacg3zyf65y2khi18n2azezbvarexycubzncga8kipytsdz+...@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 <[email protected]> >To: [email protected] >Subject: Re: Notice: Fradulent RIPE ASNs >Message-ID: <[email protected]> >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 <[email protected]> >To: Shrdlu <[email protected]> >Cc: [email protected] >Subject: Re: Suggestions for the future on your web site: (was > cookies, and before that Re: Dreamhost hijacking my prefix...) >Message-ID: <[email protected]> >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 >*************************************
