>3) This protocol is a bit loaded with options and features. It
>supports a number of different queries, leaves a fair amount of
>flexibility in how such information is obtained (e.g., proxies are
>supported) and is rather easily extensible, including in proprietary
>ways. The IANA Considerations Section indicates that anyone can obtain
>code points to extend the protocol as they please without the need for
>even a basic sanity review. As one reviewer noted:

        I can't agree more.  The initial proposal was simple and robust
        (which was just a name lookup).  I personally think Qtypes other than
        "Node name" are unnecessary.

>More detailed comments from various reviewers:
>
>Many application implementations do a reverse DNS lookup on an IP
>address to learn the DNS Name of the connecting system. This name is
>then used to make access control decisions. Some may believe that this
>mechanism can be used to replace the reverse lookup. However this
>introduces a new security vulnerability, which is to say that a bogus
>host could connect to a service and when queried with this protocol it
>would provide the DNS Name that the server is expecting and therefore
>make an inappropriate access control decisions.

        This part, I have a major objection.

        This view is completely opposite from concerns raised in
        draft-ietf-dnsop-inaddr-required-03.txt - DNS PTR records should
        not be used as sort-of authenticity, therefore, it is not recommended
        to be used as an access control mechanism.

        In my understanding, the threat imposed by malicious responses to
        ICMPv6 node information query (Qtype = node name) is equal to
        setting up DNS PTR records without forward zone administrators'
        knowing.  For instance, anyone can set up DNS PTR records that returns
        "www.ietf.org".  Similarly, anyone can respond with ICMPv6 node
        information reply with "www.ietf.org".

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to