--- 1/draft-ietf-grow-embed-addr-04.txt 2006-02-04 23:24:04.000000000 +0100 +++ 2/draft-ietf-grow-embed-addr-05.txt 2006-02-04 23:24:04.000000000 +0100 @@ -1,17 +1,16 @@ - Global Routing Operations D. Plonka Internet-Draft University of Wisconsin -Expires: April 22, 2005 October 22, 2004 +Expires: May 24, 2005 November 23, 2004 Embedding Globally Routable Internet Addresses Considered Harmful - draft-ietf-grow-embed-addr-04 + draft-ietf-grow-embed-addr-05 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. @@ -24,100 +23,56 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 22, 2005. + This Internet-Draft will expire on May 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document means to clarify best current practices in the Internet community. Internet hosts should not contain globally routable Internet Protocol addresses embedded within firmware or elsewhere as part of their default configuration such that it influences run-time behavior. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1 Disable Unused Features . . . . . . . . . . . . . . . . . 6 - 3.2 Provide User Interface for IP Features . . . . . . . . . . 6 - 3.3 Use Domain Names as Service Identifiers . . . . . . . . . 6 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1 Disable Unused Features . . . . . . . . . . . . . . . . . 5 + 3.2 Provide User Interface for IP Features . . . . . . . . . . 5 + 3.3 Use Domain Names as Service Identifiers . . . . . . . . . 5 3.4 Use Special-Purpose, Reserved IP Addresses When - Available . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.5 Discover and Utilize Local Services . . . . . . . . . . . 7 - 3.6 Avoid Mentioning the IP Addresses of Services . . . . . . 8 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 - 8.2 Informative References . . . . . . . . . . . . . . . . . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 - A. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . . 11 - -Revision History - - RFC-EDITOR: PLEASE REMOVE REVISION HISTORY BEFORE PUBLICATION. The - following is the recent revision history of this document - - $Log: draft-ietf-grow-embed-addr.xml,v $ - Revision 1.19 2004/10/22 16:08:17 plonka - edits based on initial IESG evaluation for BCP: - - * fixed a typo reported by Spencer Dawkins - - * reworded the introduction as suggested by Ted Hardie to make it clear that - the document is about service identifiers used by the device, not the host - IP address it uses as a client of those services - - * improved recommendation to use DNS names based on comments by Harald - Alvestrand, Steve Bellovin, and Pekka Savola - - * under Security Considerations, strengthened the opposition to ad hoc remote - control mechanisms by mentioned that they should be able to be disabled, - based on comment by Russ Housley - - * used the term "mobility" rather than "portability" and "networks" - rather than "internets" based on comment by Thomas Narten. - - Revision 1.18 2004/10/21 20:24:35 plonka - changed from full RFC2026 to RFC3667 compliance - - used compact as suggested by Pekka Savola - - added table of contents and sortrefs - - added headings and subsections for specific recommendations - - added example of how domain names might be used, based on suggestion by - Pekka Savola - - added reference to RFC3849 now that it's available (re: IPv6 documentation - prefix) - - other minor edits - - Figure 1 + Available . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5 Discover and Utilize Local Services . . . . . . . . . . . 6 + 3.6 Avoid Mentioning the IP Addresses of Services . . . . . . 7 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 + 8.2 Informative References . . . . . . . . . . . . . . . . . . . 8 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 + A. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 10 1. Introduction Vendors of consumer electronics and network gear have unfortunately chosen to embed, or "hard-code", globally routable Internet Protocol addresses within their products' firmware. These products use these embedded IP addresses as service identifiers and direct service requests (unsolicited Internet traffic) to them. One recent example was the embedding of the globally routable IP address of a Network Time Protocol server in the firmware of hundreds of thousands of @@ -264,26 +219,26 @@ version-specific name such as "sntp-server.v1.widget.config.example.com". Here, the "config.example.com" namespace is dedicated to that vendor's product configuration, with sub-domains introduced as deemed necessary. Such special-purpose domain names enable ongoing maintenance and reconfiguration of the services for their client hosts and can aid in the ongoing measurement of service usage throughout the product's lifetime. An alternative to inventing vendor-specific domain naming conventions - for a product's service identifiers is to utilize SVR resource + for a product's service identifiers is to utilize SRV resource records (RR), defined by RFC 2782 [10]. SRV records are a generic type of RR which uses a service-specific prefix in combination with a - base domain name. For example, an SVR-cognizant SNTP client might + base domain name. For example, an SRV-cognizant SNTP client might discover Example, Inc.'s suggested NTP server by performing an - SVR-type query to lookup for "_ntp._udp.example.com". + SRV-type query to lookup for "_ntp._udp.example.com". However, note that simply hard-coding DNS name service identifiers rather than IP addresses is not a panacea. Entries in the domain name space are also ephemeral and can change owners for various reasons including acquisitions and litigation. As such, developers and vendors should explore a product's potential failure modes resulting from the loss of administrative control of a given domain for whatever reason. 3.4 Use Special-Purpose, Reserved IP Addresses When Available @@ -361,21 +316,23 @@ pre-configured state then care should be taken to use an appropriate service identifier and use standard resolution mechanisms to dynamically resolve the identifier into an IP address. Also, any such identifiers should be alterable in the field through a conventional command and control interface for the service. 7. Acknowledgements The author thanks the following reviewers for their contributions to this document: Paul Barford, Geoff Huston, David Meyer, Mike - O'Connor, Michael Patton, Tom Petch, and Pekka Savola. + O'Connor, Michael Patton, Tom Petch, and Pekka Savola. Harald + Alvestrand, Spencer Dawkins, Ted Hardie, and Thomas Narten provided + valuable feedback during AD and IESG review. 8. References 8.1 Normative References [1] Hubbard, K., "INTERNET REGISTRY IP ALLOCATION GUIDELINES", RFC 2050, BCP 12, November 1996. [2] Eastlake, D., "Reserved Top Level DNS Names", RFC 2606, BCP 32, June 1999.