Subject: Re: IPv6 and Dynamic DNS

From: Robert Elz <[email-masked]>
Date: Tue, 03 Aug 1999 23:43:40 +1000

Date:        Tue, 3 Aug 1999 06:37:30 -0400 
    From:        "Cutler, James R" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Can we backstep a bit and better define the business and technical need for
  | updating DNS reverse entries?

This is certainly a valid question, and one of two responses I was half
expecting.    As long as we do it consciously, we can decide that the reverse
lookups don't achieve anything that matters very much, and so we should
just punt on how they would be automated (leave it to those who want them
to pick their own way - using DHCPv6, or manually, or whatever).

The other response I half expected was for someone to refer back to the
"who are you" ICMP message that was once mooted as a possible method to
perform this mapping - it has a host of other problems, but not the
particular one raised.

As long as the community decides, and makes known, the intended resolution
of this - be it a solution I can't see, or one of the above, I'll be happy
enough.   I just don't want to see this issue ignored, so if someone is
assuming that IP6.INT will just work, we either provide the mechanisms to
make that so, or we educate them that it is not going to happen.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Aug 1999 23:43:40 +1000

kre

---

From: "Cutler, James R" <[email-masked]>
Date: Tue, 3 Aug 1999 06:37:30 -0400

Can we backstep a bit and better define the business and technical need for
updating DNS reverse entries?  It seems clear that most usage is either:  1.
for the convenience of the service provider, or 2. for "poor man's
security".  Is there another.

Second, it seems that there is a clear differentiation between "just make
the d... thing work", which autoconfiguration does admirably, and controlled
update of DNS in response to address assignments.  Whether one uses pure
DHCP or adds a controlling element such as Lucent's QIP product, which
manages both forward and reverse DNS entries, is determined by the network
provider.

It seems clear to me that autoconfiguration is the favored approach for
small or temporary networks. The choice for large networks, as for example -
EDS Intranet, may well be different. This implies that DNS updates from
autoconfiguration may well not be a requirement.

	JimC

-----Original Message-----
From: Robert Elz [mailto:[email-masked]]
Sent: Monday, August 02, 1999 4:02 PM
To: Jim Bound
Cc: [email-masked]; [email-masked]
Subject: Re: IPv6 and Dynamic DNS 

    Date:        Mon, 02 Aug 1999 13:43:39 -0400
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well right now thats kind of how it must work.

Yes, and that's what I was asking about, as in general, that's not
a satisfactory method.  Or not for the kind of dynamic information
that is involved here (getting manually configured with a key is
fine for the forward zone, as the name changes rarely, and this is
easily possible - having to do the same for the address is beyond
reasonable as a burden).

  | Well its working in practice now in a sense with the DHCPv4 servers but
  | as you say at least there is some "implied" authorziation btw the DHCPv4
  | server and the client.  But not necessarily any real authority btw the
  | DHCPv4 server and the DNS master of the zone.

No, not necessarily, but it can usually be worked out, and this is the
assumption that has generally been made, and which I think underpins the
relevant DHCP options.   That is, while there isn't necessarily a
relationship between the admin of the DHCP server (who is allocating the
addresses to various objects on the net) and the zone file maintainer
for the in-addr.arpa (or ip6.int) zone file, who is publishing the
assigned addresses, in most cases these two entities are likely to work
closely together, and have arranged the mechanisms to do so - and if that
involves allowing the DHCP server to dynamically update the zone file,
then that will usually happen.

For IPv4 this (or manually having an adress assigned, and having the
zone file manually updated at the same time usually) are the only options.

For IPv6 we have this alternate, and much simpler, mechanism.   But it isn't
going to be a viable mechanism unless we also have a way to get the DNS info
updated - and right now I'm seeing nothing (not even any attempt) to find
that
method.

Note that this really has nothing whatever to do with key exchange per se, 
though that may become a component.  It is a question of authorisation, and
where that comes from.  Keys are just a method to demonstrate that
authorisation exists, they don't provide it in the first place, and it is
that first step that I don't see here.

  | 1.  I would like to point out that because a DHCPv4ORv6 does the update
  | does not mean its secure in DNS.

No, and this has nothing whatever do do with the question.

  | 2.  There is an M bit in stateless addr conf which right now the only
  | solution being proposed is DHCPv6.

Yes, I know, and if that method (any such method) is in use, then the
problem I forsee doesn't arise.  All the others you're alluding to are
still there, but those are at least known, and being worked upon, so I'm
not so worried about them.

  | 3.  Right now in addrconf in the case of BIND there are mechanisms to
  | build the key but we are just testing this now in 8.2.

This has nothing to do with the problem.

  | 4.  As far as the IETF ruleset for authentication I am hoping thats in
  | DNSSEC but I can't find it now.

I'm not sure what this means, but I suspect it is also missing the point.

  | 5.  It appears us vendors will deploy per #3 above and not wait for the
  | issues with #4.

Fine, but I still see nothing at all which addresses the problem here.

  | So maybe the result of your mail is we need to define key exchange
  | mechanisms as a standard for dyn upds to DNS?

No, nothing like that at all.

  | If so then I think its irrelevant if the update is done by the client or
  | the server?  Both need the same security measures.

Yes, they do.   The question is still how and where is the authorisation
to use whatever security measures exist is granted.   If a server is doing
the update, this is easy, as the existence of the server is known, it can
be allowed to use (via whatever mechanisms are appropriate) whatever it
needs to get its job done.    Since clients just appear, and the IPv6
autoconfig is supposed to let them just start running (assuming the net
admin
allows that, and remember I am assuming that here) I don't see how they're
going to be authorised to do anything at all (related to the address).

So we have no server (dhcp type server - this is the assumption) and
unauthorised clients (not clients without a key - unauthorised clients).
But we still have the ip6.int zone file to get updated, somehow.

  | Also there is nothing to prevent an IPv4 DHC client to upate DNS without
  | even going to the DHCPv4 server.

No, of course not, assuming the authorisation exists.   I believe that the
general assumption is that it won't normally do that for the in-addr.arpa,
since it isn't expected to have any a priori knowledge of what address
it is going to be given, it also can't be expected to have any authorisation
to make the update - however circumstances can be odd, and in some
circumstances the client may be able to perform the update.  The same would
be true for IPv6 in similar circumstances.   But this uninteresting case
does nothing to solve the general problem.   We get no closer to solve the
problem by pointing out the cases in which the problem doesn't exist, unless
you're also able to show that those cases cover all the relevant cases,
and here, I don't believe that is possible.

  | I would argue there is no difference between either zone file once you
have
  | the credentials at the client

Of course.   The question is where those credentials came from.   I thought
I had made that clear in the last mesage, if not in the first one.   Perhaps
I have this time?   And once again, this has nothing to do with any kind of
key distribution protocol - any of those must still require some kind of
authentication before blindly handing out any key that some random client
chooses to ask for.   Its at that level that the problem arises here.

kre

---

From: Terry Lambert <[email-masked]>
Date: Tue, 03 Aug 1999 15:57:43 -0700

Cutler, James R wrote:
> 
> Can we backstep a bit and better define the business and
> technical need for updating DNS reverse entries?  It seems
> clear that most usage is either:  1. for the convenience
> of the service provider, or 2. for "poor man's security".
> Is there another.

I think it's mostly "poor man's security", so things like
"sendmail" won't balk at talking to you.

I believe the theory is that you can trust forward mappings,
because of who owns the delegation, but you can't trust
reverse mappings, mostly for the same reasons.

To establish a trusted peer identity, a "getpeername()" is
issued.  We know that they aren't lying about their IP
address becuse everyone disables source routing, and
because they want packets back from us.

We then do a "gethostbyaddr()" to get the canonical name,
and then we look it up to see if it had the same IP address,
because we trust the domain to serve us the IP address we
are expecting.  If we don't get this, then someone who
owns the IP address, but not the domain, is spoofing us
with an invalid name in their reverse map.

I don't know how "poor" this really is; we are only
interested in establishing that the forward and reverse
mappings are transitive, so we know that whoever has
the legally delegated ownership of the domain is who we
are talking to, so that we can hold the domain owner
accountable for the actions of an IP address.

We may, additionally, use this to ensure that the domain
claimed in data over the protocol transaction matches the
domain of the owner of the IP address.  This means that
we hold the machine with that IP address accountable for
providing valid data.

This is a widely deployed SPAM countermeasure, based on
the theory that:

o	Domains are expensive
o	IP address blocks are expensive
o	"Burning" either of these in order to SPAM should
	be a more expensive proposition than the value of
	SPAM'ming in the first place.

This is also widely deployed for accounting records (logging,
billing, etc.).

> It seems clear to me that autoconfiguration is the
> favored approach for small or temporary networks. The
> choice for large networks, as for example - EDS Intranet,
> may well be different. This implies that DNS updates from

I think you need to make a distinction between:

o	Machines you trust, because they are installed
	behind your firewall

o	Machines you trust because they are your customers

o	Machines you trust because the trust is temporary

o	Machine you don't trust, but which someone else
	might, based on their forward and reverse mappings
	being transitive

I think the question comes down to a succinct "who owns
the address assigned during autoconfiguration?".

I think the answer is "partly the assignor, and partly
the assignee".  Then the question becomes "if I trust
them enough to give them an address, why don't I trust
them enough to accept a reverse mapping update from that
address telling me who they think they are?".

You could even be more explicit, and ask the question
like this: "for a laptop in an airport access point, a
telecommuting center, or a "wired" boardroom in which
business between two companies is being conducted, how
can I establish reverse mappings so that the laptop is not
crippled in capability vis a vis a permanently installed
workstation?".

You might also ask "how can I do this such that I don't
have to start trusting certificates and scanning laptop
IR ports/WaveLAN cards as they enter my premesis?".

I think this argument boils down to "why be protective
of the reverse mappings at all, if they aren't useful for
something about which we need to be protective?".

One might take the view that, in the future, there will
be no explicit Intranets, and what we now think of as
an Intranet will be replaced by a virtual Intranet which
consists of a VPN and some way to authenticate it to "get
inside".

In such a world, do we need to establish individual
identity (setting aside the desirability of getting
billed per-packet, which varies depending on whether or
not you are a telco, and the personal privacy issues),
or merely establish proxy identity, ala "they're inside,
they must be trustworthy people".

"Inside", in this case, being "the reverse mapping
matches the forward mapping", until we can get around
to implementing the world, above.

-- 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.

---

From: Jim Bound <[email-masked]>
Date: Tue, 03 Aug 1999 21:55:41 -0400

Jim,

Question for IPv6 stateless addrconf.

Right now when you install and configure IPv6 from our implementation it
asks you if you want dyn dns upds to be performed for you.

It seems from your mail we should ask the question do you want forward
mappings and reverse mappings for ip6.int within the zone of the domain
of that network?  So we need add more granularity to that set up
interface?

thanks
/jim