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

Hello, again,

Thanks for the detailed response.  I now understand what I was
concerned about more clearly, and hopefully I can be clearer on that
point this time.

At Sun, 30 Mar 2008 11:42:34 -0400,
Andrew Sullivan <ajs@commandprompt.com> wrote:

> > 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)
> 
> In the current version, we have attempted to address this question in
> two ways.

I think I basically understand the intent, but the subtle wording of
this document makes me unsure about it without knowing the background
discussions like this one.

The current document reads (to me):

1. list "cases where people say they are using, the reverse tree, and
   it's useful to them", with notes that it's unknown to add any
   security, unreliable, and neither necessary nor sufficient for
   abuse (sapm) detection.
2. and recommend IP addresses should have reverse mapping unless
   strong counter-considerations exist (and an example of such
   considerations is something that doesn't apply for many ordinary
   end operators).
3. on the other hand, encourage the reverse mapping users to think
   carefully before adopting such tests (= the "cases" given in bullet
   #1 above).

This is not convincing to me in the following two points:

A. it's unfair.  If this is based on the spirit of "reciprocity"
   (referring to Bill), which I'd respect, IMO it should be a fair
   deal.  It's not very fair to me to request someone to do something
   while just encouraging others to think about it (even if
   carefully).  And, as I mentioned in the previous message, I'm
   not just ethically complaining about it; I'm afraid the unbalanced
   fairness will worsen poor interoperability.

   To make it fair, I can think of two approaches:
   X. weaken the requirement for the provider of the mapping.  This is
      what I proposed in my first message in this thread.
   Y. tighten the note to the naive users, e.g., "should not use any
      test of reverse delegation, particularly when that test is
      intended to improve security, unless there is a strong
      counter-considerations such as a statistical proof that it
      improves the security without false positives".

   I can live with either way, but proposed X first considering
   peoples' views so vary that we cannot easily agree on tightening
   the recommendations.  But, if proposal X is not acceptable due to
   the opinion that weakening it makes the document effectively die,
   is there any reason we cannot adopt approach Y?

B. if the unfairness is on purpose, it's then not very convincing in
   that the only reason is that some people say it's useful and they
   want to use it, despite the list of why it's not a very good idea.
   If the only justification is that "some people want to use it that
   way", I'd rather request we respect the fairness.

Whether others agree on my view or not, I hope I'm clear about my
concern this time.  I'm going to make the following response based on
this meta-level point.

> First, we do list a number of cases where people say they are using
> the reverse tree, and it's useful to them.  As Brian Dickson says
> elswhere in this thread, the simple fact is that there is no way to
> tell whether there is existing or matching reverse without querying
> for it.  To the extent that the reverse tree can be valuable, it
> requires that people populate it and keep it up to date.

That's basically fine.

> Second, the current version includes the following text in Section
> 4.2; it  is intended to address your objection, at least in part.
> 
>                     It is nevertheless worth considering that not all
>    benefit from an administration practice accrues to the administrator
>    of a network.  The consumers of reverse mapping data are often not
>    the operators of the network that provides the reverse mappings.
>    Users of reverse mapping data report that it is valuable to them.
> 
> (note that there's a typo in the published version: "accrue" rather
> than "accrues".  I just fixed it in my local copy, now.)
> 
> The idea here is to remind people that the reason you _should_ do this
> is because other people say they find the reverse map useful.  It is
> true that there is an asymmetry of cost and benefit here; that's the
> reason that we need the draft at all, I think.

As indicated by the word "asymmetry", this sounds unfair to me, and I
don't see why we cannot be fair.

> > 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
> 
> I tried to argue in
> <http://www.ietf.org/mail-archive/web/dnsop/current/msg05563.html>
> that the counter-consideration is ultimately one that operators are
> going to have to evaluate themselves.  The same section 4.2 says
> explicitly that the principle is not intended to impose an undue
> burden on network operators.  

Again, my point is that the balance is not very fair.  If we can agree
on being fair, I'm happy to propose specific text.

> I agree, however, that
> 
> > just one of very few lazy operators; rather, I think a non negligible
> > number of ordinary operators will take a similar action.  
> 
> many people may decide (unfortunately, in my opinion) that maintaining
> the reverse will be too burdensome.  There's nothing anybody can do
> about that, but I still think we should say that it would be better
> overall if they would maintain the reverse mapping.

That's fine, and we can do this without being unfair (and that's what
I'm proposing).

> > 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
> 
> I think the document does condemn relying on the reverse mapping,
> particularly in section 4.3.
> 
> > 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.
> 
> I think the context of the "think carefully" remark also suggests that
> operators who don't want to maintain the reverse map need to think
> carefully:
> 
>    At the same time, site 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.

This specific point is basically okay for me.  My concern is the
overall unfairness.

> > 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".
> 
> Please note that this is not an RFC2119 "SHOULD".  The document as it
> is now does not refer to RFC2119 at all, because this document does
> not create new requirements of any sort.  My understanding is that the
> way one communicates as much in an Internet Draft is by not citing
> RFC2119, but I'd be happy to be corrected.

I understand this, and I admit this "should" is much weaker than
RFC2119 SHOULD.  But it still sounds unfair to me in the overall
context of this document.  As long as we can be fair, I don't much
care about the subtle nuance.

> > 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.
> 
> I attempted to reply to that request in
> <http://www.ietf.org/mail-archive/web/dnsop/current/msg05563.html>.
> The reason I have trouble with this is twfold.

I admit the cost is not very high.  My essential point (I agree I was
not very clear in my first message) is the fact that only the provider
side is required to pay the cost, even if it's small.  As long as we
behave in a fair manner, I agree this would be marginal and can live
with that.

> > One more possibly related thing: what does this document recommend
> > about "matching reverse data"?  
> 
> The idea is that, if you maintain the reverse mapping, the mappings
> will automatically match.  This is implicit in 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.
> 
> But notice the caveat.  That caveat is made more explicit in section
> 4.4:
> 
>    Administrators are advised to keep in mind the effects of adding a
>    very large number of PTR records for a given reverse mapping.
> 
> So, there should usually be matching reverse data.  But the draft
> attempts to note that there will be at least some occasions in which
> it is impractical to maintain the data this way.

Hmm, this seems to be a different issue from my main point.  I'll
respond to this point in a separate message.

> > 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.  
> 
> If I understand this correctly, you mean, "Difficult to assess the
> validity of the thing the people say," and not, "Difficult to assess
> whether people actually have said that," (since people have made the
> claim during the discussion about this document).  I don't know how to
> assess the validity of someone's claim that a strategy is useful _to
> them_.  Would this be better if we altered it to "Some operators
> report that scoring mail on the basis. . ."?

It's the former, and my point is that this is too weak as a base of
requiring the provision of reverse mappings.  For example, what if the
operator simply ignores many, many false positives and reports they
are happy with this because it eliminates spams (and even without
checking whether they can eliminate the same number of spams without
it)?  I'm not happy with being required to perform specific
operational actions (i.e., providing reverse mappings) just to make
such a naive operator happy.

Anyway, I think I can basically live with the current text (while I
personally would like to propose some clarification if accepted), if
we can act in a fair manner.

> > 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.
> 
> When I attempted to collect such references, all the spam-fighting
> people told me that every reference I made would be obsolete within
> months.  I'm happy to attempt this again, though, if others in the
> working group also think it is a worthwhile thing to do.  Anyone?

To me, this rather proves that this is weak as a base of requiring
some specific action.  But I understand your point.  I'm not
necessarily requesting such references.

> > 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.
> 
> The draft already says, more than once, that you shouldn't rely too
> heavily on the reverse mapping, particularly by itself.  I don't
> especially see the value of adding specific examples of how not to
> rely on the reverse mapping alone for every case, but I'm of course
> willing to reconsider that position depending upon expressions of WG
> support to say something different.

This is a pretty minor point for me.  I'm fine without adding such a
reference if the overall tone of the document can be fair.

> >    ... 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. ...
> 
> I'm not opposed to adding this text (thank you for it), if there are
> other expressions of support.  I do note that there is already text in
> section 3.4 that makes a similar point:
> 
>    The much larger address space of IPv6 makes administration of reverse
>    mapping somewhat daunting, in the absence of good tools to help
>    administrators.  Some discussion of this issue can be found in
>    [RFC4472], particularly section 7.
> 
> I also suggested previously that I'd be willing to put in a reference
> to draft-ietf-v6ops-scanning-implications; at the time I was somewhat
> uneasy with it, because I thought we were fairly close to WGLC.
> That didn't happen as quickly as I expected, in fact, and I note that
> draft-ietf-v6ops-scanning-implications is in the RFC Editor's queue.
> So there won't be any problems with the reference anyway.  Would such
> a reference help?

Perhaps.  My main concern of the original text is that it sounded as
if this workaround is too easy to implement without considering the
actual cost and it (implicitly) bases the argument of the requirement.
Again, this will probably become a minor point if the overall document
can be more fair.

> > 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?
> 
> I know we've never clarified this; I'm not sure how to do it and still
> make readable text.

This seems to be a separate issue.  I'll make a separate response for
this point.

> >    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.
> 
> > > 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.  
> 
> I think this is a reasonable objection, but I also suspect that "the
> day reverse mapping is universal" will never come.  Nevertheless, let
> me see if we can do better.

This is one typical instance directly related to my main concern, and:

> What about this:
> 
>    Some users continue to report difficulty in ensuring complete
>    population of the reverse tree by upstream providers.  This situation
>    could be corrected by the provision by those providers of reverse
>    mapping; but even if that happened, because there is no way to be
>    sure the reverse map is always complete, connection rejection on
>    the basis of missing reverse mapping should be regarded as a last
>    resort.
> 
> This text stays with the current point (that you shouldn't reject
> connections because of missing reverse, because you can't be sure that
> you're reacting to the right information) without drawing into this
> paragraph other issues of the utility of the reverse mapping.  Does it
> address your objection?

Yes, I think so, thanks.

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