Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse Mapping"

At Fri, 14 Mar 2008 04:45:00 +0100,
Peter Koch <pk@DENIC.DE> wrote:

> in accordance with the roadmap posted the other day, this is to initiate
> a working group last call on
> 
> 	"Considerations for the use of DNS Reverse Mapping"
> 	draft-ietf-dnsop-reverse-mapping-considerations-06.txt
> 
> ending Friday, 2008-04-04, 18:00 UTC.
> 
> The document is aimed at a status of "BCP".
> Please review the draft and send comments and/or statements of support or
> non-support to the WG mailing list.  We have taken names of volunteers,
> but everyone is encouraged to review.  There will be a five reviewer threshold
> and _no_ default action.

I've read this version of the draft, and I regret to say I cannot
(yet) support it.  I've always been a supporter of this work, and
been respecting the authors' effort in taking into account
controversial opinions, but I still must oppose to moving forward with
this version.

As a meta (and most substantial) level, this version still doesn't
answer the fundamental question I asked a year ago: "why *should* one
provide reverse mappings for all IP addresses they manage? (despite
the cost of the provision)?".
(see http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html)

I admit I'm partially responsible for the lack of the answer as I
was not very active in the follow-up discussion at that time (I hope I
can be more active and responsive this time).  But I'm very much
concerned about the current tone of the draft, so I cannot help
repeating it.

Since this document does not provide a convincing answer (at least to
me) for the question of "why I should", I, as an operator, will still
only provide reverse mappings as a best effort basis (i.e., I may not
provide them even if there is no "*strong* counter-considerations").
For example I won't provide reverse mappings if I simply cannot (or
don't want to) afford the operational cost.  And I'm afraid I'm not
just one of very few lazy operators; rather, I think a non negligible
number of ordinary operators will take a similar action.  On the other
hand, since this document only requires "thinking carefully" about
adopting (dubious) access control based on reverse mappings, operators
who are currently deploying it will simply continue the operation,
probably with quickly "thinking about it" as an excuse.  I'm also
afraid the unbalanced level of recommendations (i.e., "should provide
reverse mappings" vs "are encouraged to think about it before using
it") will give an excuse for such operators (revmap users) to continue
it.  The end result will be a (continued) poor interoperability, and
the "excuse" may even make it worse.

My interpretation from the discussions so far is that the issues are
too subtle or controversial to provide a convincing reason for
declaring a specific requirement with such a strong word as "should".
Maybe future changes in operation like wider deployment of IPv6 and/or
DNSSEC, or changes in the relationship between the existence of reverse
mappings and SPAM, may change the practice more clearly and we can
revisit it.  But, in my understanding, the "best current practice" we
can agree today is to simply state issues without a strong
recommendation.

I proposed one specific change to Section 4.4 a year ago along with
this point:

From

   Unless there are strong counter-considerations, such as a high
   probability of forcing large numbers of queries to use TCP, all IP
   addresses in use within a range should have a reverse mapping.

To

   A network administrator is encouraged to provide a reverse mapping
   for IP addresses in use within a range of the network if
   administration cost is acceptable according to the local policy.
   In some cases the administrator may rather want to avoid providing
   reverse mapping; for example, when there is a high probability of
   forcing large numbers of queries to use TCP.

I believe this is more fair compared to the counterpart for the users
(i.e., "encourage to think about it carefully") and is more realistic
with the understanding (of mine) that a strong requirement with no
convincing reason will be ignored anyway.  Is there any reason we
cannot adopt this text?  If this is something we can "live with", I
sincerely request adopting it.

One more possibly related thing: what does this document recommend
about "matching reverse data"?  While I still haven't understood why
we are required to provide reverse mappings, if it's something related
to 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."
(from Section 4.4), then the recommendation without also requiring the
provision of matching reverse data would be incomplete.

The following are specific comments on the text more or less along
with this major point.  I also have a trivial/less controversial
comments; I'll send them in a separate message so that they won't be
buried in the controversy.

Section 3.2

   Reports from operators suggest that scoring mail on the basis of
   missing or non-matching reverse mapping remains an imperfect but
   useful measure of the likelihood that a given message is spam,
   particularly in combination with other measures.  It is clear that
   the presence of reverse mapping, and a match between the forward and
   reverse zones, is neither a necessary nor sufficient condition for a
   candidate message to be spam.

I'm not very much comfortable with a statement based on "some people
say something" because it's difficult to assess its validity.  In
fact, I cannot really be sure that reverse mapping-based approach is
that effective, considering the fact that most of today's spams are
sent from botnets and the reverse mappings are often provided (when
provided) by the ISP, rather than the end users who host the bots.
I'd rather like to see a solid reference that describes how exactly
effective of this type of scoring is, both in terms of the ability of
identifying spams and of the ability of avoiding false positives.

I'd also like to add a reference to research work in this area that
doesn't rely on reverse mapping, such as a SIGCOM '07 paper:
http://www.sigcomm.org/ccr/drupal/?q=node/267
This is not related to DNS or reverse mapping specifically per se, but
I think it's useful to show people who naively believe the power of
reverse mappings that there are alternatives, which might be more
trustworthy, for their purposes.

Section 3.4

   The larger address space of IPv6 also makes possible "hiding" active
   hosts within a large address block: the impracticability of scanning
   an entire IPv6 network for running network services means that an
   administrator could effectively conceal running services in an IPv6
   network in a way not possible in an IPv4 network.  Such hiding would
   be prevented by a reverse mapping that revealed only existing hosts.
   If such "hiding" is desirable, it is possible nevertheless to provide
   reverse mapping for (a large segment of) the network in question, and
   then use only a small number of the so-mapped hosts.  This approach
   is consistent with the suggestion outlined in section 4.2, below.

I pointed out the suggested alternative might be too optimistic in
terms of reality in my previous comment:
http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html
this version still doesn't address the concern.  I'd like to propose
the following change, which I believe is more realistic.

   ... If such "hiding" is desirable, one possible alternative is to
   provide reverse mapping for (a large segment of) the network in
   question, and then use only a small number of the so-mapped hosts.
   It should still be noted, however, that this approach may not
   easily be realized with deployed implementations, and that
   automatically generated host names that are often used in this
   approach may make them useless. ...

Section 4.2

   In general, the DNS response to a reverse map query for an address
   ought to reflect what is supposed to be seen at the address by the
   machine initiating the query.

Maybe I'm too dull, but I've never succeeded to understand the meaning
of this sentence (I asked the same question on a previous version of
the draft, but this point has never been clarified).  In particular, I
don't understand what this means: "what is supposed to be seen at the
address by the machine initiating the query".  Can't this be more
clarified?

Also Section 4.2

   Unless there are strong counter-considerations, such as a high
   probability of forcing large numbers of queries to use TCP, IP
   addresses in use within a range and referenced in a forward mapping
   should have a reverse mapping.

I failed to understand this sentence.  Does this mean

   IP addresses that are
      - in use within a range, and
      - referenced in a forward mapping
   should have a reverse mapping.

or

   - IP addresses that are in use within a range, and
   - IP addresses that are referenced in a forward mapping
   should have a reverse mapping.

or something else?  In either case, does this mean we don't have to
provide reverse mappings for addresses that are NOT referenced in a
forward mapping?

I also asked the precise definition of 'in use' (especially in the
context of IPv6 stateless address configuration) in my previous
comment, but it's still unclear in this version.

Section 4.4

   Some users continue to report difficulty in ensuring complete
   population of the reverse tree by upstream providers.  This situation
   can be corrected by the provision by those providers of reverse
   mapping; but until the day reverse mapping is universal, complete
   connection rejection on the basis of missing reverse mapping should
   be regarded as a last resort.

(Again, I commented on this before) I don't follow the logic here.
Repeating my previous comment:

> I don't understand the logic of this sentence.  This sounds as if
> complete connection rejection on the basis of missing reverse mapping
> will be encouraged (or at least not discouraged) when reverse mapping
> is universal.  But in my understanding the essential problem of this
> approach is "the use of the reverse tree provides no real security,
> (and) can lead to erroneous results".  This should still apply even if
> "reverse mapping is universal".  So I'd rewrite it to, e.g.:

>   Some users continue to report difficulty in ensuring complete
>   population of the reverse tree by upstream providers.  This
>   situation can be improved by the provision by those providers of
>   reverse mapping; but even if reverse mapping is more widely
>   provided, complete connection rejection on the basis of missing
>   reverse mapping should be generally discouraged, since the
>   existence of a reverse mapping does not necessarily mean the owner
>   of the address is legitimate.

Perhaps my suggested text is too biased toward discouraging the
dubious use of reverse mappings, but at least I want to see something
that is logically more understandable.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop