>>>>> On Fri, 19 Jan 2007 01:10:46 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> 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.
> 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.
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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
