Network Working Group J. Klensin Internet-Draft July 1, 2004 Expires: December 30, 2004 Terminology for Describing Internet Connectivity draft-klensin-ip-service-terms-03.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. Klensin Expires December 30, 2004 [Page 1] Internet-Draft IP Service Terms July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The Problem and the Requirement . . . . . . . . . . . . . 3 1.2 Adoption and a Non-pejorative Terminology . . . . . . . . 3 1.3 Definitional Terminology . . . . . . . . . . . . . . . . . 4 2. General Terminology . . . . . . . . . . . . . . . . . . . . . 4 3. Filtering or Security Issues and Terminology . . . . . . . . . 5 4. Additional Terminology . . . . . . . . . . . . . . . . . . . . 7 4.1 Disclaimer -- Note in Draft . . . . . . . . . . . . . . . 7 4.2 Additional Useful Terms . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Klensin Expires December 30, 2004 [Page 2] Internet-Draft IP Service Terms July 2004 1. Introduction 1.1 The Problem and the Requirement Different ISPs and other providers offer a wide variety of products that are identified as "Internet" or "Internet access". These products offer different types of functionality and, as a result, some may be appropriate for certain users and uses and not others. For example, a service that offers only access to the Web, but that does not support any other type of Internet services, may be entirely appropriate for someone who is exclusively interested in browsing and in web-based email services, but not for someone who requires access to download files or make more intense use of email. And it is likely to be even less appropriate for someone who requires the ability to operate servers for other users, who needs virtual private network (VPN) capabilities or other secured access to a remote office, or who needs to synchronize mail for offline use. Recent, and rapidly evolving, changes to the Internet's email environment have led to additional restrictions on sending and retrieving email. These restrictions, most of them developed as part of well-intentioned attempts to prevent or fight unsolicited mail of various types, may be imposed independently of the service types described below and are discussed separately in Section 3. Of course, the document describes only the functions provided or permitted by the service provider. It does not, and cannot, specify the functions that pass through and are supported by various user-provided equipment. [[Note in Draft: This paragraph to be removed by the RFC Editor if the document progresses that far.]] This document is a first attempt at establishing some definitions for these various services. It is hoped that the definitions will evolve into ones that can be standardized and adopted widely enough to be useful to users and consumers. 1.2 Adoption and a Non-pejorative Terminology The definitions proposed here are clearly of little value if service providers and vendors are not willing to adopt them. Consequently, the terms proposed are intended to not be pejorative, despite the belief of some members of the IETF community that some of these connectively models are simply "broken" or "not really an Internet service". The mention of a particular service or model in this document does not imply any endorsement of it, only recognition of something that exists, or might exist, in the marketplace. Klensin Expires December 30, 2004 [Page 3] Internet-Draft IP Service Terms July 2004 1.3 Definitional Terminology When the terms SHOULD, MUST, or MAY are used, and capitalized, in this document, they are used as defined in [1]. 2. General Terminology The terms listed in this section are the primary "IP Service Terms" and it is hoped that service providers will adopt them in describing offerings to potential users or customers. Terms are listed below more or less in order of ascending (to "full Internet") capability. In each case, the terminology refers to the intent of the provider (ISP) as expressed in either technical measures or terms and conditions of service. It may be possible to do some additional things with particular implementations of these characteristic connectivity types, but those flexibilities are generally not the intent of the provider and are unlikely to be supported if the workarounds stop working. Web connectivity. This service provides connectivity to the web only. Other services are generally not supported. In particular, there may be no access to POP3 or IMAP email, encrypted tunnels or other VPN mechanisms. The addresses used may not be public and are generally dynamic and relatively short-lived (hours or days rather than months or years). These addresses are often announced as "dynamic" to those who keep lists of dial-up or dynamic addresses (see Section 3). The provider may impose a filtering web proxy on the connections; that proxy may change and redirect URLs to other sites than the one originally specified by the user or embedded link. Client connectivity only, without a public address. This service provides access to the Internet without support for server or most peer to peer functions. The IP address assigned to the customer is dynamic and, as a distinguishing feature of this class, is assigned from non-public address space. Servers and peer-to-peer functions are generally not supported by the network address translation (NAT) systems that are required by the use of private addresses (the more precise categorization of types of NATs given in [2] are somewhat orthogonal to this document but might be provided as additional terms as described in Section 4). Filtering web proxies are common with this type of service, and the provider SHOULD indicate whether or not one is present. Klensin Expires December 30, 2004 [Page 4] Internet-Draft IP Service Terms July 2004 Client only, public address. This service provides access to the Internet without support for server or most peer to peer functions. The IP address assigned to the customer in public address space. It is usually nominally dynamic or otherwise subject to change, but may not change for months at a time. Most VPN and similar connections will work with this service. The provider may prohibit the use of server functions by either legal (contractual) restrictions or by filtering of incoming connection attempts. Filtering web proxies are uncommon with this type of service, and the provider SHOULD indicate if one is present. Full Internet Connectivity. This service provides the user full Internet connectivity, with one or more static public addresses. Dynamic addresses that are long-lived enough to make operating servers practical without highly dynamic DNS entries are possible, provided that they are not characterized as "dynamic" to third parties. Filtering web proxies, interception proxies, NAT, and other provider-imposed restrictions on inbound or outbound ports and traffic are incompatible with this type of service and servers on a connected customer LAN are typically considered normal. The only compatible restrictions are bandwidth limitations and prohibitions against network abuse or illegal activities. 3. Filtering or Security Issues and Terminology As mentioned in the Introduction, the effort to control or limit objectionable network traffic including unsolicited mail of various types (including "spam"); worms, viruses, and their impact; and in some cases, specific content has led to additional restrictions on the behavior and capabilities of internet services. In general, significant restrictions are more likely to be encountered with web connectivity and non-public-address services, but some current recommendations would apply them at all levels. Some of these mail restrictions may prevent sending outgoing mail except through servers operated by the ISP for that purpose, may prevent use of return addresses of the user's choice, and may even prevent access to mail depositories (other than those supplied by the provider) by remote-access protocols such as POP3 or IMAP4. Because users may have legitimate reasons to access remote file services, remote mail submission servers (or at least to use their preferred email addresses from multiple locations), and to access remote mail depositories (again, a near-requirement if a single address is to be used), it is important that providers disclose the services, filters, and conditions they are making available or imposing. Several key issues in email filtering are of particular importance: Klensin Expires December 30, 2004 [Page 5] Internet-Draft IP Service Terms July 2004 Dynamic Addresses. A number of systems, including several "blacklists", are based on the assumption that most undesired email originated from systems with dynamic addresses, especially dialup and home broadband systems. Consequently, they attempt to prevent the addresses from being used to send mail, or perform some other services, except through provider systems designated for that purpose. Different techniques are used to identify systems with dynamic addresses, including provider advertising of such addresses to blacklist operators, heuristics that utilize certain address ranges, and inspection of reverse-mapping domain names to see if they contain telltale strings such as "dsl" or "dial". In some cases, the absence of a reverse-mapping DNS address is taken as an indication that the address is "dynamic" (prohibition on connections based on the absence of a reverse-mapping DNS record was a technique developed for FTP servers many years ago; it was found to have fairly high rates both of prohibiting legitimate connection attempts and failing to prevent illegitimate ones). Service providers SHOULD describe what they are doing in this area for both incoming and outgoing message traffic, and users should be aware that, if an address is advertised as "dynamic", it may be impossible to use it to send mail to an arbitrary system even if Full Internet Connectivity is otherwise provided. Non-public addresses and NATs. The NAT systems that are used to map between private and public address spaces may support connections to distant mail systems for outbound and inbound mail, but terms of service often prohibit the use of systems not supplied by the connectivity provider as well as prohibiting the operation of "servers" (typically not precisely defined) on the client connection. Outbound port filtering from the provider. Another common technique involves blocking connections to servers outside the provider's control by blocking TCP "ports" that are commonly used for messaging functions. Different providers have different theories about this. Some prohibit their customers from accessing external SMTP servers for message submission, but permit the use of the mail submission protocol ([3]) with sender authentication. Others try to block all outgoing messaging-related protocols, including the use of remote mail retrieval protocols (less common with public-address services than those that are dependent on private addresses and NATs). If this type of filtering is present, especially with "Client only, public address" and "Full Internet Connectivity" services, the provider MUST indicate that fact (see also Section 4). More generally, filters that block some or all mail being sent to remote systems (other than via provider-supported servers) are, as discussed above, becoming common and SHOULD be disclosed. Klensin Expires December 30, 2004 [Page 6] Internet-Draft IP Service Terms July 2004 4. Additional Terminology 4.1 Disclaimer -- Note in Draft [[This subsection is to be dropped or moved (presumably in modified form) to an appendix before final publication.]] This document is a first cut. For these definitions to be useful, considerable input from the IETF community, suggestions for additional terms, and better definitions will be required. The document assumes that a single set of terms will be adequate and that a more complex arrangement --e.g., a matrix or array that contrasts a service type with address availability, presence or absence of NATs, etc.-- is not needed. If something more complex _is_ needed, someone should propose it, although this author is very skeptical about the possibility of getting acceptance for a complex, multidimensional scheme. The suggestion to move the list that now appears below into a separate "Additional Terminology" section is due to Brian Carpenter. It seems to be a good solution, but comments are needed as to whether this gets us into the "matrix" complexity that I have been trying to avoid. Comments on the initial draft of this document suggest that the observations above bear repeating and some expansion. It is easy to come up with cases which the terms suggested do not provide adequate differentiation. Some ISPs try to block VPNs in conjunction with their "client only" services, others do not. In some parts of the world, interception and reinterpretation of DNS queries is common, in others it is quite rare. Those factors, and others, suggest that the simple list below could easily be expanded into a matrix or multidimensional array of features. That type of list might be useful for people writing commercial procurement specifications, but it would not be useful for the "what is being advertised and what are you likely to get" goal of this document. For this specification, anything more complex than a simple list is almost certain to be unusable. Specifically, the following distinctions have been suggested, but have so far been resisted by the author as adding excessive complication. They are listed both for further consideration and to illustrate how easily things can become complicated. Input from the community is, of course, desired. If we preserve this new model, the language of the bullet items may need improvement: unlike the terms above, "the service should..." may not be the right introductory phrase. Suggestions solicited. Klensin Expires December 30, 2004 [Page 7] Internet-Draft IP Service Terms July 2004 4.2 Additional Useful Terms These additional terms, while not as basic to understanding a service offering as the ones identified above, as listed as additional information that a service provider might choose to provide to complement those general definitions. Or a potential customer might use those that are relevant as an in constructing a list of specific questions to ask. Version support. The service should declare that it includes IPv4 support only, both IPv4 and IPv6 support, or IPv6 support only. Authentication support. The service should declare which technical mechanism(s) it uses to establish and possibly authenticate connections - such as unauthenticated DHCP, PPP, RADIUS, HTTP interception... VPNs and Tunnels. Is IPSec blocked or permitted? Are other tunneling techniques at the IP layer or below, such as L2TP, permitted? Is there any attempt to block applications-layer tunnel mechanisms such as SSH? DNS support. Are users required to utilize DNS servers provided by the service provider, or are DNS queries permitted to reach arbitrary servers? IP-related services. Are ICMP messages to and from end user sites generally blocked or permitted? Are specific functions such as ping and traceroute blocked and, if so, at what point in the network? Roaming support. The service should declare whether or not it supports IP roaming. [[Note in draft: this term probably needs to be defined sufficiently to make it useful. Could whomever suggested listing it help here?]] And, for "broadband" connections, whether some dialup arrangement is supported for either backup or customer travel and whether that arrangement has full access to mailboxes, etc. Applications services provided. The service should identify whether it provides email services and/or web hosting, and on what basis. An email services listing should identify whether POP3, IMAP, or web access are provided and in what combinations and what types of authentication and privacy services are supported or required for each. Is FTP PASV supported or blocked? Applications blocking. The service should declare whether it blocks use of SMTP or mail submission to other than its own servers and if its servers restrict the user to use of its domain names on outbound email. Similarly, any actions of the service to block or restrict outbound use of other applications services should be identified. Klensin Expires December 30, 2004 [Page 8] Internet-Draft IP Service Terms July 2004 Filtering. The service should declare whether it provides filtering or protection against worms or denial of service attacks against its customers, virus and UCE filtering for its mail services (if any), non-discretionary or "parental control" filtering of content, and so on. Wiretapping and interception. The service should indicate whether traffic passing through it is subject to lawful intercept with or without notice? Is traffic data stored for possible use by law enforcement with or without notice? 5. Security Considerations This document is about terminology, not protocols, and does not raise any particular security issues. However, if the type of terminology that is proposed is widely adopted, it may become easier to identify security-related expectations of particular hosts, LANs, and types of connections. 6. Acknowledgements This document was inspired by an email conversation with Vernon Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been proposals to produce definitions like the ones above for many years, that conversation convinced the author that it was finally time to get a strawman on the table to see if the IETF could actually carry it forward. Harald Alvestrand, Brian Carpenter, George Michaelson, Vernon Schryver, and others made several suggestions on the initial draft that resulted in clarifications to the second one and Stephane Bortzmeyer, Brian Carpenter, Pekka Savola, and Vernon Schryver made very useful suggestions that were incorporated into the third one. 7 Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. Klensin Expires December 30, 2004 [Page 9] Internet-Draft IP Service Terms July 2004 Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires December 30, 2004 [Page 10] Internet-Draft IP Service Terms July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires December 30, 2004 [Page 11]