NANOG Digest, Vol 60, Issue 54

Thu Jan 17 12:46:01 UTC 2013

unsub=scribe please

[carl gough] founder and CEO  +61 425 266 764

mobsource.com  

On 17/01/13 11:00 PM, "nanog-request at nanog.org" <nanog-request at nanog.org>
wrote:

>Send NANOG mailing list submissions to
>	nanog at 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 at nanog.org
>
>You can reach the person managing the list at
>	nanog-owner at 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 at gmail.com>
>Cc: "North American Network Operators' Group" <nanog at nanog.org>
>Subject: Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT
>	Instead of IPv6
>Message-ID:
>	<CACg3zYF65y2kHi18N2AZEzbvARExYCuBznCGA8KiPyTsDz+3Xw at 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 at gsp.org>
>To: nanog at nanog.org
>Subject: Re: Notice: Fradulent RIPE ASNs
>Message-ID: <20130117103334.GA7155 at 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 at ripe.net>
>To: Shrdlu <shrdlu at deaddrop.org>
>Cc: nanog at 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 at 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
>*************************************