idnits 2.17.1 draft-klensin-ip-service-terms-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 448), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2004) is 7220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2476 (ref. '3') (Obsoleted by RFC 4409) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Klensin 2 Internet-Draft July 13, 2004 3 Expires: January 11, 2005 5 Terminology for Describing Internet Connectivity 6 draft-klensin-ip-service-terms-04.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 11, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 As the Internet has evolved, many types of arrangements have been 42 advertised and sold as "Internet connectivity". Because these may 43 differ significantly in the capabilities they offer, the range of 44 options, and the lack of any standard terminology, the effort to 45 distinguish between these services has caused considerable consumer 46 confusion. This document provides a list of terms and definitions 47 that may be helpful to providers, consumers, and, potentially, 48 regulators in clarifying the type and character of services being 49 offered. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 The Problem and the Requirement . . . . . . . . . . . . . 3 55 1.2 Adoption and a Non-pejorative Terminology . . . . . . . . 3 56 1.3 Definitional Terminology . . . . . . . . . . . . . . . . . 4 57 2. General Terminology . . . . . . . . . . . . . . . . . . . . . 4 58 3. Filtering or Security Issues and Terminology . . . . . . . . . 5 59 4. Additional Terminology . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Disclaimers and Lawyers . . . . . . . . . . . . . . . . . . . 9 63 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . 11 67 1. Introduction 69 1.1 The Problem and the Requirement 71 Different ISPs and other providers offer a wide variety of products 72 that are identified as "Internet" or "Internet access". These 73 products offer different types of functionality and, as a result, 74 some may be appropriate for certain users and uses and not others. 75 For example, a service that offers only access to the Web, but that 76 does not support any other type of Internet services, may be entirely 77 appropriate for someone who is exclusively interested in browsing and 78 in web-based email services, but not for someone who requires access 79 to download files or make more intense use of email. And it is 80 likely to be even less appropriate for someone who requires the 81 ability to operate servers for other users, who needs virtual private 82 network (VPN) capabilities or other secured access to a remote 83 office, or who needs to synchronize mail for offline use. 85 Recent, and rapidly evolving, changes to the Internet's email 86 environment have led to additional restrictions on sending and 87 retrieving email. These restrictions, most of them developed as part 88 of well-intentioned attempts to prevent or fight unsolicited mail of 89 various types, may be imposed independently of the service types 90 described below and are discussed separately in Section 3. 92 Of course, the document describes only the functions provided or 93 permitted by the service provider. It does not, and cannot, specify 94 the functions that pass through and are supported by various 95 user-provided equipment. 97 [[Note in Draft: This paragraph to be removed by the RFC Editor if 98 the document progresses that far.]] This document is a first attempt 99 at establishing some definitions for these various services. It is 100 hoped that the definitions will evolve into ones that can be 101 standardized and adopted widely enough to be useful to users and 102 consumers. 104 1.2 Adoption and a Non-pejorative Terminology 106 The definitions proposed here are clearly of little value if service 107 providers and vendors are not willing to adopt them. Consequently, 108 the terms proposed are intended to not be pejorative, despite the 109 belief of some members of the IETF community that some of these 110 connectively models are simply "broken" or "not really an Internet 111 service". The mention of a particular service or model in this 112 document does not imply any endorsement of it, only recognition of 113 something that exists, or might exist, in the marketplace. 115 1.3 Definitional Terminology 117 When the terms SHOULD, MUST, or MAY are used, and capitalized, in 118 this document, they are used as defined in [1]. 120 2. General Terminology 122 The terms listed in this section are the primary "IP Service Terms" 123 and it is hoped that service providers will adopt them in describing 124 offerings to potential users or customers. 126 Terms are listed below more or less in order of ascending (to "full 127 Internet") capability. In each case, the terminology refers to the 128 intent of the provider (ISP) as expressed in either technical 129 measures or terms and conditions of service. It may be possible to 130 work around particular implementations of these characteristic 131 connectivity types, but those flexibilities are generally not the 132 intent of the provider and are unlikely to be supported if the 133 workarounds stop working. 135 Web connectivity. This service provides connectivity to the web 136 only. Other services are generally not supported. In particular, 137 there may be no access to POP3 or IMAP email, encrypted tunnels or 138 other VPN mechanisms. The addresses used may be private and/or 139 not globally reachable. They are generally dynamic and relatively 140 short-lived (hours or days rather than months or years). These 141 addresses are often announced as "dynamic" to those who keep lists 142 of dial-up or dynamic addresses (see Section 3). The provider may 143 impose a filtering web proxy on the connections; that proxy may 144 change and redirect URLs to other sites than the one originally 145 specified by the user or embedded link. 147 Client connectivity only, without a public address. This service 148 provides access to the Internet without support for server or most 149 peer to peer functions. The IP address assigned to the customer 150 is dynamic and, as a distinguishing feature of this class, is 151 assigned from non-public address space. Servers and peer-to-peer 152 functions are generally not supported by the network address 153 translation (NAT) systems that are required by the use of private 154 addresses (the more precise categorization of types of NATs given 155 in [2] are somewhat orthogonal to this document but might be 156 provided as additional terms as described in Section 4). 157 Filtering web proxies are common with this type of service, and 158 the provider SHOULD indicate whether or not one is present. 160 Client only, public address. This service provides access to the 161 Internet without support for server or most peer to peer 162 functions. The IP address assigned to the customer is in public 163 address space. It is usually nominally dynamic or otherwise 164 subject to change, but may not change for months at a time. Most 165 VPN and similar connections will work with this service. The 166 provider may prohibit the use of server functions by either legal 167 (contractual) restrictions or by filtering of incoming connection 168 attempts. Filtering web proxies are uncommon with this type of 169 service, and the provider SHOULD indicate if one is present. 171 Firewalled Internet Connectivity. This service provides access to 172 the Internet and supports most server and most peer to peer 173 functions with one or more (usually more) static public addresses. 174 It is similar in most respects to "Full Internet Connectivity", 175 below, and all of the qualifications and restrictions on 176 limitations described there apply. However, a managed "firewall" 177 is in place between the customer and the public Internet. This 178 may result in blocking of some services, and others may be 179 intercepted by proxies, content-filtering arrangements, or 180 applications gateways (although the latter three are less common). 181 The provider SHOULD specify which services are blocked and which 182 are intercepted or altered in other ways. 184 In most areas, this service arrangement is offered as an add-on, 185 extra-cost, option with what would otherwise be Full Internet 186 Connectivity. 188 Full Internet Connectivity. This service provides the user full 189 Internet connectivity, with one or more static public addresses. 190 Dynamic addresses that are long-lived enough to make operating 191 servers practical without highly dynamic DNS entries are possible, 192 provided that they are not characterized as "dynamic" to third 193 parties. Filtering web proxies, interception proxies, NAT, and 194 other provider-imposed restrictions on inbound or outbound ports 195 and traffic are incompatible with this type of service and servers 196 on a connected customer LAN are typically considered normal. The 197 only compatible restrictions are bandwidth limitations and 198 prohibitions against network abuse or illegal activities. 200 3. Filtering or Security Issues and Terminology 202 As mentioned in the Introduction, the effort to control or limit 203 objectionable network traffic including unsolicited mail of various 204 types (including "spam"); worms, viruses, and their impact; and in 205 some cases, specific content has led to additional restrictions on 206 the behavior and capabilities of internet services. In general, 207 significant restrictions are more likely to be encountered with web 208 connectivity and non-public-address services, but some current 209 recommendations would apply them at all levels. Some of these mail 210 restrictions may prevent sending outgoing mail except through servers 211 operated by the ISP for that purpose, may prevent use of return 212 addresses of the user's choice, and may even prevent access to mail 213 depositories (other than those supplied by the provider) by 214 remote-access protocols such as POP3 or IMAP4. Because users may 215 have legitimate reasons to access remote file services, remote mail 216 submission servers (or at least to use their preferred email 217 addresses from multiple locations), and to access remote mail 218 depositories (again, a near-requirement if a single address is to be 219 used), it is important that providers disclose the services, filters, 220 and conditions they are making available or imposing. 222 Several key issues in email filtering are of particular importance: 224 Dynamic Addresses. A number of systems, including several 225 "blacklists", are based on the assumption that most undesired 226 email originated from systems with dynamic addresses, especially 227 dialup and home broadband systems. Consequently, they attempt to 228 prevent the addresses from being used to send mail, or perform 229 some other services, except through provider systems designated 230 for that purpose. Different techniques are used to identify 231 systems with dynamic addresses, including provider advertising of 232 such addresses to blacklist operators, heuristics that utilize 233 certain address ranges, and inspection of reverse-mapping domain 234 names to see if they contain telltale strings such as "dsl" or 235 "dial". In some cases, the absence of a reverse-mapping DNS 236 address is taken as an indication that the address is "dynamic" 237 (prohibition on connections based on the absence of a 238 reverse-mapping DNS record was a technique developed for FTP 239 servers many years ago; it was found to have fairly high rates 240 both of prohibiting legitimate connection attempts and failing to 241 prevent illegitimate ones). Service providers SHOULD describe 242 what they are doing in this area for both incoming and outgoing 243 message traffic, and users should be aware that, if an address is 244 advertised as "dynamic", it may be impossible to use it to send 245 mail to an arbitrary system even if Full Internet Connectivity is 246 otherwise provided. 247 Non-public addresses and NATs. The NAT systems that are used to map 248 between private and public address spaces may support connections 249 to distant mail systems for outbound and inbound mail, but terms 250 of service often prohibit the use of systems not supplied by the 251 connectivity provider as well as prohibiting the operation of 252 "servers" (typically not precisely defined) on the client 253 connection. 255 Outbound port filtering from the provider. Another common technique 256 involves blocking connections to servers outside the provider's 257 control by blocking TCP "ports" that are commonly used for 258 messaging functions. Different providers have different theories 259 about this. Some prohibit their customers from accessing external 260 SMTP servers for message submission, but permit the use of the 261 mail submission protocol ([3]) with sender authentication. Others 262 try to block all outgoing messaging-related protocols, including 263 the use of remote mail retrieval protocols (less common with 264 public-address services than those that are dependent on private 265 addresses and NATs). If this type of filtering is present, 266 especially with "Client only, public address" and "Full Internet 267 Connectivity" services, the provider MUST indicate that fact (see 268 also Section 4). Still others may divert (reroute) outbound email 269 traffic to their own servers, on the theory that this eliminates 270 the need for users of portable machines to reconfigure them as 271 they connect from different network locations. Again, this MUST 272 be disclosed, especially since it can have signficant security and 273 privacy implications. 275 More generally, filters that block some or all mail being sent to 276 (or submitted to) remote systems (other than via 277 provider-supported servers), or that attempt to divert that 278 traffic to their own servers, are, as discussed above, becoming 279 common and SHOULD be disclosed. 281 4. Additional Terminology 283 These additional terms, while not as basic to understanding a service 284 offering as the ones identified above, as listed as additional 285 information that a service provider might choose to provide to 286 complement those general definitions. Or a potential customer might 287 use those that are relevant by, for example, constructing a list of 288 specific questions to ask. 290 Version support. Does the service include IPv4 support only, both 291 IPv4 and IPv6 support, or IPv6 support only? 292 Authentication support. Which technical mechanism(s) are used by the 293 service to establish and possibly authenticate connections? 294 Examples might include unauthenticated DHCP, PPP, RADIUS, or HTTP 295 interception. 296 VPNs and Tunnels. Is IPSec blocked or permitted? Are other 297 tunneling techniques at the IP layer or below, such as L2TP, 298 permitted? Is there any attempt to block applications-layer 299 tunnel mechanisms such as SSH? 301 DNS support. Are users required to utilize DNS servers provided by 302 the service provider, or are DNS queries permitted to reach 303 arbitrary servers? 304 IP-related services. Are ICMP messages to and from end user sites 305 generally blocked or permitted? Are specific functions such as 306 ping and traceroute blocked and, if so, at what point in the 307 network? 308 Roaming support. Does the service intentionally include support for 309 IP roaming and, if so, how is this defined? 310 For "broadband" connections, is some dialup arrangement provided 311 for either backup or customer travel? If present, does that 312 arrangement have full access to mailboxes, etc. 313 Applications services provided. Are email services and/or web 314 hosting provided as part of the service, and on what basis? An 315 email services listing should identify whether POP3, IMAP, or web 316 access are provided and in what combinations and what types of 317 authentication and privacy services are supported or required for 318 each. 319 Use and Blocking of Outbound Applications Services. Does the service 320 block use of SMTP or mail submission to other than its own servers 321 or intercept such submissions and route them to its servers? Do 322 its servers restrict the user to use of its domain names on 323 outbound email? (For email specifically, also see Section 3 324 above.) Is FTP PASV supported or blocked? Are blocks or 325 intercepts imposed on other file sharing or file transfer 326 mechanisms, on conferencing applications, or on private 327 applications services? More generally, the provider should 328 identify any actions of the service to block, restrict, or alter 329 the destination of, the outbound use (i.e., the use of services 330 not supplied by the provider or on the provider's network) of 331 applications services. 332 Use and Blocking of Inbound Applications Services. In addition to 333 any issues raised by dynamic or private address space (when 334 present), does the service take any other measures to specifically 335 restrict the connections that can be made to equipment operated by 336 the customer? Specifically, are inbound SMTP, HTTP or HTTPS, FTP, 337 or various peer-to-peer or other connections (possibly including 338 applications not specifically recognized by the provider) 339 prohibited and, if so, which ones? 340 Application Content Filtering. The service should declare whether it 341 provides filtering or protection against worms or denial of 342 service attacks against its customers, virus and UCE filtering for 343 its mail services (if any), non-discretionary or "parental 344 control" filtering of content, and so on. 345 Wiretapping and interception. The service should indicate whether 346 traffic passing through it is subject to lawful intercept with or 347 without notice? Is traffic data stored for possible use by law 348 enforcement with or without notice? 350 5. Security Considerations 352 This document is about terminology, not protocols, and does not raise 353 any particular security issues. However, if the type of terminology 354 that is proposed is widely adopted, it may become easier to identify 355 security-related expectations of particular hosts, LANs, and types of 356 connections. 358 6. Acknowledgements 360 This document was inspired by an email conversation with Vernon 361 Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been 362 proposals to produce definitions like the ones above for many years, 363 that conversation convinced the author that it was finally time to 364 get a strawman on the table to see if the IETF could actually carry 365 it forward. Harald Alvestrand, Brian Carpenter, George Michaelson, 366 Vernon Schryver, and others made several suggestions on the initial 367 draft that resulted in clarifications to the second one and Stephane 368 Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, Pekka Savola, 369 and Vernon Schryver made very useful suggestions that were 370 incorporated into subsequent versions. Susan Harris also gave the 371 penultimate version an exceptional careful reading, which is greatly 372 appreciated. 374 7. Disclaimers and Lawyers 376 [[Note to the IESG and in Draft: several of the people who have 377 contributed to, or commented on, this document have observed that, if 378 it is considered successful, sections of it could well end up in 379 national or local regulations, other types of consumer protection 380 provisions, or contractual terms and conditions. Given that concern, 381 the IESG is requested, to consult legal counsel as to whether the 382 normal disclaimers, which were designed somewhat more for protocol 383 specifications, are adequate to prevent creating (quoting from one 384 contributor), "the smallest atom of liability for the author, the 385 IETF, the RFC Editor, ISOC, or anyone else within 10000 km" from 386 liability. This section should then be removed and, if needed, 387 replaced by text here or elsewhere in the document as appropriate.]] 389 8 Informative References 391 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 392 Levels", BCP 14, RFC 2119, March 1997. 394 [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 395 (NAT) Terminology and Considerations", RFC 2663, August 1999. 397 [3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, 398 December 1998. 400 Author's Address 402 John C Klensin 403 1770 Massachusetts Ave, #322 404 Cambridge, MA 02140 405 USA 407 Phone: +1 617 491 5735 408 EMail: john-ietf@jck.com 410 Intellectual Property Statement 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org. 434 Disclaimer of Validity 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 439 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 440 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 441 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 Copyright Statement 446 Copyright (C) The Internet Society (2004). This document is subject 447 to the rights, licenses and restrictions contained in BCP 78, and 448 except as set forth therein, the authors retain all their rights. 450 Acknowledgment 452 Funding for the RFC Editor function is currently provided by the 453 Internet Society.