Subject: Re: Unfinished DNS UPDATE work...

From: Dean Anderson <[email-masked]>
Date: Wed, 03 May 2000 11:59:40 -0400

Around 04:23 PM 5/2/2000 -0400, rumor has it that Kevin Darcy said:
>I'm not sure what you mean by "commandeer". Can a server not check
>delegations and/or the zone SOA to verify that the entity which is
>requesting a master-slave relationship isn't just some random pirate?

If a zone is created dynamicly, then no. At least, as has been discussed.

But I think you suggest that perhaps it might be reasonable for the server
to permit masters for which the server has staticly configured slave zones
to create zones.

Then there is already a prexisting master/slave relationship for some zone,
and it seems reasonable one might slave for other zones from the same
master server.

This avoids the need for a complicated additional trust exchange protocol.

I can't see why you would ever have a slave server without any staticly
configured slave zones, so such a relationship either already exists, or
the update is from a random pirate, and should be denied.

		--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
           Plain Aviation, Inc                  [email-masked]
           LAN/WAN/UNIX/NT/TCPIP          http://www.av8.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Terry Lambert <[email-masked]>
Date: Wed, 03 May 2000 11:49:47 -0700

All in all, a lot of productive comments and thought,
which is exactly what I had hoped would happen!  It seems
it may be time for some experimentation on the side, but
we should keep the discussion going, so here's a couple
more comments:

Harald Tveit Alvestrand wrote (commenting on John Gilmore's note):
[ ... ]
> at the moment, it seems to me that a signed NOTIFY is
> required for this to make sense, but don't know if NOTIFY
> contains the required information or if it can be signed
> in the Right Way so that configuration is easy at the
> slave side, or if the sig on the NS in the notified zone
> is the Right Thing to check instead.

One caveat: DDNS doesn't currently require signatures,
since you are permitted to statically configure access
control lists.  This same mechanism could be used, in
lieu of signatures, to provide the capability.

Dean Anderson wrote:
> >I'm not sure what you mean by "commandeer". Can a server
> >not check delegations and/or the zone SOA to verify that
> >the entity which is requesting a master-slave relationship
> >isn't just some random pirate?
> 
> But I think you suggest that perhaps it might be reasonable
> for the server to permit masters for which the server has
> staticly configured slave zones to create zones.
> 
> Then there is already a prexisting master/slave relationship
> for some zone, and it seems reasonable one might slave for
> other zones from the same master server.

In fact, one could statically establish this relationship,
e.g. "I am the slave for at least one zone from this master",
by configuring the slave as a [stealth] slave of the master's
own zone, assuming it's self hosting, or any one zone, in the
unlikely case that it is not.

> I can't see why you would ever have a slave server without
> any staticly configured slave zones, so such a relationship
> either already exists, or the update is from a random pirate,
> and should be denied.

I can see several cases where this might not be something
that would be configured.

I think that you could adapt John Gilmore's excellent
suggestion to cover this case, though, by permitting the
NOTIFY-based-create in the options section of the slave,
without requiring a zone be preconfigured.

One could imagine an "empty" slave being populated by a
master using the "NOTIFY to create SOA in case of NS
record specified to master" to trigger the notify by the
master to the slave.

If we didn't use the ACL method, but instead used the
preestablished relationship method to control this, we
could do this merely by configuring the slave as a stealth
slave for one zone, thus permitting non-stealth zones to
be configured by master NOTIFY events.

I think it's now time for me to start grovelling through
the relevent RFCs for NOTIFY, and to see what it would
take to ACL at least SOA creation on the master by way of
the options configuration, instead of the assumption of a
preexisting SOA for the zone being modified... maybe the
code can also be directly applied to the slave, as well,
if it's done right.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: "Cricket Liu" <[email-masked]>
Date: Wed, 3 May 2000 13:26:37 -0600

> to permit masters for which the server has staticly configured slave zones

Or simply add a new server substatement like:

server 192.168.0.1 {
    allow-add-slave-zones yes;
    keys { foo-bar.; };
};

Using TSIG to authenticate powerful mechanisms
like this would be a good idea, I think.

> and it seems reasonable one might slave for other zones from the same

I'd rather define that on a master-by-master basis.

> the update is from a random pirate, and should be denied.

There's the much-sought-after "slave for all zones this primary
master is authoritative for."  It'd be nice to bootstrap a new slave
with just a server statement like the above.

cricket

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 04 May 2000 08:07:44 +0200

>lieu of signatures, to provide the capability.

What are ACLs usually based on?

If you're using source IP as an authenticator for a connectionless, 
no-handshake protocol, I've got a great bridge to sell you..... from RFC 
2136 (Dynamic Update):

8 - Security Considerations

    8.1. In the absence of [RFC2137] or equivilent technology, the
    protocol described by this document makes it possible for anyone who
    can reach an authoritative name server to alter the contents of any
    zones on that server.  This is a serious increase in vulnerability
    from the current technology.  Therefore it is very strongly
    recommended that the protocols described in this document not be used
    without [RFC2137] or other equivalently strong security measures,
    e.g. IPsec.

Source IP + requirement that MAC is on the local wire mostly works as a 
defense against the outside bogons, if you can swing it, I think. (Against 
the insider there are few good non-cryptographic defenses).

But this is not a common case for zone-transfer stuff.

                          Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Thu, 04 May 2000 11:22:25 -0700

> What are ACLs usually based on?

IP address.

> If you're using source IP as an authenticator for a
> connectionless, no-handshake protocol, I've got a great
> bridge to sell you..... from RFC 2136 (Dynamic Update):

You would require TCP for this.  The connection would not
be established unless the source IP was valid, in the
absence of source routing.  I don't know of any networks
(non-experimental) which enable source routing at this time.

>     8.1. In the absence of [RFC2137] or equivilent technology,

I think that IP based ACLs requring a TCP connection can
be considered "equivalent technology".

-- Terry Lambert

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 04 May 2000 21:40:49 +0200

>(non-experimental) which enable source routing at this time.

this = what? the initial NOTIFY, or the slave-initiated zone transfer?

The initial NOTIFY is most likely UDP; easily faked.

The outgoing AXFR would be sent to the address given as the source of the
NOTIFY, and could be hijacked by an adversary with the ability to listen to 
outgoing packets and reply with fake-source-address packets; such an attack 
was used at MIT to break encrypted sessions in Netscape (by modifying the 
page in Netscape that contained the crypto code when it was loaded using 
NFS from the fileserver).
Alternatively, an attack on the routing tables of any router between the 
fake-source-address and the server being attacked would give access.

With luck, you could even manage to hijack the session without being able 
to listen; that's what sequence number attacks are for.

This vulnerability is noted in RFC 1996 (NOTIFY), btw.

                          Harald

---

From: Terry Lambert <[email-masked]>
Date: Thu, 04 May 2000 16:41:52 -0700

> this = what? the initial NOTIFY, or the slave-initiated

Using source IP as an authenticator.  If it wasn't TCP,
you wouldn't permit zone creation.

This is practically the same case as with signatures, where
the payload bloats so big the packets have to go TCP anyway.

> The initial NOTIFY is most likely UDP; easily faked.

If it's UDP, you refuse the zone creation.  Period.  So
the rest of the argument predicated on UDP is irrelevant.

There are really two cases here: (1) someone substitutes
data, or (2) someone utilizes my servers to serve legitimate
data, without my permission.

Nothing stops them from hijacking normal zone transfers
today.  If we are worried about substitute data, then
solve that problem first.  Zone transfers are less
likely than zone creation.

If someone legitimately owns a zone, has it pointed at
my server without permission, and hacks my server so that
it serves their zone for them, well, I'm not the guy
getting paid for zone registration in the first place,
so I really don't care.  Compared to my normal server load,
that's noise.  If they asked me with as much effort as a
hack would take, I'd probably have done it for them.

> Alternatively, an attack on the routing tables of any
> router between the fake-source-address and the server
> being attacked would give access.

If they are in control of any part of the network
infrastructure between my servers, I'm screwed anyway.

Why don't I just wait for TLS in IPv6, when all of this
signature cruft becomes irrelevent anyway, because I can
trust the remote machine's identity?

I just want the best resolution available within the near
term future.  John Gilmore's and other suggestions look
like it, unless someone has something else productive to
add about solving the problem, instead of why it can't be
solved until six years from now.

Thanks,
-- Terry Lambert

---

From: Andrew Brown <[email-masked]>
Date: Thu, 4 May 2000 23:54:20 -0400

>(non-experimental) which enable source routing at this time.

perhaps i'm a cynic, but i'm pretty sure you're talking about the
"other" half of the internet.  you might have turned it off, and i
sure have, but has *everyone* else done so?  i think not.

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 04 May 2000 21:34:24 -0700

> This vulnerability is noted in RFC 1996 (NOTIFY), btw.

all of the reasons why zone creation isn't specified yet are in the later
dns rfc's and in the namedroppers archives (including the dnsind minutes).
it's not that it should not be done, but rather, that it's not a simple
knob that was merely forgotten in the other specifications -- it's a big
deal.  a hard problem.  a task worthy of a hero.

such a hero would have to do his or her homework first, though.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 05 May 2000 19:45:11 -0400

> such a hero would have to do his or her homework first, though.

I searched the entire namedroppers archives available at
ftp://ftp.ietf.org/pub/lists for compound phrases containing both "zone" and
"creation" (the term you used) or reasonable variations thereof, and got only
2 relevant hits (by "relevant", I exclude variations of the RFC text itself
explaining that zone creation isn't currently possible with Dynamic Update,
since we've already seen that in this thread):

#1: Bill Simpson questioned the aforementioned RFC text, in November of 1996,
and asked "..., doesn't this preclude us from using this for distributed
updating of the TLD zones?". As far as I can tell, no-one answered his query.

#2: in response to a generic "why can't I create a zone with Dynamic
Update?"-type question, from Matt O'Connell in May of 1998, the following
answer was given by James Cutler:

>        Zones form the shape and structure of the name tree.
>        The structure must be designed and put into place.
>
>        RRs are leaves on the tree and may grow and fall off.
>        This is an operations issue, not a design issue.
>        Dynamic updates support the operation within the design.

This is hardly in the same category as the "it's really hard" hand-waving
I've been seeing lately.

I also eyeballed all of the messages with "minutes" in their Subject: lines,
just in case the mechanical search might have missed relevant content using
slightly different terminology. Zilch.

The same mechanical search of all of the RFC's in the BIND 9 Beta 2 "doc/rfc"
directory yielded no relevant hits.

Could you provide some more specific pointers?

Or, better yet, could one of the "it's really hard" oldbie faction give a
quick *summary* to us "why not?" newbies? This might be more efficient than a
bunch of folks running around trying to hunt down references in RFC's and old
list archives.

---

As a potential slave, if I have a list of all the servers which are allowed
to initiate master-slave relationships with me, and I get a crypto-verified
NOTIFY from one of them, and I (optionally) check the delegations, optionally
with crypto-verification of the responses to verify that, yes, the server
sending me the NOTIFY really has been delegated the zone it wants me to
slave, how much more paranoid do I have to be before going ahead and becoming
a slave to the zone? What is the "hard problem" to be solved here?

- Kevin