Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 7 Apr 2003 14:20:44 -0400

I know that this draft has been discussed a lot already
and that Dean has strongly held convictions, but I can't
just let some of Dean's statements go by without comment.

Daniel wrote:
> > It is the purpose of this draft to define the reasons to 
> > promote the use of INADDR, and to also discourage usage
> > that can be harmful and which provides false security [...] 

This is a reasonable and proper thing to do in this draft.
Yes, there was a period where some sites attempted
to do website access control by forward-->reverse-->forward
DNS lookups.  That didn't last long, but it's appropriate
to document the reasons why such things are Bad Ideas.
 
Dean replied:
> Then it should include a statement to the effect of:
> 
> ------------
> IN-ADDR should not be used for any logging, auditing, identification,
> authentication, or authorization purpose.  Its sole purpose is for
> the convenience of such applications as traceroute.

No, no, no, no, no.  Your statement above is not accurate.
I agree that is rarely useful to log IN-ADDR information by itself
without the IP address--in fact, it's a Bad Idea and the IETF almost
certainly should clearly recommend against logging of IN-ADDR without
the associated IP.  However, it *can* be useful to record both the
IP address and corresponding PTR lookup information, where
such information is available.  The PTR information can't always be
relied upon by itself, but since it can change over time it does
represent information that is either logged or lost.  Is it your
assertion that the PTR information, if logged along with the IP
address, can *never* be relied upon in any way by a competent
administrator or investigator?

More importantly:
It is *entirely* proper for a large ISP (or in fact any company)
to populate the reverse lookup tree with information such as

xx.129.203.24.in-addr.arpa  PTR  \
   modemcable0xx.129-203-24.que.mc.videotron.ca [0]

and it is *entirely* appropriate for me to be able to choose to
use that information as one factor in deciding how to handle
incoming connection attempts from that IP address.

It's appropriate today in both the "IPv4-only" world and in the
IPv4/IPv6 world.  Yes, it's difficult to ensure that that information
is 100% accurate, even if it's accurate it's not always useful, and
it will be more difficult to ensure it's accurate when the number
of supported IP addresses grows by $BIGNUM.  The fact that reverse
lookup information can be difficult to maintain and use effectively
does not mean that its continued use constitutes a hazard to users such
that it should never be used within applications.

It's entirely possible that someone out there will choose to run
their own mailserver at home, on an IP address with reverse info
such as that above (or no reverse lookup info, or...).  That's their
choice, and I have no problem with it--but someone in such a
situation should realize that there *is* a reasonable probability that
their outgoing connections may be denied at other sites.  This isn't a
problem specific to unsolicited e-mail, it's a general issue.
Connectivity to an ISP does not (and never will) constitute some
guarantee that everyone else out there is obliged to receive all the
packets that one might choose to send.

Given that DNS reverse lookup *does* provide a useful function, and
there is no other solution (including the ICMP techniques that Dean
apparently favors) that provides information which is equivalent and
can be used/controlled/managed/distributed in ways as effective as
DNS, I strongly object to Dean's continued attempts to use this
draft to de-specify DNS reverse lookup.  Does the draft need updates
and modifications?  Yes, from my reading--am I correct in thinking
that an updated version is already in work, and/or would now be an
appropriate time to Send Text?

[0] Yes, I pulled this IP out of a log of spam rejects.

--
Rip Loomis                         Senior Systems Security Engineer
SAIC Enterprise Security Solutions Group     www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 7 Apr 2003 16:24:29 -0400 (EDT)

> just let some of Dean's statements go by without comment.

My views are neither "convictions", nor "strongly held". They just happen
to be logically correct. The "strongly held convictions" are those that
refuse to accept logical arguments and the consequences of deduction.

> without the IP address--in fact, it's a Bad Idea and the IETF almost

Actually, it is still quite common to find logs without IP addresses.
There are still a number of unix implementations that have syslog's and
wtmp's that don't have anything but the in-addr response (and only 64
bytes of that).  For example, Linux stores the in-addr for IPv4, and the
IP address for IPv6.

However, I am not saying it is inappropriate to store in-addr as secondary
information. I am saying it is inappropriate to use in-addr as the primary
information.  Those are different things.

> relied upon by itself, but since it can change over time it does

You seem to miss the point: PTR information can _never_ be relied by
itself.  There is no case where it can be relied on. It is silly to keep
repeating this point.

> represent information that is either logged or lost.

> Is it your assertion that the PTR information, if logged along with the
> IP address, can *never* be relied upon in any way by a competent

Yes.  Only the IP address can be relied on.  If you have the IP address,
you don't need the IN-ADDR.  If you don't have the IP address, the IN-ADDR
can't be trusted. Without the IP address, you have nothing.

> incoming connection attempts from that IP address.

It is _entirely_ up to the ISP to decide whether or not to do that. If
they don't do that, then that case is _also_ entirely proper.

_YOU_ can do whatever you want to. Just don't expect the rest of use to
change our IN-ADDR zones to suit your misguided and illogical convictions.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Apr 2003 02:10:13 +0200

>  refuse to accept logical arguments and the consequences of deduction.

	Methinks thou doth protest too much.

	Despite all your claims to the contrary, claiming that "strongly 
held convictions" are actually fact is merely proof of the depth to 
which you hold these convictions -- in your world, it appears that 
they are actually fact.

	However, in the real world....

>  Actually, it is still quite common to find logs without IP addresses.

	Evidence, please.

>  bytes of that).

	Evidence, please.

>                   For example, Linux stores the in-addr for IPv4, and the
>  IP address for IPv6.

	There is no one single "Linux".  There are many different 
versions of the Linux kernel.  There are many Linux distributions 
that may or may not make use of a particular Linux kernel.  For any 
particular subsystem, there are probably at least two to six or more 
different major variants of that system, and a particular 
distribution may or may not choose to use a particular one.

>  information.  Those are different things.

	Insofar as this statement goes, I agree.  If only you would not 
use this as a jumping-off point for making every possible attempt to 
destroy all possible use of reverse DNS.

>  itself.  There is no case where it can be relied on. It is silly to keep

	Who said that we'd be doing this, or suggesting this?

	Everything I've read (so far) indicates that we're talking about 
making use of this information as an added data point, above and 
beyond the bare IP address.

>  you don't need the IN-ADDR.

	Wrong.  It can be a useful piece of information, information that 
may not be around in a few days or a few months, when you decide to 
try to look up that IP address.  It's important not to destroy or 
throw away information unnecessarily.

>  change our IN-ADDR zones to suit your misguided and illogical convictions.

	It is entirely within your right to choose to do whatever you 
want with your DNS zones.

	However, I must insist once again that you refrain from removing 
from others their own right to make the same choice.

-- 
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: [email-masked]
Date: Mon, 7 Apr 2003 19:03:35 -0700

> throw away information unnecessarily.

It should be pointed out that an IP address cannot always be "relied
on", either.  IP addresses and ptr records are just two different kinds
of information, with different characteristics.  The usefulness of 
either depends on the context.

As far as the draft is concerned, I believe that its conclusion should 
be: 

    Population of the inverse tree with useful information should be
    encouraged, but neither required nor relied upon. 

Other than that, I think the draft could be expanded to include more
examples of the disparate ways that the inverse tree is actually used 
in practice, both good and bad.

Kent

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Apr 2003 09:01:02 +0200

At 7:03 PM -0700 2003/04/07, [email-masked] wrote:

>  on", either.

	Indeed.  This is a point that I had made earlier, but which 
appears to have been conveniently ignored by the destructionists.

>                IP addresses and ptr records are just two different kinds

	Agreed.

>      encouraged, but neither required nor relied upon.

	I would modify that to state that software authors (and OS 
vendors) should not use it by default, or at least not by itself -- 
the IP address should also be provided.  However, the owner of the 
system should be free to configure the software to use this 
information, if they so choose.

>  in practice, both good and bad.

	Agreed.