Subject: [dnsext] An efficient method to publish ranges of IP addresses in the DNS

From: John Levine <[email-masked]>
Date: 22 Dec 2010 04:51:23 -0000

[ I also sent this to dnsop, which may be more appropriate. ]

We all know how DNSBLs and DNSWLs work for IPv4 addresses, just like
rDNS only with A or TXT records rather than PTR.

When I wrote RFC 5782 I assumed the same thing would work for IPv6
addresses.  But I was wrong -- the address space is so big that a
modestly hostile opponent can use a different IP address for each
message, which would cause disastrous cache behavior and equally
disastrous amounts of traffic to the DNSBL's servers.

So I came up with an entirely different way to store and query the
data in the DNS, which as far as I can tell will have excellent
performance and cache behavior, even if bad guys are hopping all over
the IP address space.  Take a look, tell me if I'm nuts:

http://www.ietf.org/id/draft-levine-iprangepub-00.txt

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Florian Weimer <[email-masked]>
Date: Wed, 22 Dec 2010 08:25:53 +0000

> http://www.ietf.org/id/draft-levine-iprangepub-00.txt

I think the crux is this:

   One significant practical difference is that it is much easier for
   clients to obtain copies of all or part of the database.

If this isn't a problem, why not publish the list of CIDRs directly
(perhaps with incremental updates based on WebDAV/VCDIFF)?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 22 Dec 2010 10:02:29 -0500

> (perhaps with incremental updates based on WebDAV/VCDIFF)?

It's the same reason that even though you can FTP a copy of the whole .COM 
zone, most people prefer to use the DNS.

For very large mail systems, it is indeed common to keep a local copy of a 
DNSBL, typically updated by rsync.  But most mail systems are not very 
large, and it's more efficient for them to query the entries they need. 
My goal here is to keep the aggregate traffic from the non-giant mail 
system from overwhelming caches and servers.

Regards,

---

From: Brandon Black <[email-masked]>
Date: Wed, 22 Dec 2010 12:08:30 -0600

On Wed, Dec 22, 2010 at 9:02 AM, John R. Levine <[email-masked]> wrote:
> large, and it's more efficient for them to query the entries they need. My
> goal here is to keep the aggregate traffic from the non-giant mail system
> from overwhelming caches and servers.

Even for low volume mail systems, is it really true that DNSBL usage
is more efficient (not to mention reliable?) than rsyncing a fixed
list on a reasonable schedule given some engineering to have a good
list of rsync mirrors and randomize the request times?

-- Brandon

---

From: "John R. Levine" <[email-masked]>
Date: 22 Dec 2010 13:39:07 -0500

> list of rsync mirrors and randomize the request times?

The widely used CBL has about 7 million entries, and is updated every 15 
minutes.  That's an awful lot of rsyncing for a system like mine that only 
gets 100,000 mail connections per day.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Dec 2010 17:23:26 -0800

On 12/22/10 10:39 AM, John R. Levine wrote:
> The widely used CBL has about 7 million entries, and is updated every 
> 15 minutes.  That's an awful lot of rsyncing for a system like mine 
> that only gets 100,000 mail connections per day.
John,

Question the eventual complexity of this information.  The typical size 
of most prefixes (above the interface) assigned to entities already 
represents a range roughly 10,000 times greater than that used by v4.  
This estimate ignores the 64 bits found within the interface, which you 
also hope to map.  With v6 networks and addresses made freely available, 
there is nothing that suggests malefactors will cooperate and 
consolidate their locations.  Also B-Trees depend upon synchronous 
updates of related nodes.  CNAMEs are not a remedy for nodes already 
cached, which is something that can be exploited.

See:
  http://ipv6.he.net/bgpview/bgp-page-complete.html

A significant advantage of v6 is the ability to renumber networks 
quickly.  A white-listing scheme based upon v6 addresses will 
essentially destroy this ability.

Dealing with 6 million legitimate sources by host name is something DNS 
can handle within a single transaction without making v6 fragile.  (It 
would be better to authenticate hosts cryptographically, which your 
scheme ignores.)  v6 makes constructing address block-lists an effort 
likely to flood available system memory. Trapping networks controlled by 
malefactors is best done with BGP filters.  Trapping host names 
controlled by malefactors is best done with RPZ zones. Both schemes can 
be dynamically updated, and then offered as a service to smaller entities.

-Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 12:23:59 +0000

How about this as an approach

1) use a new RR that is designed for RBL use.

2) Subtype the RR to support the following uses:

A) Meta-Data Declarations
B) Granularity specifications
C) RBL assertions

So the apex of blocklist verybad.info might contain the following
declarations:

Meta: The semantics are defined in format x at http://blahh
Granularity: IPv4 24 bits
Granularity: IPv6 12 bits
Assertion: IPv4 / Granularity=8 bits / <bitmask> / Unroutable
Assertion: IPv6 / Granularity=8 bits / <bitmask> / Unroutable

So the apex record in the zone tells receivers how to interpret the zone
data and that there are IPv4 and IPv6 versions.

Bitmasks allow us to quickly declare the reserved and unroutable sections as
being out of scope. if no bitmask declaration matches, resolution continues
at the next lowest level of granularity.

To perform the next level of resolution, we chop off whatever length of
prefix is required, convert to hex and use it as a prefix label:

_283.ipv6.verybad.info
Assertion: IPv6 / Granularity=8 bits / <bitmask> / Unroutable
Granularity: 52 bits

And so on.

We can be very confident that the NICs will issue address ranges in a
reasonably compact fashion. What we cannot know now or reasonably predict is
what the issue increments will turn out to be once the system is running in
steady state. We can know what they intend, but not what they will find
works in practice.

An alternative to the bitmask approach would be to specify address ranges.
This might yield a more compact representation.

Another point to consider is that ISPs might well find it convenient to use
a record of this type to help RBL type schemes by describing the structure
of what they provide.

A broadband ISP is likely to assign IP addresses in fairly large blocks.
Each residential user receiving a /64 perhaps. If one address in such a
block is compromised then likely all are compromised.

A co-loc facility might well assign IP addresses on a case by case basis.
Each machine asks for as many IP addresses as they need, but they all come
from the same /64 allocation that the ISP obtained. The fact that one
machine is compromised does not mean that we should automatically block
every machine in the facility.

So in some cases we need only 64 bit resolution, in another we need the full
128 bits.

This approach will require more round trips than at present, but that would
not worry me unduly. The granularity declarations are likely to cache for
extended periods in any case.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 23 Dec 2010 09:23:49 -0500

> Assertion: IPv6 / Granularity=8 bits / <bitmask> / Unroutable

My original thought was something like that.

It fails completely for whitelists, which by their nature include single 
addresses.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 17:42:46 +0000

I don't agree.

I have a whitelist declaration from Google, isn't it likely to be for a  /48
or so?

But more generally, I would like to get away from having to separate out
white and black. Even on a whitelist I would want to block out unroutable
space.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 23 Dec 2010 14:03:43 -0500

> I have a whitelist declaration from Google, isn't it likely to be for a  /48

No, it's individual sending hosts.

> white and black. Even on a whitelist I would want to block out unroutable

The people I know who use DNSBLs and DNSWLs have shown little interest in 
complex assertions about what they mean.  If an address is in a DNSBL it's 
bad, if it's in a DNSWL, it's good.

Regards,