Subject: [DNSOP] reverse-mapping-considerations: ambiguity?

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Jan 2007 17:13:56 -0500

Dear colleagues,

In 

http://www1.ietf.org/mail-archive/web/dnsop/current/msg00062.html

Dean Anderson argued that a proposed text change he offered be
included instead of some language that is already in
draft-ietf-dnsop-reverse-mapping-considerations-01.txt.  His argument
is that his proposed text "is clear and specific, and it resolves the
ambiguity in your descriptions."

I would like to defer to the group on this question.  I am not so far
convinced that Dean's formulation is clearer, more specific, or less
ambiguous than the language that is in the draft at present, but I
would like to hear an argument from anyone other than Dean who thinks
it is.  If no such argument is forthcoming, then I plan to leave
alone the language in the draft about the implications of relying on
the reverse tree for security.

For reference, in case people want to look at this some more, I
believe the entire thread on that topic starts here:

http://www1.ietf.org/mail-archive/web/dnsop/current/msg00042.html

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 19 Jan 2007 01:10:46 +0900

>>>>> On Tue, 16 Jan 2007 17:13:56 -0500, 
>>>>> Andrew Sullivan <[email-masked]> said:

> the reverse tree for security.

It's difficult to answer the question with yes-or-no since the
previous discussion seems to diverge, covering many subtle points, but
I'm afraid I share with some of the concerns raised in the
discussion.  I've carefully reread every line of the 01 version, and
found that my concerns are not really addressed (of course, I'm not
claiming it must necessarily be addressed).

Right now, I don't have time to provide further details in an e-mail
message, but I'll post my own comments to the 01 version by early next
week, which will probably be related to this issue.

The bottom line is, however, that I very much appreciate the effort in
this work, even though the resulting document after the discussion
might not be satisfactory for me (I won't be surprised at the result
since this document seems to contain many controversial points on a
subtle balance of opinions).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 19 Jan 2007 01:10:46 +0900

JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 24 Jan 2007 02:35:01 +0900

>>>>> On Fri, 19 Jan 2007 01:10:46 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> week, which will probably be related to this issue.

So, here are my own comments.  Sorry, this is pretty lengthy...I hope
I'm at least clear enough.

Overall, I cannot be sure what exactly are recommended and why they
are in Section 4.  In particular, I don't understand the logic towards
the following recommendation in Section 4.1 (3rd paragraph):

   All IP addresses in use within a block should have a reverse mapping.

Perhaps the rationale behind it is an observation that there may be
some useful cases where a reverse mapping helps or is necessary.  But
most of the concrete examples given in the draft do not lead to such a
strong recommendation:

- for "protocols that could benefit from accurate reverse mapping
  data" (quoted from Section 1.3), specifically
  [RFC4025]/[RFC4255]/[RFC4322], it should be sufficient to provide
  reverse mappings for those hosts that are involved in the protocols;
  we don't need a reverse mapping for other types of hosts, i.e., a
  host that is not an IPsec security gateway or an SSH server or an
  IKE responder.  Actually, it seems to me the situation is the same
  as that of forward mapping - we usually need a forward mapping for
  hosts that provide some well-known services and are expected to be
  connected from other nodes, and we don't need to provide a forward
  mapping for other hosts (we may provide it, of course).

- the situation is also the same for traceroute (section 3.1, last
  paragraph).  It might be useful to know the "host name" of
  intermediate routers (which often provides some intutive information
  - which may not be very trustworthy though - of the network
  topology), but I think we don't usually rely on the reverse mapping
  result for numerous end devices, especially those that do not
  provide any well-known services.

  BTW, while the draft states when a reverse mapping is missing "the
  traceroutes take longer", I don't think this is very accurate.  As
  long as the corresponding reverse mapping zone is properly
  maintained (*somewhere* under in-addr.arpa or ip6.arpa), traceroute
  should work fast enough without host name information.  Of course, a
  lame-delegation type of "missing" may make it take longer, but I
  don't think this sentence specially talks about that case.

  Or perhaps it refers to delays due to a slow link such as dialup in
  conjunction with lack of negative caching (Section 3.1, 3rd
  paragraph of page 4)?  If so, I don't think it's really a fair
  argument: first, such a delay or increased server load also happens
  for existing reverse mappings especially for some initial queries.
  Second, I believe negative caching is already pretty mature in
  caching server implementations (standardization-wise, RFC2308
  defined the usage almost 9 years ago, which is 4 years before
  RFC3363 finally recommended ip6.arpa + nibbles for IPv6 reverse
  mapping); if we discuss effects such as delay or load by assuming
  lack of such a matured feature, we could also argue that trying to
  resolve reverse mappings can cause a delay or increased server load
  in conjuction of lack of caching (either positive or negative),
  whether the mapping exists or not.

- I believe the same argument applies to the "delayed response" part
  of log analysis (section 3.1, second to last paragraph).  I'm not
  sure how substantial a missing reverse map is for statistics
  packages that try to resolve it, but I suspect they will simply work
  with textual addresses in such a case.

So, it seems to me that the only essential background that results in
the "strong recommendation" is "FTP (or telnet) sites simply rejecting
user sessions without a reverse mapping", "web sites verifying the
client's location using reverse mapping", or "TCP wrappers rejecting
clients that don't have reverse mapping", or "anti-spam systems
performing reverse-forward match tests to reject mail that does not
pass the test", etc.  That is, it seems the primary motivation of the
recommendation is, perhaps implicitly, to endorse such "security"
usage of reverse mappings.

If that were the real intent (I don't think so based on the discussion
in this thread so far), I'd be confused because in section 4.3 this
same document actually (at least to some extent) discourages such
usage: "The use of reverse mapping does not usually improve security,
and should not be a default policy."  I guess this confusion I'm
feeling is related to the issues raised in the "ambiguity" thread.

One expected explanation is that "some administrators don't accept the
recommendations (in this case "do not rely on reverse mappings for
security purposes that do not actually improve security") anyway, so
it's more realistic to consider how to deal with them (in this case
providing reverse mappings for all IP addresses "in use").
Admittedly, there are such administrators.  But if our action is to
let such admins do what doesn't really make sense and to recommend
others to adapt themselves for the convenience of the stubborn admins,
I don't see much importance in this effort; a stubborn admin will do
whatever they want anyway regardless of "technically sound"
recommendations from the IETF, whether it's not relying on reverse
mappings for non-secure purposes or it's providing reverse mappings
for all IP addresses.  I thought the IETF should primarily make
recommendations based on what is technically sound, and then (if still
necessary) consider compromises to deal with evil things.

Based on this opinion, my general proposal for section 4 is:

- recommend that RIR or LIR (or any organization that delegates IP
  address blocks) should provide appropriate reverse mapping
  delegations as well so that users who are delegated the address
  blocks can provide any reverse mappings that they want to publicize.

- not recommend "all IP addresses in use within a block have a reverse
  mapping."  In addition, we might clarify it's up to the site
  administrator which part of the their addresses should have reverse
  mappings.

- a bit more strongly discourage relying on the use of reverse
  mappings for "security" purposes that do not really improve
  security, clarifying those include reverse-forward matching or
  rejecting FTP/telnet/SMTP requests based on the (non)existence of
  reverse mapping or failure in reverse-forward match.

- and then (if still necessary) note that some administrators will
  still ignore the recommendations and continue relying on reverse
  mappings for the "security" purposes, and that other site
  administrators may want to provide more reverse mappings as an
  intermediate solution to deal with such "security-conscious" admins.

I also have related comments on other sections, but I'm stopping here
at the moment since I guess it's already pretty controversial.  If we
cannot agree on these fundamental points, the other comments on other
sections will probably meaningless.

Thanks,

					JINMEI, Tatuya

p.s. it's undoubtedly too early, but I'm copying below what I'd
envision in section 4 based on my opinions described above, just to be
concrete along with the actual text.

4. Recommendations

4.1 Delegation considerations

   It is desirable that Regional Registries and any Local Registries to
   whom they delegate should ensure the delegation of corresponding
   reverse mappings to the delegated organizations.

   Network operators should define and implement policies and procedures
   which delegate reverse mappings to their clients who wish to run
   their own reverse tree DNS services.  By the same token, network
   operators should provide reverse mapping for those users who do not
   have the resources to do it themselves.

4.2 Application considerations

   Applications should not rely on reverse mapping for proper
   operation, although functions that depend on reverse mapping (such
   as [RFC4025]) will obviously not work in its absence.  When the use
   of reverse mapping is optional for an application, the default
   configuration should be to turn it off.

   Operators and users are reminded that the use of the reverse tree,
   sometimes in conjunction with a lookup of the name resulting from
   the PTR record, provides no real security, can lead to erroneous
   results and generally just increases load on DNS servers. Further,
   in cases where address block holders fail to properly configure
   reverse mapping, users of those blocks are penalized.

4.3  Usage and deployment considerations

   Site administrators are encouraged to think carefully before
   adopting any test of reverse delegation, and are generally
   discouraged to employ such a test, particularly when that test is
   intended to improve security.  The use of reverse mapping does not
   usually improve security, and should not be a default policy.
   Those improper applications of reverse mapping include rejecting
   connection attempts due to lack of reverse mapping or mismatch of
   reverse and forward mappings.

   This test not only fails to reject many attempts of invalid access,
   but also rejects legitimate request from innocent users.  For
   example, some users continue to report difficulty in ensuring
   correct management of the reverse tree by upstream providers, in
   which case the users cannot provide the required reverse mapping
   even if they want to do so.  Also, adding a very large number of
   PTR records for a given reverse mapping can make providing reverse
   mappings ineffective; in particular, sites where a very large
   number of "virtual" host names resolve to the same host may force
   DNS responses to use TCP.  Thus, complete connection rejection on
   the basis of missing reverse mapping should be regarded as a last
   resort.

   In general, site administrators have the right to decide whether or
   not they provide reverse mappings for addresses they are using, and
   in case they do, the right to decide for which part of the
   addresses they provide the mappings.  However, the administrators
   are cautioned that administrators at other sites sometimes use
   reverse mapping as one of several pieces of evidence in evaluating
   connection traffic, particularly in the context of mail systems and
   anti-spam efforts.  Even though such us of reverse mapping should
   usually be discouraged especially when it results in rejecting
   connection attempts, administrators who believe in this type of
   "security" will continue relying on it for the moment.  Thus, until
   the day the improper reliance of reverse mapping is fully
   obsoleted, an administrator who owns an IP address block may need
   to consider providing more reverse mappings than those that are
   really necessary.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 24 Jan 2007 02:35:01 +0900

Thanks,

					JINMEI, Tatuya

4. Recommendations