Subject: Re: IPv6 and Dynamic DNS

From: Jerry Scharf <[email-masked]>
Date: Wed, 4 Aug 1999 12:14:12 -0700 (PDT)

Terry,

It is trivial for anyone in the path to reply with a packet before one
of th real nameservers do, and put any content they want in it. This is
one of the main reasons for the entire DNSSEC effort. It's a feature of
the current DNS design, so looking to it for security is just bad.

Second, the problem with dealing with dynamic update of both the forward
and reverse records is that they have dramatically different ownership
models. My name belongs to me, but the IP address belongs to the DHCP
server. So do I give the DHCP server proxy rights to update my name (bad),
give me the proxy rights to update the reverse (worse), have two
independent actions that are not guaranteed to be in synch (bad) or
punt one of the directions (bad).

Discussing this without bringing folks from the DHCP group in is probably
not a completely useful use of bandwidth. I know they have discussed this
issue many times and need to be part of any final solution.

jerry

---

From: Terry Lambert <[email-masked]>
Date: Wed, 04 Aug 1999 14:30:41 -0700

Jerry Scharf wrote:
> 
> Terry,
> 
> It is trivial for anyone in the path to reply with a packet
> before one of th real nameservers do, and put any content
> they want in it. This is one of the main reasons for the
> entire DNSSEC effort. It's a feature of the current DNS
> design, so looking to it for security is just bad.

Exactly right.  I would class this as a betrayal of implicit
trust, in the current model.  I must implictly trust my
upstream to not lie to me.  I understand the rationale behind
not wanting to have implicit trust, but until things are
improved (i.e. TLS or DNSSEC is deployed), we are stuck with
a man-in-the-middle vulnerability.

I guess a good (rehetorical) question at this point is,
"which will be available first, IPv6, or DNSSEC?"; it's
rhetorical, because IPv6 is available, and getting deployed,
now.  You can install IPv6 (via KAME) on FreeBSD today, and
you will immediately have applications, including an IPv6
enabled Mozilla, available for download.

I think the road to hell is paved with documents like
RFC 2554.   Embedding authentication into every single
legacy protocol you need to use can't be the right answer.

> Second, the problem with dealing with dynamic update of
> both the forward and reverse records is that they have
> dramatically different ownership models. My name belongs
> to me, but the IP address belongs to the DHCP server. So
> do I give the DHCP server proxy rights to update my name (bad),
> give me the proxy rights to update the reverse (worse), have
> two independent actions that are not guaranteed to be in synch
> (bad) or punt one of the directions (bad).

I'd like to take DHCP out of this.  Say, instead, I do IPv6
autoconfiguration.  I'm doing this because I'm either a
"visitor" at a network attachment point, without a DHCP
configuration available, or because I want to do away with
the hassle of having to explicitly configure "non-visitors".

This gets rid of the DHCP proxy rights issue, and it gets
rid of the endangering part of my private address space by
allowing someone to use it issue.

In that case, part of the IP address belongs to where I
attach to the network, and part of it belongs to me.

Looking at the standard delegation model in DNS, this is
the rough equivalent of .com. (the attach point) delegating
authority over visitor.com. (the autoconfiguration space
in which my machine resides) to me (the machine).

I don't see how it's any worse to allow an autoconfigured
machine control over its own reverse address record, for
the part of the address space that belongs to it.

It seems to me that the same "security" afforded by using
a forward/reverse correlation combined with an IP address
"ban" (e.g. the RBL) could be applied to the machine
owned portion of the IP address space.

I also don't see how DHCP doing DDNS is going to work, in
a DNSSEC environment.

If the DHCP server wants to do a DDNS update, wouldn't it
have to employ a knapsack algorithm consisting of my
certificate ("Hi, I'm foo.whistle.com"), the certificate
of the DNS server containing the forward SOA ("Hi, I'm
the DNS for whistle.com, and I will vouch for 'foo'"),
the certificate for the DNS server it's trying to update
the reverse in ("Hi, I'm the DNS for visitor.com"), and
the certificate for the DHCP server ("Hi, I'm a DHCP
server allowed to update reverse records in visitor.com")?

This seems too complicated.

Where does the trust between the forward and the reverse
get established?  Or is it OK to update the reverse on
an automatically assigned address if the DNS for whistle.com
vets foo.whistle.com as being a whistle.com machine?

I have a real problem with trying to apply an RBL-type
mechanism in this scenario, without blacking out IP
addresses in visitor.com's domain, which is what would
happen if we are talking about a DHCP address pool, as
opposed to a machine specific autoconfiguration address
component in _any_ autoconfiguration space.

[ ... visions of SPAMmer's with laptops sitting in
  "wired" airport lounges sending off 1000 message
  "bursts" before moving on ...]

Is the idea that foo.whistle.com would use _no_ other
resources from visitor.com, other than the reverse
address entry, and be forced to relay mail, etc.,
though its "home base", despite the multiplication
of network traffic, should this become common?

[ I guess this is a different "travelling salesman"
  problem... 8-) ]

If so, how is this different than just allowing the
reverse assignment, and verifying that the forward
and the reverse match?

And how does a laptop from whistle.com in a visitor.com
conference room access the projection display service in
the conference room -- another certificate, requiring
more human intervention?

> Discussing this without bringing folks from the DHCP
> group in is probably not a completely useful use of
> bandwidth. I know they have discussed this issue many
> times and need to be part of any final solution.

Maybe.

I would actually like to throw the DHCP server configuration
for visiting machines requirement out the window.  It seems
to me that the complexities of attempting to use DHCP as a
conduit for certification by proxy will make it a non-starter
for the "visiting computer you want to partially trust" case.

-- Terry Lambert
-- Whistle Communications, Inc.
-- [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.