Thomas Narten wrote: > ... > 2) The document doesn't specify security issues around RFC 3041 > temporary addresses and how they can be ameliorated. But queries for > names and addresses can be used to discover the relationship between > more permanent DNS names and IP addresses and the temporary addresses > (and names).
THere is no reason a node would respond to this query if its intent is to remain anonymous. On top of that there are no 'security issues' raised here, though there may be some authentication issues. > > Stating this threat in the security considerations is needed. What threat? Is the concern that some implementer would be stupid enough to reveal a private address? Stupidity can't be legislated against. > Presumably the threat can be avoided by requiring that nodes separate > the temporary addresses from other addresses and names e.g. by > - having queries sent to a temporary destination address or > for a temporary subject address not return non-temporary addresses > or domain names > - having queries for non-temporary addresses or for domain names not > return temporary addresses. > While there might be a policy knob to override this, the setting of > that knob must default to the above separation. Why should there be a policy knob for revealing a 3041 address to name mapping? That is absolutely absurd. Either the node is allowed to use the addresses 'privately' or the node is not allowed to use those addresses at all. The policy knob belongs on the decision to use the format, not on requiring disclosure if they are used. Personally I would leave the querier hung in a timeout, but the politically correct thing to do might be to pretend the node doesn't know its name and return a null list with ttl=0. > > 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: > > As an example, the original idea -- that you ask a host for its > own name -- is a good one, and for lots of reasons it may be far > better than using PTR records. But this draft has mutated to > take on aspects of the Kitchen Sink Protocol > > There does not appear to be a readily applicable security model for > how one can secure the protocol or the information it returns. This > would lead one to prefer a more narrowly scoped protocol that can't > easily be extended in inappropriate ways, especially for a Standards > Track protocol. It is strongly suggested that the document should > restrict extensions to the protocol to RFC-approved new queries and a > small space for private use. Again there is no 'security' in the information returned, but there may be some concern about authenticity. The potential security issue that has been missed in this set of responses is the ability to use this to seed a dos attack against the complete set of addresses without tripping an IDS frequency counter. It also doesn't make any sense to use a mechansim that is clearly getting packets to the dst node to ask it for other addresses that might be used to get packets to it. THe only possible use I can see would be to allow shifting to a different pair for route selection reasons, but that implies global usage which is itself a bad idea. The best way to restrict the applicability of this protocol is to limit it to link-scope or site-scope addresses. Since an answer from outside the local administrative scope can't be trusted anyway, there is no reason for the protocol to escape that scope. Once the connection exceeds the bounds of a site, either there is no trust, or there is some authentication infrastructure support. If there is authenticated infrastructure, it makes more sense to use DNSsec than create something new. Tony BTW: if the document maintains its Kitchen-Sink flavor, the IPv4 query type should be removed and IPv4 addresses should be returned in IPv4-mapped IPv6 format. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
