Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration

From: Derek Atkins <[email-masked]>
Date: 07 Feb 2003 09:58:41 -0500

Ted Lemon <[email-masked]> writes:

> You could do an additional validation where if someone wants to stuff
> a new valid into an old PTR record, the DNS server looks to see if the
> old FQDN in that PTR record still points back to the address referred
> to by the PTR record, and if it does, refuses the update.   This
> prevents PTR record stealing.
> 
> Is there some other attack I'm not thinking of here?

I rightfully grab an address and go through the process.  Then I go
offnet without removing my forward pointer.  My "lease" expires.  The
next person who happens to get my address can no longer get the PTR
entry because the old (stale) forward entry is still there.

> Obviously this assumes that the DNS server for the zone in question is
> willing to have arbitrary clients establish PTR records.   I can
> imagine a variety of administrative policies, from "allow all domains"
> to "allow only this set of domains" to "allow only my domain" to
> "allow no PTR updates at all."

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Feb 2003 13:08:17 -0600

> entry because the old (stale) forward entry is still there.

Yup.   We can't do much about this case without adding extra complexity 
we'd probably rather avoid.   Does that render the technique Not Useful?

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Feb 2003 18:39:07 -0500

> we'd probably rather avoid.   Does that render the technique Not Useful?

</tact>

well, imiho, you were already three klud^H^H^Hheuristics deep and
the basic dynmaic update it all relies on is still not reliable in
my daily use experience.

randy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 11 Feb 2003 10:53:37 +0100

> entry because the old (stale) forward entry is still there.

Huhhh??? The host that is managing the addresses also manages the
reverse tree.  As soon as an address is assigned to a new MAC address
the PTR should change to a default vallue or be dynamically updated by
the new host.

It would be a strange world if I would not be able to get a PTR RR
because somebody else uses a stale forward mapping.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 10:00:42 -0500

> the PTR should change to a default vallue or be dynamically updated by

You're thinking of a V4 world.  Think "V6 Autoconfiguration".  When
using autoconfig the "host that is managing the address" is "MY
HOST".  My host, plugging into a v6 network, is certainly not in
charge or managing the reverse tree.

Not everyone in the v6 world is using DHCPv6.  In fact the IETF in
Atlanta certainly wasn't.

However we still want "proper" dns in such a world.

> because somebody else uses a stale forward mapping.

Agreed, which is why I brought up the issue.

-derek

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 20:02:47 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:
    >>> Sorry, misuse of terminology.  It sends an update to the reverse
    >>> server signed in the private half of the SIG key from its forward
    >>> FQDN.  The reverse server has to know to do step 6 to validate the
    >>> update.
    >> because my laptop has a relationship to the server for psg.com, and
    >> can put something kinky into the forward name should not mean that the
    >> owner of the reverse zone should trust the data in the forward zone or
    >> that the laptop asserts.  is the attack not pretty obvious?

    Ted> It was a rough outline.  Obviously the checking the reverse server
    Ted> has to do to make it work is more than what I said, but it's totally
    Ted> doable.  The validation I described prevents a random host on the
    Ted> network from trivially stuffing the DNS server with bogus PTR
    Ted> records.  You could do an additional validation where if someone
    Ted> wants to stuff a new valid into an old PTR record, the DNS server
    Ted> looks to see if the old FQDN in that PTR record still points back to
    Ted> the address referred to by the PTR record, and if it does, refuses
    Ted> the update.  This prevents PTR record stealing.

  Maybe. I'm not convinced that the failure cases are tractable, or can
easily be dealt with. 

    Ted> Obviously this assumes that the DNS server for the zone in question
    Ted> is willing to have arbitrary clients establish PTR records.  I can

  It would a lot easier if a machine on the local LAN can control things to
a finer degree. A lot easier to deal with the trust relationships. It
provides a clearly local place to put administrative overrides, and to clear
up confusion. Such a machine can much more clearly check reachability of the
"client".

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [