At Fri, 14 Mar 2008 04:45:00 +0100, Peter Koch <[EMAIL PROTECTED]> 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