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

[JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>]

>>>>> On Wed, 02 Apr 2003 17:32:12 -0500, 
>>>>> Rob Austein <sra+dnsop@hactrn.net> said:

> So far we've heard from:
> - Ray, who pointed out some RIR-related (specifically, ARIN-related)
>   text that needs some work;

> - Mxxs, who liked the draft and suggested adding text discussing IPv6;

('xx' seemed to be non-ascii characters)

> - Dean, who says that we should not be working on this draft.

> Does anybody -else- have comments on this draft?  In particular: does
> anybody who has not yet spoken on this have an opinion on whether the
> WG should be working on this?

Though I've mentioned this draft in a separate thread, I think I can
present my opinion since I'm not listed above.

I believe the wg should work on this, and I basically support the
intention of the draft.

The draft, however, will need several clarifications.

As already pointed out, the title (and the filename) does not reflect
the content well and will thus need to be revised.  Abstract and
introduction may also need a revise from this point of view.

Secondly, if I don't misunderstand the intention, the draft says two
things:

1. we need to try to build correct reverse mapping as much as
   possible.
2. applications should not rely on reverse mapping for several
   purposes as they currently do.  The discouraged purposes include:
   - rejecting ftp/telnet connections just due to the lack of reverse
     mapping or failure of reverse-forward-reverse match.
   - filtering rule in TCP wrappers due to the lack of reverse mapping
   - regarding e-mail messages as spam if the sender address does not
     have a reverse mapping

I don't much care about bullet 1, but I think bullet 2 needs some
clarification.

First, I'd like to confirm if my understanding above is correct.  The
draft basically just says:

   Applications SHOULD NOT rely on IN-ADDR for proper operation.

But it is not very clear what the "proper operation" means.  I picked
up the examples of the discouraged usage from Section 3 based on my
understanding of the draft.  If I read it correctly, however, then I'd
wonder why people who seemed to want rely on such a usage
(e.g. rejecting ftp connections) are supporting the draft.

Also, I'm not sure if all the examples in Section 3 are discouraged
based on the intention of the draft, which include:

  - (to try) logging the result of reverse lookup of a web client in a
    web server
  - reverse lookup in traceroute

Finally, Section 4 needs to be clearer.  The draft says

   The use
   of IN-ADDR, sometimes in conjunction with a lookup of the name
   resulting from the PTR record provides no real security, ...
                                          ^^^^^^^^^^^^^^^^

but, as already pointed out in this list, "security" is a broad term.
I believe the draft should be clear on what kind of "security" it is
talking about.

In summary, I'd like the draft

- to clarify the first paragraph of Section 4, and
- to add a concrete list of discouraged usage in Section 4

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.