Re: NANOG Digest, Vol 60, Issue 54

["carl gough [mobsource]" <carl () mobsource com>]

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
> *************************************