idnits 2.17.1 draft-ietf-lemonade-deployments-06.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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 527. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 2007) is 6251 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4550 (ref. 'PROFILE') (Obsoleted by RFC 5550) -- Obsolete informational reference (is this intentional?): RFC 4409 (ref. 'SUBMISSION') (Obsoleted by RFC 6409) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Deployment Considerations for 3 lemonade-compliant Mobile Email R. Gellens 4 Document: draft-ietf-lemonade-deployments-06.txt Qualcomm 5 Expires: September 2007 March 2007 7 Deployment Considerations for lemonade-compliant Mobile Email 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The IETF Trust (2007). All Rights Reserved. 35 Abstract 37 This document discusses deployment issues and describes requirements 38 for successful deployment of mobile email which are implicit in the 39 IETF lemonade documents. 41 Gellens [Page 1] Expires September 2007 42 Table of Contents 44 1 Conventions Used in this Document . . . . . . . . . . . . . . 2 45 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 46 3 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 4 TCP Connections . . . . . . . . . . . . . . . . . . . . . . 3 48 4.1 Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4.2 Maintenance during temporary transport loss . . . . . . 5 50 5 Dormancy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 6.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . 6 53 7 NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 8 Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 56 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 57 11 Normative References . . . . . . . . . . . . . . . . . . . . 10 58 12 Informative References . . . . . . . . . . . . . . . . . . . 10 59 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 60 Appendix A: Changes from Previous Version . . . . . . . . . . 11 61 Intellectual Property Statement . . . . . . . . . . . . . . . 11 62 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 64 1 Conventions Used in this Document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [KEYWORDS]. 70 2 Introduction 72 The IETF lemonade group has developed a set of extensions to IMAP 73 and Message Submission, along with a profile document which 74 restricts server behavior and describes client usage [PROFILE]. 76 Successful deployment of lemonade-compliant mobile email requires 77 various functionality which is generally assumed and hence often not 78 covered in email RFCs. This document describes some of these 79 additional considerations, with a focus on those which have been 80 reported to be problematic. 82 3 Ports 84 Both IMAP and Message Submission have been assigned well-known ports 85 [IANA] which MUST be available. IMAP uses port 143. Message 86 Submission uses port 587. It is REQUIRED that the client be able to 87 contact the server on these ports. Hence the client and server 89 Gellens [Page 2] Expires September 2007 90 systems, as well as any intermediary systems, MUST allow 91 communication on these ports. 93 Historically, MUAs have used port 25 for message submission, and 94 [SUBMISSION] does accommodate this. However, it has become 95 increasingly common for ISPs and organizations to restrict outbound 96 port 25. Additionally, hotels and other public accommodations 97 sometimes intercept port 25 connections, regardless of the 98 destination host, resulting in users unexpectedly submitting 99 potentially sensitive communications to unknown and untrusted 100 third-party servers. Typically, users are not aware of such 101 interception. (Such interception violates [FIREWALLS] and has many 102 negative consequences.) 104 Due to endemic security vulnerabilities in widely-deployed SMTP 105 servers, organizations often employ application-level firewalls 106 which intercept SMTP and permit only a limited subset of the 107 protocol. New extensions are therefore more difficult to deploy on 108 port 25. Since lemonade requires support for several [SUBMISSION] 109 extensions, it is extremely important that lemonade clients use, and 110 lemonade servers listen on, port 587 by default. 112 In addition to communications between the client and server systems, 113 lemonade requires that the Message Submission server be able to 114 establish a TCP connection to the IMAP server (for 115 forward-without-download). This uses port 143 by default. 117 Messaging clients sometimes use protocols to store, retrieve, and 118 update configuration and preference data. Functionality such as 119 setting a new device to use the configuration and preference data of 120 another device, or having a device inherit default configuration 121 data from a user account, an organization, or other source, is 122 likely to be even more useful with small mobile devices. One such 123 protocol which was developed for this purpose is [ACAP]. It is 124 therefore RECOMMENDED that clients be able to contact servers on 125 this port (674). 127 Note that systems which do not support application use of [TCP] on 128 arbitrary ports are not full Internet clients. As a result, such 129 systems use gateways to the Internet which necessarily result in 130 data integrity problems. 132 4 TCP Connections 134 Both IMAP and Message Submission use [TCP]. Hence the client system 135 MUST be able to establish and maintain TCP connections to these 136 servers. The Message Submission server MUST be able to initiate a 137 connection to the IMAP server. Support for application use of [TCP] 139 Gellens [Page 3] Expires September 2007 140 is REQUIRED of both client and server systems. 142 The requirements and advice in [HOST-REQUIREMENTS] SHOULD be 143 followed. 145 Note that, for environments that do not support application use of 146 [TCP] but do so for HTTP, email can be offered by deploying webmail. 147 Webmail is a common term for email over the web, where a server 148 speaks HTTP to the client and an email protocol (often IMAP) to the 149 mail store. Its functionality is necessarily limited by the 150 capabilities of the web client, the webmail server, the protocols 151 used between the webmail server and the client (HTTP and a markup 152 language such as HTML), and between the webmail server and the mail 153 store. However, if HTTP is all that is available to an application, 154 the environment is by definition limited and thus functionality 155 offered to the user must also be limited, and can't be lemonade 156 compliant. 158 4.1 Lifetime 160 The duration of the TCP connections between the client and server 161 systems for both IMAP and Message Submission can be arbitrarily 162 long. The client system, the server, as well as all intermediate 163 systems MUST NOT terminate these TCP connections simply because of 164 their duration. 166 The only permissible timeouts on TCP connections occur at the IMAP 167 and Message Submission application level: if no data is received 168 within a period of time, either side MAY terminate the connection as 169 permitted by the protocol (see [SUBMISSION] or [IMAP]). Such 170 timeouts MUST only be enforced by the server or client, not an 171 intermediary system. Since IMAP permits unsolicited notifications 172 of state changes, it is reasonable for clients to remain connected 173 for extended periods with no data being exchanged. 175 It has been reported that some networks impose time restrictions of 176 their own on TCP connections other than HTTP. Such behavior is 177 harmful to email and all other TCP-based protocols. It is unclear 178 how widespread such reported behavior is, or if it is an accidental 179 consequence of an attempt at optimizing for HTTP traffic, 180 implementation limitations in firewalls, NATs or other devices, or a 181 deliberate choice. Either way, such a barrier to TCP connections is 182 a significant risk to the increasing usage of IETF protocols on such 183 networks. Note that TCP is designed to be more efficient when it is 184 used to transfer data over time. Prohibiting such connections thus 185 imposes hidden costs on an operator's network, forcing clients to 186 use TCP in inefficient ways. One way in which carriers can 187 inadvertently force TCP connections closed, resulting in users 189 Gellens [Page 4] Expires September 2007 190 wasting packets by reopening them, is described in Section 7 192 Note that end systems remain able to terminate TCP connections at 193 any time based on local decisions, for example, to prevent overload 194 during a denial-of-service attack. These mechanisms are permitted 195 to take idle time into consideration and are not affected by these 196 requirements. 198 4.2 Maintenance during temporary transport loss 200 TCP is designed to withstand temporary loss of lower-level 201 connectivity. Such transient loss is not uncommon in mobile systems 202 (for example, due to handoffs, fade, etc.). The TCP connection 203 SHOULD be able to survive temporary lower-level loss when the IP 204 address of the client does not change (for example, short-duration 205 loss of the mobile device's traffic channel or periods of high 206 packet loss). Thus, the TCP/IP stack on the client, the server, and 207 all intermediate systems SHOULD maintain the TCP connection during 208 transient loss of connectivity. 210 To this end, client and server systems SHOULD NOT set the TCP 211 keep-alive socket option, and SHOULD NOT close a connection based on 212 ICMP "soft" errors, such as host unreachable messages. 214 5 Dormancy 216 Cellular data channels are connection-oriented (they are brought up 217 or down to establish or tear down connections); it costs network 218 resources to establish connections. 220 Some mobile devices and networks support dormant mode, in which the 221 traffic channel is brought down during idle periods, yet the PPP or 222 equivalent level remains active, and the mobile retains its IP 223 address. 225 Maintenance of TCP connections during dormancy SHOULD be supported 226 by the client, server, and any intermediate systems. Thus, as 227 stated in 4.2 above, client and server systems SHOULD NOT set the 228 TCP keep-alive socket option, and SHOULD NOT close a connection 229 based on ICMP host unreachable messages. 231 Sending packets just to keep the session active causes unnecessary 232 channel establishment and timeout; with a long-idle TCP connection, 233 this would periodically bring up the channel and then let it idle 234 until it times out, again and again. 236 Gellens [Page 5] Expires September 2007 237 6 Firewalls 239 New services must necessarily have their traffic pass through 240 firewalls in order to be usable by corporate employees or 241 organization members connecting externally, such as when using 242 mobile devices. Firewalls exist to block traffic, yet exceptions 243 must be made for services to be used. There is a body of best 244 practices based on long experience in this area. Numerous 245 techniques exist to help organizations balance protecting themselves 246 and providing services to their members, employees, and/or 247 customers. (Describing, or even enumerating, such techniques and 248 practices is beyond the scope of this document, but section 8 does 249 mention some.) 251 It is critical that protocol design and architecture permit such 252 practices, and not constrain them. One key way in which the design 253 of a new service can aid its secure deployment is to maintain the 254 one-to-one association of services and port numbers. 256 One or more firewalls might exist in the path between the client and 257 server systems, as well as between the Message Submission and IMAP 258 servers. Proper deployment REQUIRES that TCP connections be 259 possible from the client system to the IMAP and Message Submission 260 ports on the servers, as well as from the Message Submission server 261 to the IMAP server. This may require configuring firewalls to 262 permit such usage. 264 Firewalls deployed in the network path MUST NOT damage protocol 265 traffic. In particular, both message submission and IMAP 266 connections from the client MUST be permitted. Firewalls MUST NOT 267 partially block extensions to these protocols, such as by allowing 268 one side of an extension negotiation, as doing so results in the two 269 sides being out of synch, with later failures. See [FIREWALLS] for 270 more discussion. 272 Application proxies, which are a not uncommon mechanism, are 273 discussed in [PROXIES]. 275 6.1 Firewall Traversal 277 An often-heard complaint from those attempting to deploy new 278 services within an organization is that the group responsible for 279 maintaining the firewall is unable or unwilling to open the required 280 ports. The group which owns the firewall, being charged with 281 organizational network security, is often reluctant to open firewall 282 ports without an understanding of the benefits and the security 283 implications of the new service. 285 Gellens [Page 6] Expires September 2007 286 The group wishing to deploy a new service is often tempted to bypass 287 the procedure and internal politics necessary to open the firewall 288 ports. A tempting kludge is to tunnel the new service over an 289 existing service that is already permitted to pass through the 290 firewall, typically HTTP on port 80 or sometimes SMTP on port 25. 291 Some of the downsides to this are discussed in [KLUDGE]. 293 Such bypass can appear to be immediately successful, since the new 294 service seems to deploy. However, assuming the network security 295 group is competent, when they become aware of the kludge, their 296 response is generally to block the violation of organizational 297 security policy. It is difficult to design an application-level 298 proxy/firewall which can provide such access control without 299 violating the transparency requirements of firewalls, as described 300 in [FIREWALLS]. Collateral damage is common in these circumstances. 301 The new service (which initially appeared to have been successfully 302 deployed) as well as those existing services which were leveraged to 303 tunnel the new service, becomes subject to arbitrary and 304 unpredictable failures. This encourages an adversarial relationship 305 between the two groups, which hinders attempts at resolution. 307 Even more serious is what happens if a vulnerability is discovered 308 in the new service. Until the vulnerability is corrected, the 309 network security group must disable both the new service and the 310 (typically mission-critical) existing service on which it is 311 layered. 313 An often-repeated truism is that any computer which is connected to 314 a network is insecure. Security and usefulness are both 315 considerations, with organizations making choices about achieving 316 acceptable measures in both areas. Deploying new services typically 317 requires deciding to permit access to the ports used by the service, 318 with appropriate protections. While the delay necessary to review 319 the implications of a new service may be frustrating, in the long 320 run it is likely to be less expensive than a kludge. 322 7 NATs 324 Many NAT boxes place lifetime limits on state, which has the effect 325 of aging out long-idle TCP connections. Since memory is relatively 326 cheap, there's little benefit in arbitrary timeouts. Instead, the 327 oldest unused connection can be recycled if memory or other 328 resources (such as IP addresses) become exhausted, allowing 329 connections to stay stay up forever when resources are available. 331 Gellens [Page 7] Expires September 2007 332 Any NAT boxes which are deployed between client and server systems 333 SHOULD be configured to have extremely long connection lifetimes. 334 Unlimited lifetimes are RECOMMENDED. 336 Note that IMAP and message submission clients will automatically 337 re-open TCP connections as needed, but it saves time, packets, and 338 processing to avoid the need to do so. Re-opening IMAP and message 339 submission connections generally incurs costs for authentication, 340 TLS negotiation, and server processing, as well as resetting of TCP 341 behavior such as windows. It is also ridiculously wasteful to force 342 clients to send NOOP commands just to maintain NAT state, especially 343 since this can defeat dormancy mode. 345 8 Security Considerations 347 There are numerous security considerations whenever an organization 348 chooses to make any of its services available via the Internet. 349 This includes email from mobile clients. 351 Sites concerned about email security should perform a threat 352 analysis, get relevant defenses and/or insurance in place and then 353 make a conscious decision to open up this service. As discussed in 354 section 6.1, piggybacking email traffic on the HTTP port in an 355 attempt to avoid making a firewall configuration change to 356 explicitly permit mobile email connections would bypass this 357 important step and reduces the overall security of the system. 359 Organizations might wish to purchase a messaging server which comes 360 with some indemnity and/or a messaging server which is used "on the 361 edge" by the organization that sells the server. 363 This document does not attempt to catalogue either the various risks 364 an organization might face or the numerous techniques which can be 365 used to protect against the risks. However, to help illustrate the 366 deployment considerations, a very small sample of some of the risks 367 and countermeasures appear below. 369 Some organizations are concerned that permitting direct access to 370 their mail servers via the Internet increases their vulnerability, 371 since a successful exploit against a mail server can potentially 372 expose all mail and authentication credentials stored on that 373 server, and can serve as an injection point for spam. In addition, 374 there are concerns over eavesdropping or modification of mail data 375 and authentication credentials. 377 Gellens [Page 8] Expires September 2007 378 A large number of approaches exist which can mitigate the risks 379 while allowing access to mail services via mobile clients. 381 Placing servers inside one or more DMZs (demilitarized zones, also 382 called perimeter networks) can protect the rest of the network from 383 a compromised server. An additional way to reduce the risk is to 384 store authentication credentials on a system which is not accessible 385 from the Internet, and which the servers within the DMZ can access 386 only by sending the credentials as received from the client and 387 receiving an authorized/not authorized response. Such isolation 388 reduces the ability of a compromised server to serve as a base for 389 attacking other network hosts. 391 Many additional techniques for further isolation exist, such as 392 having the DMZ IMAP server have no mail store of its own. When a 393 client connects to such a server, the DMZ IMAP server might contact 394 the authentication server and receive a ticket, which it passes to 395 the mail store in order to access the client's mail. In this way a 396 compromised IMAP server cannot be used to access the mail or 397 credentials for other users. 399 It is important to realize that simply throwing an extra box in 400 front of the mail servers, such as a gateway which may use HTTP or 401 any of a number of synchronization protocols to communicate with 402 clients, does not itself change the security aspects. By adding 403 such a gateway, the overall security of the system, and the 404 vulnerability of the mail servers, may remain unchanged or may be 405 significantly worsened. Isolation and indirection can be used to 406 protect against specific risks, but to be effective, such steps need 407 to be done after a threat analysis, and with understanding of the 408 issues involved. 410 Organizations SHOULD deploy servers which support the use of TLS for 411 all connections and which can be optionally configured to require 412 TLS. When TLS is used, it SHOULD be via the STARTTLS extensions 413 rather than the alternate port method. TLS can be an effective 414 measure to protect against specific threats, including eavesdropping 415 and alteration, of the traffic between the end-points. However, 416 just because TLS is deployed does not mean the system is "secure." 418 Attempts at bypassing current firewall policy when deploying new 419 services have serious risks, as discussed in section 6.1. 421 It's rare for a new service to not have associated security 422 considerations. Making email available to an organization's members 423 using mobile devices can offer significant benefits. 425 Gellens [Page 9] Expires September 2007 426 9 IANA Considerations 428 None. 430 10 Acknowledgments 432 Chris Newman and Phil Karn suggested very helpful text. Brian Ross 433 and Dave Cridland reviewed drafts and provided excellent 434 suggestions. 436 11 Normative References 438 [HOST-REQUIREMENTS] "Requirements for Internet Hosts -- 439 Communication Layers", R. Braden, RFC 1122, October 1989. 441 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement 442 Levels", S. Bradner, RFC 2119, BCP 14, March 1997. 444 [IANA] IANA Port Number Registry, 445 447 [TCP] "Transmission Control Protocol", J. Postel, RFC 793, STD 7, 448 September 1981. 450 12 Informative References 452 [ACAP] "ACAP -- Application Configuration Access Protocol", C. 453 Newman, J.G. Myers, RFC 2244, November 1997. 455 [FIREWALLS] "Behavior of and Requirements for Internet Firewalls", 456 N. Freed, RFC 2979, October 2000. 458 [IMAP] "Internet Message Access Protocol -- Version 4rev1", M. 459 Crispin, RFC 3501, March 2003. 461 [KLUDGE] "On the use of HTTP as a Substrate", K. Moore, BCP 56, 462 February 2002. 464 [PROFILE] "Lemonade Profile", S. Maes, A. Melnikov, RFC 4550, June 465 2006. 467 [PROXIES] "Classical versus Transparent IP Proxies", M. Chatel, RFC 468 1919, March 1996. 470 Gellens [Page 10] Expires September 2007 472 [SUBMISSION] "Message Submission for Mail", R. Gellens, J. Klensin, 473 RFC 4409, April 2006. 475 13 Author's Address 477 Randall Gellens 478 QUALCOMM Incorporated 479 5775 Morehouse Drive 480 San Diego, CA 92121 481 randy@qualcomm.com 483 Appendix A: Changes from Previous Version 485 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 487 Changes made from version -04 to -05 as a result of IETF Last Call: 488 o Fixed some typos. 489 o Made first use of TCP into a reference. 491 Changes made from version -03 to -04 as a result of WG Last Call: 492 o New boilerplate text 493 o Wording tweaks from lemonade list (e.g., expanding contractions) 494 o Explcitly state that support for TCP is REQUIRED 495 o Correct reference in timeout text from PROFILE to IMAP 496 o Add RFC number to KEYWORDS reference (nit checker doesn't like 497 BCP number only) 498 o Move HOST-REQUIREMENTS reference to normative from informative 499 o Add TCP reference (since TCP support is REQUIRED) 500 o Add IMAP reference (for port number) 501 o Update PROFILE reference to RFC (from RFC Ed pub queue) 503 Intellectual Property Statement 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed 507 to pertain to the implementation or use of the technology described 508 in this document or the extent to which any license under such 509 rights might or might not be available; nor does it represent that 510 it has made any independent effort to identify any such rights. 511 Information on the procedures with respect to rights in RFC 512 documents can be found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use 517 of such proprietary rights by implementers or users of this 519 Gellens [Page 11] Expires September 2007 520 specification can be obtained from the IETF on-line IPR repository 521 at http://www.ietf.org/ipr. 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights that may cover technology that may be required to implement 526 this standard. Please address the information to the IETF at 527 ietf-ipr@ietf.org. 529 Full Copyright Statement 531 Copyright (C) The IETF Trust (2007). 533 This document is subject to the rights, licenses and restrictions 534 contained in BCP 78, and except as set forth therein, the authors 535 retain all their rights. 537 This document and the information contained herein are provided on 538 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 539 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 540 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 541 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 542 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 543 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 544 FOR A PARTICULAR PURPOSE. 546 Gellens [Page 12] Expires September 2007