Re: 2008.02.20 NANOG 42 IPv4 PTR queries for unallocated space

Just FYI:

Leo's email address is

<leo.vegoda@icann.org>

Regards,
-drc

On Feb 20, 2008, at 10:34 AM, Matthew Petach wrote:

>
> Notes from day 4 of NANOG 42, we're on the home stretch now,
> so there's only a bit more of my spewage to wade through before
> we can resume our normal discussion of the imminent death of
> the internet as we know it. :)
>
> Again, apologies for typos, misspellings of names, etc.
>
> Matt
>
>
>
> 2008.02.20 opening remarks and analysis of PTR
> queries for IPv4 reserved addresses
>
> Trying to measure use of unallocated IPv4 address
> space
>
> Starting with Leo Vigoda, working at IANA now.
> leo.vigoda@icann.org
>
> At last NANOG, did lightning talk about how people
> were using unallocated space, but didn't show lots
> of data.
>
> Now, has a way to hopefully measure IPv4 addresses
> that people are trying to use.
>
> Not all the addresses, but at least one view of it.
>
> Problem?
> All unallocated unicast space will eventually be
> allocated; no more free /8's in the IANA pool at
> some point, as v6 won't get rolled out in time.
>
> Some people are using the same addres space that's
> currently in the 'unallocated' pool.
>
> Tried to measure it by looking at DNS queries at
> l.root for addresses in the unallocated blocks.
> root servers provide in-addr.arpa delegations,
> if a /8 isn't allocated, there's no delegation,
> so the root servers see the queries.
>
> Can't measure well-maintained networks with
> split-horizon DNS, or with good egress filters.
>
> Doesn't know how to measure truly private
> internal use; if you have ideas, let him know.
>
> Results slide; long blue line at the far left,
> lots and lots of queries, then shallows off to
> the right side; some old rubbish names in in-addr
> people are querying for.
>
> Left side is the fun stuff.
>
> 222/8, allocated to APNIC; not sure why it gets
> a lot more queries than the other /8's. Could be
> mail server lookups, since there's a lot of mail
> that comes out of 222/8; could be one rogue server.
> If you assume it's bogus, and chuck it out, data
> 'looks' better.
> 10/8 is near the top, as expected.
> 0/8 RFC3330
> 2/8 is unallocated; in the top 15 range. Odd there's
> unallocated space so close to the top of the queries
> range.
> If you take out all the unallocated stuff, there's
> still a lot of entries; looking at top 10 list:
> 2/8, 1/8, 23/8, 5/8, 100/8 is there at #5, which
> is odd. the next /8's they *were* going to give
> ARIN were 100/101, they decided to NOT give it
> out to figure out why there's so many hits on it
> in this round.
>
> The top 10 list is the 30 day period ending sunday;
> he also compared to statistics he used at the esNOG
> meeting in madrid a few months ago.
>
> Not very static; people leave top 10, new come on.
>
> 28dec-26jan, vs 19jan to 17feb
>
> 2/8 and 1/8 stay in #1 and #2
> other /8s shift; 5/8 rises, 23/8 rises, 100/8
> drops, 27/8 drops.
>
> It's not static, there's movement, people are
> shifting and shuffling blocks.
>
> Not measuring the query source address and AS #
> that could be gathered to inform people they're
> trying to talk to unallocated space.
>
> Only gathering from l.root, would be good to get
> data from other root servers.
>
> Leo's not a proper researcher, so would be good to
> get skillset from a real researcher.
>
> Would like to get data from nodes all over the
> world to get more global information; can see if
> there's more of a local component, or if this is
> a global phenomenon. This would be a very big
> data analysis challenge, combining l, k, and other
> root server operators, and get a more complete view
> of the data.
>
> Use it to either warn people, or help get things
> fixed if at all possible.
>
> Q: Louis Lee, Equinix, want to find out if they've
> looked to see if the top10 prefixes are in the global
> routing table when the queries come in?
> A: No, that hasn't been looked at, but a proper
> researcher would probably have considered and
> tied that data in as well.
>
> Q: Leo Bicknell, ISC: did they look at the source of
> queries? Are they all coming from a common
> resolver?
> A: no, not yet; would be the sort of thing that a
> proper researcher would be able to dig into.
> There are privacy considerations with looking at
> sources of queries, etc; needs to be thought
> through very carefully to make sure no per
>
> Q: Keith Mitchell, Interesting work, thanks Leo;
> there's lots of information for gathering, sharing,
> and protecting privacy in OIRC; if he would like
> to work with OIRC, they can give pointers on how
> to handle that data with necessary
>
> Q: further instrumenting to see if there's noise
> in the allocated space to see if this may be just
> part of overall background noise?
> A: this is the raw, basic data
>
> Q: Duane Wessels, measurement factory; DNS queries
> behave differently when a result exists vs doesn't
> exist; may be worthwhile to temporarily make them
> exist on a set of servers, and collect the data
> from there, and see if the resolution process
> follows the delegation.
>
> Q: Troy Jessup, Utah edu network; could 1, 2, 100,
> etc. network queries be due to malware that starts
> at one end of a block and just starts scanning
> indiscriminantly. 100 seems to be a common starting
> point for malware, for example.
> Haven't looked into it in that much detail--is it
> just 1.1.1.1/32, or 1.1.1.1/16, how much coverage
> within the block is there? is it just hot spots?
> These are really good ideas for the Real Researcher(tm)
> to delve into, once one can be tracked down.
>
> If people want to send suggestions, email him at
>
> leo.vigoda@icann.org
>
Received on Wed Feb 20 15:36:31 2008