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

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

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 <dnsop-request@cafax.se>.