Let me clarify... [EMAIL PROTECTED] writes:
> >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. The above suggests that the IESG comment was implying that doing reverse lookups for some sort of security check is a good idea; actually, the IESG view is the opposite. It believes it is generally a bad idea. However, it is also the case that people seem to do this. Thus, the suggestion to put in explicit text saying this is an even worse idea than if one was just using the DNS record. But the issue is more nuanced I think. I *thought* that what implementations did was a) do a lookup of address -> name b) do a lookup of name -> address If the later returns the first address, that is somehow a good enough check. So, one can imagine doing ICMP name lookups for a), but still do b) via the DNS. The issue here would be different than just doing a) via lookups or doing both a) and b) via lookups. > 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". Yep. This would all be appropriate to better explain in the security considerations section. Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
