Subject: comments on dnsop-ipv6-dns-issues-00

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Nov 2002 23:41:13 +0200 (EET)

Hello,

As an overview, I'm very happy about the direction of this draft -- 
especially the recommended action in IPv4/IPv6 name space issues.

Comments.

      - every single DNS zone SHOULD be served by at least an IPv4
      reachable DNS server.

==> s/an/one/

8.  DNSsec

   There is nothing specific to IPv6 or IPv4 in DNSsec.

==> perhaps it would be appropriate that there are IPv6 specifications, 
and more possibly on the way, which break DNSsec.

9. Security considerations

   Using wildcard DNS records in the reverse path tree may have some
   implication when used in conjunction with DNSsec.

==> add something to the effect of "Security considerations for referenced 
documents are described in those memos and are not replicated here."

   [RFC2766] Network Address Translation - Protocol Translation (NAT-
   PT). G.  Tsirtsis, P. Srisuresh. February 2000.

   [NAT-PTissues] Issues with NAT-PT DNS ALG in RFC2766, A. Durand,
   draft-durand-natpt-dns-alg-issues-00.txt, work in progress.

   [NAT64] NAT64 - NAT46, A. Durand, draft-durand-ngtrans-
   nat64-nat46-00.txt, work in progress.

==> these, at least, weren't referenced in the main body (intended to be 
part of DNSsec?).

   [IPv6ADDRARCH] IP Version 6 Addressing Architecture, R. Hinden,
   draft-ipngwg-addr-arch-v3-09.txt, work in progress.

==> 11.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Nov 2002 21:31:27 +0200 (EET)

On Wed, 20 Nov 2002, Jun-ichiro itojun Hagino wrote:
> >4. Automatic population of the Reverse path DNS
> 
> 	we could use ICMPv6 node information query, or something alike,
> 	to directly query the reverse name to the node itself.
> 	(we cannot sign RR, obviously)
> 	draft-itojun-ipv6-nodeinfo-revlookup-00.txt

I believe this kind of off-link nodeinfo querying is in direct conflict 
with the way NI queries are supposed to be used (which is causing the IESG 
problems also).

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 20 Nov 2002 04:23:17 +0900

itojun

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Nov 2002 21:12:47 +0859 ()

Itojun;

> 	(we cannot sign RR, obviously)

Your assumption that source address of a incoming packet is reachable is
improper.

Never assume routing symmetric.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Fri, 22 Nov 2002 15:03:06 +1100

Date:        Thu, 21 Nov 2002 21:12:47 +0859 ()
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | Your assumption that source address of a incoming packet is reachable is
  | improper.

The source is more likely reachable than some DNS server at some unknown
location - at least we know the source address is actually alive and connected
at the time.

The two issues with using info queries for addr->name translation are
authentication, and lookups well after the event, both of which DNS servers
are likely to do better.

Personally, I have lost essentially all faith in the usefulness of addr->name
translations at all, and wouldn't mind simply saying "cannot be done" (in
general of course, it might sometimes work, just don't depend upon it).  But
if it must be done, the node info query way is good enough.

  | Never assume routing symmetric.

What does that have to do with anything?

kre

---

From: Brad Knowles <[email-masked]>
Date: Fri, 22 Nov 2002 09:56:45 +0100

>  location - at least we know the source address is actually alive 

	Do we have cryptographic evidence for this assumption?  Or are we 
just assuming that since we received a packet from a particular IP 
address that this claimed source must actually be alive?

	I'm not saying that this is not a valid assumption.  I'm saying 
that we should ask ourselves what happens when it is not valid.

>  general of course, it might sometimes work, just don't depend upon it).

	Yeah, name-based security is pretty meaningless.  Even if you 
resolve things backwards, then forwards then backwards again (or 
forwards, then backwards, then forwards again), and compare the final 
results with what you started off with, it's a guess at best.  Only 
with a full and unbroken cryptographic chain of evidence going up all 
the way to the roots, can you have some confidence that the reverse 
is actually what it claims to be.

	Still, I think we need to provide some sort of reverse mechanism.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Robert Elz <[email-masked]>
Date: Fri, 22 Nov 2002 20:40:05 +1100

Date:        Fri, 22 Nov 2002 09:56:45 +0100
    From:        Brad Knowles <[email-masked]>
    Message-ID:  <a05200f11ba03a0798758@[192.168.0.3]>

  | 	Do we have cryptographic evidence for this assumption?

Cryptographic evidence ?

But no, I haven't tried to measure it, but it is something that could be
measured.   I'm not sure it is important enough to bother with though.

  | Or are we just assuming that since we received a packet from a particular IP 
  | address that this claimed source must actually be alive?

No, of course not.   I'm assuming that most of the time it will be alive (for
genuine packets anyway, for spoofed packets, any kind of address->name lookup
is clearly a waste of time anyway).   But it isn't whether it is alive that
mattered, Otha-san's point was that it isn't necessarily possible to get
packets back to it, just because it can get packets to you - which is certainly
true.

My point was that that it is (I suspect) less likely to be able to get packets
to its in-addr.arpa DNS server, than the host itself.   If the host is sending
many packets then (spoofing and hacking aside) it is almost certainly getting
replies - or it would soon give up on sending.  Its in-addr.arpa server might
be anywhere (even if reachable, it may not be correctly configured).

  | 	Still, I think we need to provide some sort of reverse mechanism.

Why?

While I have no objections with allowing people to provide names for hosts on
their networks, one way or another, if they desire to, I can't think of any
particularly good reason why anyone would actually want to (the best one is
perhaps "because, it has always been done".  I certainly don't believe that
anyone should be expecting to be able to take someone else's address and
translate it into a name.

kre

---

From: Brad Knowles <[email-masked]>
Date: Fri, 22 Nov 2002 11:16:28 +0100

At 8:40 PM +1100 2002/11/22, Robert Elz wrote:

>  perhaps "because, it has always been done".

	Historically, the /etc/hosts (or HOSTS.TXT) table provided both 
forward and reverse mapping.  In my own experience, a one-way 
directory service has limited uses.

	When looking through logs, I want to see the name of the 
system(s) that are accessing my machines -- their IP address is only 
relevant if there is a problem with a particular system and I need to 
talk to someone about getting that machine fixed/stopped.

	However, when I give that IP address to a remote administrator 
and ask her/him to look into finding and fixing that machine, odds 
are s/he won't remember the IP address of all the machines under 
her/his control any more than I can remember which machines I have 
(which is why we have forward resolution, to map easily remembered 
names to less easily remembered numbers).  So, s/he is just as likely 
to do a reverse lookup locally as I would remotely.

	Generating all possible forward names that can exist, and then 
looking to see which ones map to which IP addresses, is not a 
particularly scalable method.  Nor is cd'ing to the directory that 
holds the contents of all the different zones and then grep'ing 
through all those files to see which lines reference a particular IP 
address.

	If we humans are going to refer to things by names, and the 
machines themselves refer to themselves by numbers, we not only need 
a method to turn names into numbers, we also need a method to turn 
numbers back into names.

	We don't need this sort of thing so much for phone numbers, since 
most humans actually use the numbers in question, and we have our own 
private directories of what names are associated with what numbers 
(effectively providing an equivalent of HOSTS.TXT), but people who 
deal with receiving a lot of telephone calls do need reverse 
directories.

	Consumers have access to CallerID, but 911 services (and other 
companies that operate large banks of phones) have access to a much 
more powerful (and unblockable) service called ANI.  And all the 
telephone companies provide reverse lookup directory services, either 
in print or interactive digital form.

>                                               I certainly don't believe that

	Certainly, the level of expectation there should be lower.  We 
should be trying to actively manage the level of expectation that 
people bring to this process.  But I am convinced that we need to 
provide some mechanism to handle reverse lookups in some fashion.

	Indeed, if we can bring cryptographic signatures to this process, 
and we can prove that the reverse signatures came from the same key 
(or chain of keys) as from the claimed forward name, then we can be a 
lot more certain that a particular reverse is authentic.  But I think 
cryptography is likely to be the only thing that can save us here.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Nov 2002 23:46:00 +0859 ()

kre;

> location

There are multiple DNS servers. Moreover, you must, anyway, rely on
DNS for forward lookup.

> - at least we know the source address is actually alive and connected
> at the time.

Source host is, source address of the host may not.

> if it must be done, the node info query way is good enough.

The primary benefit of having a reverse tree is that the tree makes
address assignement unique.

> What does that have to do with anything?

v6 people including itojun persistently assume it, for example, for
such topics as a source address selection.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Sat, 23 Nov 2002 13:15:21 +1100

Date:        Fri, 22 Nov 2002 23:46:00 +0859 ()
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | There are multiple DNS servers.

Yes, but most of the time (and especially for in-addr.arpa) they're all
clumped at the same location - if one is reachable, they all are.  The only
reason there's more than one is in case one has crashed.   And of course, not
only do the servers for the final in-addr.arpa zone itself need to be 
reachable, the whole tree down to it needs to be as well.

  | Moreover, you must, anyway, rely on DNS for forward lookup.

Yes, but that's not what is being done (and forward zones, down the tree,
tend to be better distributed).

  | Source host is, source address of the host may not.

Of course, but if the address is bogus/spoofed, then obtaining its name is
useless - all you're getting is the name of some host that isn't the one
that sent the packet.   Having that fail because the address given doesn't
work is harmless.

  | The primary benefit of having a reverse tree is that the tree makes
  | address assignement unique.

Yes, that one is an important advantage.   It would seem though that
there ought to be some rather simpler way of advertising assignments so
everyone can tell the address that they have been told is in fact assigned
to them, and to no-one else.   Managing the entire in-addr.arpa tree just
for that would be way overkill.

  | v6 people including itojun persistently assume it, for example, for
  | such topics as a source address selection.

Fine - when something is being discussed, where that assumption has been
incorrectly made, and it actually matters, then point it out - but there's no
need to add it to every discussion that relates to addresses.

kre

---

From: Brad Knowles <[email-masked]>
Date: Sat, 23 Nov 2002 04:55:49 +0100

At 1:15 PM +1100 2002/11/23, Robert Elz wrote:

>  to them, and to no-one else.

	Problem is, the people who manage the name-space may not be the 
same people who manage the IP-space.  I can manage many domains, run 
the nameservers myself, etc...

	But I have to get IP addresses from somewhere, and unless I'm a 
big company or other organization and can get IP addresses assigned 
to me directly by RIPE, ARIN, or other comparable organization, I 
have to get them from my IP provider.

	That IP provider may or may not choose to delegate to me the 
management of the portion of IP space that they have allocated for my 
use.  Moreover, that space might be dynamically allocated, and change 
each time I log on and back off again.

	This is why organizations like DynDNS.org have been created.

	Even crypto won't help you here, because it would the respective 
keys of the owners of that portion of space, and in one case it would 
be the key of the owner of the name-space and in the other it would 
be the key of the owner of the IP-space.

>                                 Managing the entire in-addr.arpa tree just

	It does seem excessive, yes.  However, I don't see a better 
solution.  If you can come up with a better solution, I'm sure we'd 
be willing to discuss the matter with you.

	However, this is a problem that people have been working on for 
quite some time, and so far as I know, no better solution has been 
proposed.  Therefore, until you can come up with something better, or 
at least some ideas of things to think about, I believe that we must 
assume that reverse DNS is here to stay.

	At the very least, I believe that we should make these separate 
discussions, and not let this issue cloud or slow down the discussion 
on things we're supposed to be here to talk about.