Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-03.txt

[Andrew Sullivan <[e-mail]>]

On Tue, Jun 12, 2007 at 07:10:27PM +0900, JINMEI Tatuya / 神明達哉 wrote:>

> Thanks for the update.  I've read the 03 version, and found that most
> of my previous comments
> http://www1.ietf.org/mail-archive/web/dnsop/current/msg05418.html
> were not actually addressed (or perhaps ignored or rejected?).  

Thanks for your review.  We considered each of your comments
carefully, and made changes to the text to address them where it
seemed correct to do so.  (At the bottom of this message, I'm
including a detailed outline of whether and how the document changed
in response to each of your comments.  Your comments have been
extremely valuable, and I'm distressed to learn that you think we are
silently ignoring them.  I apologise in advance that the responses
make this message a little long.)

> In
> particular, I now more strongly wonder why this document still keeps
> the strong recommendation:
> 
>    all IP addresses in use within a range should have a reverse mapping.

Note that, because someone has pointed out (and I missed) the
ambiguity in "in use", this sentence has to change anyway.  But I
observe three things here.  First, the sentence says "should" not
"SHOULD", so I'd argue that this is not as strong a requirement as you
seem to think.  Second, the sentence begins with, "Unless there are
strong counter-considerations. . . ," which rather softens the meaning
some more.  It strikes me that one could easily argue that "expense"
is a strong counter-consideration, in the event the expense is high
enough.  Finally, the paragraph also includes some entirely new text
at the end which was intended precisely to address your previous
comments:

        This principle is also not intended to impose undue burden on
        network operators.  It is nevertheless worth considering that
        not all benefit from an administration practice accrue 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.

In your comments before, you noted that we need a convincing reason why
a practice should be followed if it imposes any cost.  In the text
above, there is given a reason; if it is not convincing to you, and
you think the cost is too high, then it seems to me that you might
have a counter-consideration to implementing reverse mappings (that
would be the "undue burden"). 

> convincing reason for the strong suggestion in this version.  Is there
> any specific reason that we cannot make the statement more moderate
> like this?
> 
>    it is encouraged for a network administrator to provide a reverse
>    mapping for IP addresses in use within a range when the management
>    cost is acceptable for the administrator.

The problem I have with that formulation is that management cost is
not the _only_ counter-consideration that ought to be in place.  The
document already lists another example -- where the cost is imposed on
the operation of the DNS as opposed to the pocketbook of the
operator.  Moreover, there is little to distinguish, "Do this if the
cost is acceptable to you," and, "Do this or not; it's up to you."  If
the document is really going to say that it makes no difference
whether you maintain reverse mappings, then I don't think we should
bother saying anything: we'll get the situation we have today anyway.  

In addition, after the -03 draft was posted, I received a comment from
another list pointing out that there is already an RFC that says you
should implement reverse mapping: RFC 1912.  In section 2.1, it says

    Make sure your PTR and A records match.  For every IP address,
    there should be a matching PTR record in the in-addr.arpa domain.
    If a host is multi-homed, (more than one IP address) make sure
    that all IP addresses have a corresponding PTR record (not just
    the first one).  Failure to have matching PTR and A records can
    cause loss of Internet services similar to not being registered in
    the DNS at all.  Also, PTR records must point back to a valid A
    record, not a alias defined by a CNAME.  It is highly recommended
    that you use some software which automates this checking, or
    generate your DNS data from a database which automatically creates
    consistent data.

I would argue, therefore, that the current draft is something of a
softening of the position taken in RFC 1912.  (It's also pretty clear
that the draft needs to be updated to take the above passage into
account.  Thanks to Bruce Gingery on spam-l for this.)

I hope the above addresses your concerns in this area.  

Below is my outline of how the draft changed between -02 and -03 to
try to address your other helpful comments.  

The bulk of your comments were in
http://www1.ietf.org/mail-archive/web/dnsop/current/msg05411.html, I
believe.  

> - Section 1.1
>   If the intent of this document is to recommend one *should* provide
>   reverse mappings, this section clearly says so instead of the vague
>   wording like "provide some guidelines".

In -03, this section was updated to include, "suggests that site
administrators implement reverse mappings in the absence of strong
counter-considerations. . .".  The use of the word "suggests" is
intentional, again to avoid any confusion with standards-words and to
ensure that the document is clearly not imposing a requirement on
operators.

> - Section 1.2
>   I guess the IESG will suggest not using "NXDOMAIN" since it's an
>   implementation specific term (actually I was told that when I
>   edited RFC4074).

Section 1.2 (and other mentions) changed from NXDOMAIN to Name Error.

> - Section 1.3
[. . .]
> What are "useful" reverse mappings?  I'd rather remove this word, then
> it will be a mere fact and clear to read.  

The word "useful" is unpacked to use the terminology already defined
in the document.

Also,

> I don't think it's very clear that [RFC4255] could benefit from
> matching reverse mapping.  In fact, it does not mention DNS reverse
> mapping at all (while the other two do).  If we want to include
> [RFC4255], I suggest adding some text that explains how it could
> benefit from reverse mapping.

I asked about the relevance of reverse mappings to RFC 4255, and it
was approximately as I thought: reverse mappings can be useful as one
more check that you are getting the data you think you are,
particularly in the presence of the DNS Security extensions.  I wasn't
able to convince myself that explicating every example in the document
would be a good idea; the document is already kind of fat for what it
is, and I was afraid that adding an explanation of the way this might
work would just be distracting.  I did try two or three times to write
it up in a compact but suitably clear way, and failed.  If you really
object strongly to the mention of RFC 4255, I can take it out in the
-04 draft, because the other two examples probably suffice.

> - Section 3.1
[. . .]
> I think this note is too generic to make "informed decisions".  I
> suggest adding how these are ineffective or even harmful for each
> case. 

In order to make the text in each case more focussed on the topic, we
broke apart the discussion of what happens and the discussion of
whether the check in question is actually effective.  The
effectiveness discussion does not address each use of reverse
mappings, but treats them as classes of use and then discusses whether
that class of use actually achieves its goal.  We hope this makes the
point more clearly that reverse mapping _alone_ offers at best a very
weak piece of positive evidence for a conclusion.  (Note that the
negative evidence case might be different.)

> - Section 3.1
[. . .]
> As I pointed out in my comments on the previous version, this is
> unfair or misleading.  I'd rather make a new section "Examples of
> effects of relying on reverse mapping", and put this example there,
> without being specific to the "missing" case.

We simply removed this section.  It seemed to be attracting too much
dissent for its importance in the discussion.

> - Section 3.1

>    Traceroute output 
[. . .]
> I commented for the previous version that this did not seem accurate.
> There are "may"s added in this version, but I don't think they address
> the concern.

The section is altered to say this:

   Traceroute output with descriptive reverse mapping proves useful when
   debugging problems spanning large areas.  When this information is
   missing, the traceroutes can take longer, and those performing
   troubleshooting are left without useful hints.

The "additional steps" section is here more concrete, and notes the
exact benefit that accrues to the user of the reverse mapping.

> - Section 3.3
[. . .]
> I suggest adding some more text that explains why it's less pressing
> in practical.

We added "because the number of addresses affected is different" to
the sentence, to spell out what the practical difference is.

[. . .]
> than 20010db81111...abcd.example.com).  Overall, the effectiveness
> of this approach [for hiding] should be discussed more carefully,
> and in a more pragmatic way.

The text as it is accords with the recommendation in
draft-ietf-v6ops-scanning-implications-03, which discusses the
"hiding" approach more thoroughly.  Do you think we should add a
reference to that draft?  I have resisted that because this document
has dragged on a long time, and I'd like not to hold it up with a
possible downref, but if you really think the reference is needed we
can add it.  

> - Section 4.1

>    In general, the DNS response 
[. . .]
> This sentence sounds indirect and vague to me.  In particular, I'm not
> sure if I understand the phrase of "what is supposed to be seen at the
> address".

This was text lifted directly from the list (contributed by Ed Lewis,
if memory serves).  It just means that, from any place on the
Internet, there is a right answer to every query _for that querier_.
That isn't to say that there is always one universally right answer to
every query at a given time.  (Note that this moved to section 4.2 in
-03, because of the addition of another subsection.)

> - Section 4.1

>    It is desirable that Regional 
[. . .]
> I'd like to see why. (As part of my main concern)

For the reasons noted in my main argument above as to why we want to
encourage reverse mappings.  Note that this is merely "encourage", not
"require".

> - Section 4.1
[. . .]
> In addition, it's not clear to me what "all IP addresses in use"
> means.  For example, if I manage an IPv6 subnet
> "2001:db8:1111:2222::/64", are "the all addresses in use" the
> addresses from 2001:db8:1111:2222:0000:0000:0000:0000 to
> 2001:db8:1111:2222:ffff:ffff:ffff:ffff?  Or does that only mean IPv6
> addresses assigned to existing hosts in that subnet?  If the latter,
> does that include IPv6 addresses configured via stateless
> autoconfiguration and often missing from the network?  What about IPv6
> temporary addresses?

I realise in retrospect that I didn't understand this comment properly
when reading it, on the basis of another message that I overlooked (I
misfiled it) when working on the revisions.  See my other message on
this topic.  I will send a proposed change to the text to the list.  I
apologise to you and the rest of the working group for being obtuse
on this point.

> - Section 4.2
[. . .]
> I cannot be sure what "functions that depend on reverse mapping"
> specifically indicates.  An example might be helpful here.

We are getting concerned about the length of the document, so didn't
include another example.  I suppose an obvious feature would be the
display of hostnames discovered by way of the reverse map.  Do you
really think an example is needed?

> I think this is too weak.  Comparing to the strong "recommendation" in
> the previous section that does not explain why, this part provides the
> reason, so I think the recommendation can/should be tightened
> accordingly.  Referring to the text in the Security Considerations
> section, my suggestion is:

I don't understand how "no real security" is too weak.  The Security
Considerations section already says that people should use better
forms of authentication, and it seemed to me that your proposed text
was a security consideration about the use of reverse mapping itself,
and not about the document or its application.  (Maybe I'm just
misunderstanding).  The -03 draft is intended to make the
"effectiveness" section clearer and cast in a greater light.

> I'd also point out even the use of reverse mapping as a scoring system
> can be controversial.

I was unable to find a controversy around reverse mapping used in
scoring systems, or even _any_ criterion used in scoring systems.  The
idea of scoring systems seems to be that you set the bases on which
you wish to score, and then evaluate according to those criteria.  The
draft as it is has a fairly extensive discussion of the ways in which
too great weight placed on non-matching or missing reverse mappings
can cause "false positives".  Every anti-spam person I talk to tells
me that using reverse mapping in scoring is a very good, but not
perfect, measure of spamminess.  I have never met anyone actually
operating a mail server who has given me a different opinion, but I'd
be happy to hear from such people if they are out there.

> 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".

It doesn't actually say what you suggest it does -- "Not X until Y"
means that Y is a necessary condition for X, but doesn't say Y is a
sufficient condition.  In any case, the point of the section is to
discourage very strongly complete connection rejection on the basis of
missing reverse mapping, until every host on the Internet has a
reverse mapping.  Since "heat death of the Universe prior to universal
reverse mapping" is probably a safe bet, we thought this was enough.
I didn't like the alternate text you provided because it seemed to
lean on the argument that, since reverse mappings are not positive
proof, therefore they're not useful negative proof.  I don't think
that's true in every case, and therefore we can't use it as a premise.

Thank you again for your detailed reviews and helpful comments.  I
hope the above demonstrates the ways in which your review has
strengthened the document; and explains, where your specific
suggestions were not incorporated, why another path was taken.  

Best regards,
Andrew

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[e-mail]>                              M2P 2A8
jabber: [e-mail]                 [phone] x4110

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