idnits 2.17.1 draft-wing-sipping-multipart-mixed-00.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 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. ** 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. 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 are 10 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... A UA SHOULD construct a multipart/m...' RFC 2119 keyword, line 102: '... a SHOULD to provide the necessary p...' RFC 2119 keyword, line 106: '... multipart/mixed MUST have a Content-D...' RFC 2119 keyword, line 113: '...ent-Disposition of "middlebox" MUST be...' RFC 2119 keyword, line 118: '...rmation. Offers SHOULD utilize this l...' (20 more instances...) 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 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 (June 28, 2005) is 6870 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 normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-e2m-sec-reqs (ref. '4') == Outdated reference: A later version (-02) exists of draft-jennings-sipping-multipart-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-04 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-11 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING D. Wing 3 Internet-Draft Cisco Systems 4 Expires: December 30, 2005 June 28, 2005 6 SIP Offer/Answer and Middlebox Communication with End-to-End Security 7 draft-wing-sipping-multipart-mixed-00 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 months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 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. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 30, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document provides a mechanism to allow middleboxes to see IP 41 addresses, ports, and bandwidth when the session description is in an 42 S/MIME-encrypted body. 44 RFC Category 46 The author intends this Internet Draft to be published as an Proposed 47 Standards RFC. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Sending Offers . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2 Receiving Offers and Sending Answers . . . . . . . . . . . 4 55 2.3 Receiving Answers . . . . . . . . . . . . . . . . . . . . 4 56 2.4 Sensitive SDP Information . . . . . . . . . . . . . . . . 4 57 3. Interaction with Multipart/Alternative . . . . . . . . . . . . 4 58 4. Evaluation of End-to-Middle Security Requirements . . . . . . 5 59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1 Offer Containing Plaintext and Encrypted Parts . . . . . . 8 61 5.2 Offer Containing SDP and SDPng Parts and S/MIME Session . 9 62 5.3 Offer Containing Multipart/Mixed and 63 Multipart/Alternative . . . . . . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 68 8.2 Informational References . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . 14 72 1. Introduction 74 Network access and QoS is often enforced by middleboxes, such as SIP 75 proxies coordinating access with firewalls and routers, or by 76 firewalls which examine SIP signaling as it traverses the firewall. 77 Such middleboxes need to know the IP addresses and UDP ports of 78 authorized flows and need to know the bandwidth for flows to provide 79 appropriate QoS. 81 In SIP, S/MIME is specified as the means to provide end-to-end 82 security[2]. However, the use of S/MIME prevents middleboxes from 83 performing their tasks described above. 85 This document describes how to use multipart/mixed to allow an 86 endpoint to use S/MIME security to protect its SDP end-to-end, yet 87 still provide the information necessary for middleboxes to authorize 88 a media flow and provide appropriate QoS. The semantics of 89 multipart/mixed in this document follow the semantics described in 90 [3]. 92 The technique described by this document does not meet all of the 93 requirements of sipping-e2m-sec-reqs [4]. 95 2. Mechanism 97 2.1 Sending Offers 99 A UA SHOULD construct a multipart/mixed body containing at least two 100 parts: at least one part for consumption by the middleboxes and at 101 least one part for consumption by the remote UA. This requirement is 102 a SHOULD to provide the necessary port and bandwidth information to 103 both the Answerer's middleboxes and the Offerer's middleboxes. 105 There is at least a top-level multipart/mixed part containing two 106 parts. The top-level multipart/mixed MUST have a Content-Disposition 107 header field indicating "session" if an offer is contained therein. 108 The first part contains a Content-Type of application/sdp and a 109 Content-Disposition of "middlebox", and a second part contains a 110 Content-Type appropriate for consumption by the remote peer with a 111 Content-Disposition of "session". 113 The SDP sent with the Content-Disposition of "middlebox" MUST be 114 fully compliant with SDP [1] and its extensions. 116 Section 2.4 contains the list of SDP information that is considered 117 too private to reveal in the clear when S/MIME can provide end-to-end 118 encryption of that information. Offers SHOULD utilize this list in 119 determining which pieces of SDP information should be elided from the 120 plaintext multipart/mixed body parts. 122 2.2 Receiving Offers and Sending Answers 124 If a UA receives an offer containing multipart/mixed, and is 125 compliant with this document, the UA MUST ignore the parts containing 126 a Content-Disposition of "middlebox". Such parts are intended by the 127 Offerer to only be processed by middleboxes. The receiver should 128 find a part with a Content-Disposition of "session" and Content-Type 129 of application/sdp. If an Offer contained a multipart/mixed part, an 130 answerer compliant with this specification MUST create an answer 131 containing a multipart/mixed part. This is because the Offerer's 132 network may require seeing the port and bandwidth information even if 133 the Answerer's network has no such need. If an Offer did not contain 134 a multipart/mixed part, the Answer MUST NOT contain a multipart/mixed 135 part. This is because the Offerer might not support multipart/mixed. 137 2.3 Receiving Answers 139 If the Answerer doesn't understand a multipart/mixed Offer, the Offer 140 will be rejected. The UA MAY retry sending the Offer without the 141 multipart/mixed part. However, if the Offerer's network requires 142 disclosure of network ports or bandwidth, such an offer may not 143 succeed in creating a usable media path to the Answerer. Techniques 144 such as ICE [6] or preconditions [7] may be useful to discover when a 145 viable media path wasn't established. 147 2.4 Sensitive SDP Information 149 This section enumerates SDP information that is deemed too sensitive 150 to disclose in unencrypted SDP. Other documents may add to this 151 list. 153 o= (owner/creator and session identifier) 154 s= (session name) 155 i= (session information, media title) 156 u= (URI of description) 157 e= (email address) 158 p= (phone number) 159 k= (encryption key) 160 a=crypto ([11]) 161 a=key-mgmt ([9] when using Null encryption algorithm of MIKEY 162 [10]) 164 3. Interaction with Multipart/Alternative 166 An Offer can contain both a multipart/mixed part and a multipart/ 167 alternative part [5]. This might be necessary, for example, if an 168 Offer contains a part describing an RTP session and another S/MIME- 169 encrypted part describing an SRTP session. See the example in 170 section Section 5.3. Likewise, the opposite might occur -- an Offer 171 might contain a multipart/alternative and inside of that are two 172 multipart/mixed parts. This might be necessary, for example, if an 173 Offer contains two alternatives, one with simple SDP and another with 174 more complex SDPng. The Answer would indicate if SDPng was 175 understood and the middlebox would apply the necessary network policy 176 and QoS for the SDPng session in the Offer. 178 4. Evaluation of End-to-Middle Security Requirements 180 This section evaluates the technique described in this document 181 against End-to-Middle Security Requirements [4]. The requirements 182 below are taken from that document. 184 REQ-GEN-1: The solution SHOULD have little impact on the way a UA 185 handles S/MIME-secured messages. 187 This specification meets requirement REQ-GEN-1. Multipart/mixed 188 doesn't change the handling of S/MIME itself, but multipart/mixed 189 does require compliance with additional portions of MIME, which 190 isn't required by [2]. 192 REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do not 193 provide services based on S/MIME-secured bodies in terms of handling 194 the existing SIP headers. 196 This specification meets requirement REG-GEN-2. 198 REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy 199 servers in terms of handling message bodies. 201 This specification meets requirement REQ-GEN-3. However, if a 202 proxy server was previously parsing application/sdp at the top 203 level of a SIP message and interpreting the SDP in order to apply 204 some network policy, that proxy server will now have to parse the 205 multipart/mixed part. 207 REQ-GEN-4: It SHOULD allow a UA to discover security policies of 208 proxy servers. Security policies imply what data is needed to 209 disclose and/or verify in a message. 211 This specification does not meet requirement REQ-GEN-4. 213 REQ-CONF-1: The solution MUST allow encrypted data to be shared with 214 the recipient UA and a proxy server, when a UA wants. 216 This specification does not meet requirement REQ-CONF-1. 218 REQ-CONF-2: It MUST NOT violate end-to-end encryption when the 219 encrypted data does not need to be shared with any proxy servers. 221 This specification does not meet requirement REQ-CONF-2. 223 REQ-CONF-3: It SHOULD allow a UA to request a proxy server to view 224 specific message bodies. The request itself SHOULD be secure, namely 225 be authenticated for the UA and be verified for the data integrity. 227 This specification does not meet requirement REQ-CONF-3. 229 REQ-CONF-4: It MAY allow a UA to request that the recipient UA 230 disclose information to the proxy server, to which the requesting UA 231 is initially disclosing information. The request itself SHOULD be 232 secure, namely be authenticated for the UA and be verified for the 233 data integrity. 235 This specification does not meet requirement REQ-CONF-4. 237 REQ-INT-1: The solution SHOULD work even when the SIP end-to-end 238 authentication and integrity services are enabled. 240 This specification meets requirement REQ-INT-1. 242 REQ-INT-2: It SHOULD allow a UA to request a proxy server to verify 243 specific message bodies and authenticate the user. The request 244 itself SHOULD be secure, namely be authenticated for the UA and be 245 verified for the data integrity. 247 This specification does not meet requirement REQ-INT-2. 249 REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send 250 the verification data of the same information that the requesting UA 251 is providing to the proxy server. The request itself SHOULD be 252 secure, namely authenticated for the UA and be verified for the data 253 integrity. 255 This specification does not meet requirement REQ-INT-3. 257 5. Examples 259 In the following examples, certain information is elided for brevity, 260 as shown with ellipses ("..."). Encrypted portions are shown with 261 "$". 263 In all of the examples, the plaintext SDP describes the session's 264 ports, codecs, and packetization intervals, but doesn't include 265 secrets such as the SRTP keys. This same technique can be used with 266 "k=" (RTP [8]), a Null MIKEY key ([9], [10]), or sdescriptions [11]. 268 5.1 Offer Containing Plaintext and Encrypted Parts 270 In this example, the unencrypted part doesn't include the SRTP keys, 271 whereas the encrypted part does include the SRTP keys. 273 INVITE sip:bob@biloxi.example.com SIP/2.0 274 ... 275 Content-Type: multipart/mixed; boundary=yradnuoB 276 Content-Disposition: session 278 --yradnuoB 279 Content-ID: <83rqjqef3.218.1@10.1.1.1> 280 Content-Type: application/sdp 281 Content-Disposition: middlebox 283 v=0 284 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 285 s=- 286 c=IN IP4 192.168.47.11 287 t=0 0 288 m=video 51372 RTP/SAVP 31 289 m=audio 49170 RTP/SAVP 0 291 --yradnuoB 292 Content-ID: <83rqjqef3.218.2@10.1.1.1> 293 Content-Type: application/pkcs7-mime 294 Content-Disposition: session 296 $ Content-Type: application/sdp 297 $ Content-Disposition: session 298 $ 299 $ v=0 300 $ o=alice 2890844526 2890844526 IN IP4 192.168.47.11 301 $ s=- 302 $ c=IN IP4 192.168.47.11 303 $ t=0 0 304 $ m=video 51372 RTP/SAVP 31 305 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 306 $ inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 307 $ m=audio 49170 RTP/SAVP 0 308 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 309 $ inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 311 --yradnuoB-- 313 5.2 Offer Containing SDP and SDPng Parts and S/MIME Session 315 In this example, the offer contains SDP and SDPng parts for 316 consumption by an SDP-aware middlebox and by an SDPng-aware 317 middlebox, and contains an encrypted part for consumption by the 318 remote peer. 320 INVITE sip:bob@biloxi.example.com SIP/2.0 321 ... 322 Content-Type: multipart/mixed; boundary=yradnuoB 323 Content-Disposition: session 325 --yradnuoB 326 Content-ID: <98efj3.1@10.1.1.1> 327 Content-Type: application/sdp 328 Content-Disposition: middlebox 330 v=0 331 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 332 s=- 333 c=IN IP4 192.168.47.11 334 t=0 0 335 m=audio 51400 RTP/AVP 0 33 336 a=rtpmap:0 PCMU/8000 337 a=rtpmap:3 GSM/8000 339 --yradnuoB 340 Content-ID: <98efj3.2@10.1.1.1> 341 Content-Type: application/sdpng 342 Content-Disposition: middlebox 344 345 349 --yradnuoB 350 Content-ID: <98efj3.2@10.1.1.1> 351 Content-Type: application/sdpng 352 Content-Disposition: session 354 355 358 --yradnuoB-- 360 5.3 Offer Containing Multipart/Mixed and Multipart/Alternative 361 This example combines multipart/mixed with multipart/alternative[5]. 362 This would be used when an Offerer needs to communicate ports and 363 bandwidth in SDP to a middlebox, and send an encrypted offer 364 containing SDP and SDPng to the remote UA. 366 INVITE sip:bob@biloxi.example.com SIP/2.0 367 ... 368 Content-Type: multipart/mixed; boundary=dexiM 369 Content-Type: session 371 --dexiM 372 Content-Type: application/sdp 373 Content-Disposition: middlebox 375 v=0 376 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 377 s=- 378 c=IN IP4 192.168.47.11 379 t=0 0 380 m=audio 51400 RTP/AVP 0 33 381 a=rtpmap:0 PCMU/8000 382 a=rtpmap:3 GSM/8000 384 --dexiM 385 Content-Type: application/pkcs7-mime 386 Content-Disposition: session 388 $ Content-Type: multipart/alternative; boundary=evitanretlA 389 $ Content-Disposition: session 390 $ 391 $ --evitanretlA 392 $ Content-Type: application/sdp 393 $ Content-ID: <98efj3.1@10.1.1.1> 394 $ 395 $ v=0 396 $ o=alice 2890844526 2890844526 IN IP4 192.168.47.11 397 $ s=- 398 $ c=IN IP4 192.168.47.11 399 $ t=0 0 400 $ m=video 51372 RTP/SAVP 31 401 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 402 $ inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 403 $ m=audio 49170 RTP/SAVP 0 404 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 405 $ inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 406 $ 407 $ --evitanretlA 408 $ Content-Type: application/sdpng 409 $ Content-ID: <98efj3.2@10.1.1.1> 410 $ 411 $ 412 $ 415 $ --evitanretlA-- 417 --dexiM-- 419 6. Security Considerations 421 This document provides a mechanism to protect sensitive information 422 from a middlebox, but the mechanism is only effective if sensitive 423 information is not included in the unencrypted part or parts. 424 Sending sensitive information in unencrypted parts SHOULD be limited 425 to only the information necessary to provide access to the network 426 and QoS. This includes information such as IP address, UDP port, 427 codec, and sample period. 429 A User Agent may maliciously or accidentally provide incorrect 430 information in the part intended for use by a middlebox, and 431 different information in the part intended for use by the remote 432 peer. For example, the utilized bandwidth might be below or above 433 the expected bandwidth due to changing codecs for handling realtime 434 fax. As another example, an endpoint might claim to send a small 435 bandwidth audio stream but actually transmit a large bandwidth video 436 stream. Policy enforcement, such as limiting bandwidth to that 437 described in the middlebox section, can be helpful to thwart such 438 abuse. 440 7. IANA Considerations 442 This document requires IANA registration of the new Content- 443 Disposition value "middlebox". 445 8. References 447 8.1 Normative References 449 [1] Handley, M. and V. Jacobson, "SDP: Session Description 450 Protocol", RFC 2327, April 1998. 452 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 453 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 454 Session Initiation Protocol", RFC 3261, June 2002. 456 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 457 Extensions (MIME) Part Two: Media Types", RFC 2046, 458 November 1996. 460 [4] Ono, K. and S. Tachimoto, "Requirements for End-to-middle 461 Security for the Session Initiation Protocol (SIP)", 462 draft-ietf-sipping-e2m-sec-reqs-06 (work in progress), 463 March 2005. 465 [5] Jennings, C., "SIP Offer/Answer with Multipart MIME", 466 draft-jennings-sipping-multipart-00 (work in progress), 467 February 2005. 469 8.2 Informational References 471 [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 472 Methodology for Network Address Translator (NAT) Traversal for 473 Multimedia Session Establishment Protocols", 474 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 476 [7] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 477 Resource Management and Session Initiation Protocol (SIP)", 478 RFC 3312, October 2002. 480 [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 481 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 482 RFC 3550, July 2003. 484 [9] Arkko, J., "Key Management Extensions for Session Description 485 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 486 draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005. 488 [10] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 489 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 490 August 2004. 492 [11] Andreasen, F., Baugher, M., and D. Wing, "Session Description 493 Protocol Security Descriptions for Media Streams", 494 draft-ietf-mmusic-sdescriptions-11 (work in progress), 495 June 2005. 497 Author's Address 499 Dan Wing 500 Cisco Systems 501 170 West Tasman Drive 502 San Jose, CA 95134 503 USA 505 Email: dwing@cisco.com 507 Intellectual Property Statement 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at 529 ietf-ipr@ietf.org. 531 Disclaimer of Validity 533 This document and the information contained herein are provided on an 534 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 535 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 536 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 537 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 538 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 539 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 541 Copyright Statement 543 Copyright (C) The Internet Society (2005). This document is subject 544 to the rights, licenses and restrictions contained in BCP 78, and 545 except as set forth therein, the authors retain all their rights. 547 Acknowledgment 549 Funding for the RFC Editor function is currently provided by the 550 Internet Society.