idnits 2.17.00 (12 Aug 2021) /tmp/idnits8369/draft-aoun-nsis-nslp-natfw-migration-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** 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.) ** There are 10 instances of lines with control characters in the document. ** 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 461: '... raw IP MUST NOT be used. Network...' RFC 2119 keyword, line 466: '... encapsulation for IPsec protected packets (see [4]) MUST be used...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [1], but that reference does not seem to mention RFC 2119 either. -- 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 (February 16, 2004) is 6668 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) == Unused Reference: '6' is defined on line 514, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 517, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 527, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '2') -- No information found for draft-draft-ietf-nsis-ntlp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: draft-ietf-ipsec-udp-encaps has been published as RFC 3948 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '5') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '6') (Obsoleted by RFC 4566) == Outdated reference: A later version (-03) exists of draft-rosenberg-sipping-nat-scenarios-00 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-01 == Outdated reference: A later version (-04) exists of draft-manner-lrsvp-03 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group C. Aoun 3 Internet-Draft Nortel Networks 4 Expires: August 16, 2004 M. Brunner 5 M. Stiemerling 6 M. Martin 7 NEC 8 H. Tschofenig 9 Siemens 10 February 16, 2004 12 NAT/Firewall NSLP Migration Considerations 13 draft-aoun-nsis-nslp-natfw-migration-01 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 16, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document discusses migration issues towards NSIS NAT/FW NSLP 44 enabled NATs and Firewalls. The document will serve as input to the 45 NSIS NATFW NSLP document. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. NSIS unaware NAT Traversal . . . . . . . . . . . . . . . . . . 5 55 4. Unilateral NSIS signaling . . . . . . . . . . . . . . . . . . 8 57 5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 13 59 6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 14 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 63 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 Normative References . . . . . . . . . . . . . . . . . . . . . 17 67 Informative References . . . . . . . . . . . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . 20 73 1. Introduction 75 The overall NSIS protocol suite (including the NATFW NSLP) is 76 impacted by NSIS NATFW NSLP unaware NATs and Firewalls, this document 77 covers impacts as well as some suggestions to ease the deployments of 78 the NSIS protocol suite until the installed base on NATs and 79 Firewalls migrates to NSIS. 81 The NATFW NSLP should allow an end host supporting NSIS to operate 82 properly without the need of supporting true end-to-end NSIS 83 signaling to its application correspondent. This is very practical 84 during the initial phases of the NSIS migration and is applicable in 85 simple network configurations not affected by asymmetric routing. In 86 the early phases of the NSIS NATFW NSLP migration, this situation 87 will occur quite frequent and hence this scenario must be supported. 89 The NSIS protocol should traverse NSIS unaware NATs (and possibly 90 Firewalls) to allow a smoother deployment of, for example, Qos NSLP 91 in today's networks. To provide a smooth migration it is necessary to 92 understand the coexistence of NSIS aware and unware NATs and 93 Firewalls. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [1]. 101 The terminology used in this document is defined in [2]. 103 3. NSIS unaware NAT Traversal 105 This section discusses how an NE with any NSLP could still operate 106 when an NSIS unaware NAT is on the data path. The detection of an 107 NSIS unaware NAT could be a feature of the NTLP [3], allowing its 108 usage on any NE regardless of the supported NSLPs. 110 Several NSIS independent approaches could be used by the NE to learn 111 its global scoped address in order to use it for its hosted NSLPs. In 112 this version of the document, only the STUN protocol [5] is 113 considered as means to acquire the global scoped address; the next 114 versions will consider other approaches. 116 +---------------------------------------+ 117 | | +--------+ 118 | +----------+ | | STUN | 119 | |Apps | | | Server | 120 | +----------+ +---+| +--------+ 121 | | STUN | |NAT|| 122 | | CLIENT | | || 123 | |__________| +---+| 124 | |ANY_NSLP | | 125 | | NI/NR | | 126 | +----------+ | 127 | Host A | 128 +---------------------------------------+ 130 Figure 1: STUN usage for NSIS unaware NATs 132 Within the initial stages of the NSIS migration, NE functions will be 133 co-hosting a STUN client that was already present on the application 134 end-host. Within Host A, shown in Figure 1, the NSIS API could invoke 135 the services of the STUN client (as shown in Figure 2) upon 136 determination that an NSIS unaware NAT was on the path.This would 137 allow applications using UDP transport to work (only applicable for 138 cone NAT variants [5]). 140 +-----------------+ 141 ___________| NSIS aware NAT |_________ 142 | | Determination | | 143 NSIS | +-----------------+ | NSIS 144 Aware | | Unaware 145 | | 146 | | 147 V V 148 +-------------------+ +------------+ 149 |Proceed with | If not UDP |Used data | 150 |normal NR operation| +--------|transport | 151 +-------------------+ | |protocol | 152 | +------------+ 153 | | If UDP 154 V | 155 +-------------+ | 156 |Log error | | 157 |to app layer | | 158 +-------------+ V 159 +-------------+ 160 | Invoke STUN | 161 | Client | 162 +------+------+ 163 | 164 | 165 | 166 V 167 +------------+ 168 | Send STUN | 169 | binding | 170 | request | 171 +-----+------+ 172 | 173 V 174 +-------------------------+ 175 |Standard STUN operations | 176 +-------------------------+ 178 Figure 2: Interactions with a STUN client 180 NSLPs would use the STUN returned global scoped address for the flow 181 id [3].To allow NSIS signaling to be received by the NR on host A, 182 without impacting existing applications (i.e. without explicitly 183 providing the address and port of the NSIS recipient in the 184 application signaling), the NSIS protocols would need to use NTLP 185 datagram mode transport (as defined in [3]). This would imply that 186 the NTLP will be using the same port as the data flows, this might 187 complicate the proposed mode of operations (and might not meet the 188 expected performance). The next version of the draft will discuss 189 whether this approach would be practical based on received feedback 190 from implementors. 192 Subsequently we discuss how the NATFW NSLP could co-exist with 193 interim NAT traversal mechanisms described in [8]. In Figure 3, a 194 STUN client (Host A) [5], an NE (Host B), a host using a Media Proxy 195 [8] and host using a TURN client [9] co-exist in the same network 196 with a NATFW NSLP aware NAT. There are no reasons for the existing 197 mechanisms to be mutually exclusive every host could continue using 198 the existing interim solutions, meanwhile the unilateral NSIS 199 signaling would be used until both ends support the NSIS NATFW NSLP. 201 +---------------------------+ 202 | _|__1______.STUN Server 203 |STUN Client ----'''''''''' | 204 | Host A | App server 205 | 2 _..NAT++ | .-' 206 | NI/NR __.--'' | 3 .'+ 207 | Host B -'' | Media Proxy.-' 208 | | 209 | | 210 | Host C | 211 | 4 | 212 | Turn Client---------------+---------- TURN Server 213 | Host D | 214 | | 215 +---------------------------+ 217 Figure 3: Coexistence of NSIS NATFW NSLP and existing NAT traversal 218 mechanisms 220 4. Unilateral NSIS signaling 222 When NSIS NAT/FW signaling will start to be deployed, it is quite 223 possible that an NI sends an NSIS message without having an NR to 224 respond to it. The NATFW NSLP should be able to handle this type of 225 deployments. NSIS NATFW NSLP signaling for NAT binds is already local 226 within the trust domain (the Reserve External Address is intercepted 227 by the edge NAT, ref [2], however this is not the case with firewall 228 signaling that should be end to end. 230 Since the purpose of this section is to discuss how are end to end 231 signaled messages handled when no NRs are available on the end-host 232 only Firewalls (the NFs) are discussed within the example networks. 234 There are two interesting cases to be analyzed: 236 Approach 1: Implicit (not explicitly scoped) localized signaling: The 237 local trust domain (from an NI perspective) has at least one NSIS 238 aware Firewall, there is no NR on the far end as well as no NSIS 239 aware NAT or Firewall. This approaches is similar to [13], however 240 the NSIS messages do not included any scoping information. Figure 241 4 shows this scenario graphically. 243 +-----------------------+ +--------------------+ 244 |+----------+ | | +----------+ 245 ||App client| | | |App client| 246 ||NI/NR | FW++ | ,---------. | +----------+ 247 |+----------+ ''''''' The net ---. Host B | 248 | Host A | `---------' | | 249 | | | | 250 | Net A | | Net B | 251 +-----------------------+ +--------------------+ 253 Figure 4: Implicit localized signaling 255 Approach 2: Missing trust with far end host's NFs: The local trust 256 domain has no NSIS aware Firewall, there is no NR at the far end 257 but there is at least an NSIS aware firewall with which the local 258 NI has no direct trust relation (which implies an authorization 259 issue and possibly authentication issues). The main addition to 260 the issue discussed in the localized signaling case above 261 (determination of the last NE on the path and response to the NSIS 262 message by the last NE) is the lack of trust relations with the 263 NI. Figure 5 shows this scenario graphically. 265 +-----------------------+ +--------------------+ 266 |+----------+ | | +----------+ 267 ||App client| | | |App client| 268 ||NI/NR | | ,---------. | FW++ +----------+ 269 |+----------+ ''''''' The net ---. Host B | 270 | Host A | `---------' | | 271 | | | | 272 | Net A | | Net B | 273 +-----------------------+ +--------------------+ 275 Figure 5: Missing trust with the remote host's network 277 In approach (1), the NI sends its firewall policy rule creation 278 message, it traverses the first NF (its own firewall) but there is no 279 NR to respond back. If we consider to have a response timer on the 280 last NF being traversed by an NATFW NSLP message then if no response 281 is received to the NSIS message, the last NF will respond back to the 282 NI with a notification of no far end NR response. This will imply 283 that the signaling will be scoped to the last NF on the path that 284 responded back. Using the network deployment shown in Figure 4, the 285 following mode of operation would apply: 287 Host A Host B 288 NI FW++ Expected NR 289 | | | 290 |1-NSIS Init msg | | 291 |----------------> | | 292 | |2-NSIS Init msg | 293 | | +---------------> | 294 | | |NATFW NSLP ON | 295 | | | | 296 | | | | 297 | | | | 298 | | | Timeout | 299 3-NSIS Init msg Ack| V | 300 |No NR | | 301 |<.................| | 303 Figure 6: Detecting the last NSIS peer 305 Figure 7 provides the message sequences when more than one NSIS aware 306 NAT or Firewall is deployed within the same trust domain. Upon 307 determination of a previous NSIS hop, an NSIS aware node will notify 308 the previous NSIS hop of its existence to avoid launching the timer 309 that triggers sending of an NSIS message back to the NI. The current 310 NTLP message association establishment procedures supports this 311 behavior. The last NF on the path will launch the timer since no 312 valid downstream NSIS neighbor responded back. 314 Trust domain A Trust domain B 315 <..........................................> <--------> 316 Host A Host B 317 NI FW++ FW++ Expected NR 318 | | | | 319 | NSIS Init msg | | | 320 | ----------------> | NSIS Init msg | | 321 | | ---------------> | NSIS Init msg | 322 | | NATFW NSLP ON |---------------->| 323 | | | | with Token | 324 | | Valid . | NATFW NSLP ON | 325 | | NSIS Neighbor | | | 326 | |<-----------------| | | 327 | |----------------->| | Timeout | 328 | | Ack | | | 329 | | | | | 330 | | | | | 331 | | | | | 332 | | | V | 333 | | <................+ | 334 | | NSIS Init msg Ack| | 335 | NSIS Init msg Ack | No NR | | 336 | No NR | | | 337 | <.................| | | 339 Figure 7: Detecting the last NSIS peer (multiple FWs) 341 In approach (2), the NI sends its firewall policy rule creation 342 message, it traverses the FW hosted in Host B's network, but host A 343 is not authorized to install a policy rule unless the policy rule 344 creation is approved by a trusted entity within Net B. Unfortunately 345 Host B was not yet upgraded to support the NATFW NSLP, another entity 346 needs to authorize the policy rule installation. 347 Potentially a trusted third party already aware of the application 348 session held between Host A and Host B could provide an authorization 349 token to Host A [11], the token would be encapsulated within the 350 NATFW NSLP message and would allow the NSIS aware Firewall in Net B 351 to authorize Host A's requested policy rule to be installed. This 352 approach would obviously require to put in place a mechanism to 353 provide the authorization token to Host A. The token could be 354 requested by the NI and included in the NSLP signaling by default or 355 after receiving an error message from the far end NSIS aware Firewall 356 indicating that authorization data is required. The authorization 357 token would need to be associated with the identity of the NI, 358 associating the authorization token with an IP address is not 359 sufficient, and could lead to issues if the IP address was not valid 360 due to address translation occurring on the path, a proper mechanism 361 should be put in place to allow proper authentication of the entitled 362 token user. 364 Figure 8 shows the architecture with two different networks and the 365 trusted third party which creates the authorization. Figure 9 366 provides a message flow for authorization token handling. 368 +---------------+ 369 | Authorization|1-Generate Token 370 | mediator | 371 .'--------------+ 372 .' \ 373 2-Provide .-' \ 374 Token .' \ 375 .' \ 376 .' \4-Check token 377 .-' \ validity 378 +-----------.'----------+ ++----------------+ 379 |+--------.'+ | | \ +----------+ 380 ||App client| | | \ |App client| 381 ||NI/NR +-------. | ,-=.----.-. | FW++ +----------+ 382 |+----------+ `---------'The net `-------- Host B | 383 | Host A | `---------' | | 384 | | 3-Send | | 385 | Network A | NSLP msg with | Network B | 386 +-----------------------+ Token +-----------------+ 388 Figure 8: Authorization Token Handling 390 Trust domain A Trust domain B 391 <........................> <---------------------> 392 Host A Host B 393 NI FW FW++ Expected NR 394 | | | | 395 | NSIS Init msg | | | 396 | ------------------+----------------> | | 397 | | | NSIS Init msg | 398 | | | +-------------->| 399 | | | NATFW NSLP ON | 400 | | NSIS ERROR . | 401 | <....................................| | 402 | |Need Authorization| | 403 | NSIS Init msg | | | 404 | ------------------------------------>| | 405 | with Token | | | 406 | | | NSIS Init msg | 407 | | |---------------->| 408 | | | | with Token | 409 | | Valid + | NATFW NSLP ON | 410 | | NSIS Neighbor | | | 411 | |<-----------------| | Timeout | 412 | |----------------->| | | 413 | NSIS Init msg Ack | Ack | | | 414 | No NR | <................| V | 415 | <.................| NSIS Init msg Ack| | 416 | | No NR | | 418 Figure 9: Authorization Token Message Flow 420 5. NSIS unaware Firewall Traversal 422 In case an NSIS unaware firewall is traversed by NSIS messages, NSIS 423 messages should be allowed to go through it, as well as the exchanged 424 data flows between the user application clients. This is not 425 necessarily an obvious task to perform in case the NSIS messages 426 cannot be identified by the NSIS unaware firewall. Same applies for 427 the user application data flows. 429 NSIS message identification should be supported by existing 430 firewalls. 431 Currently firewalls support flow identification by using the 5 tuple 432 or a sub-set of it. The authors are still expecting feedback from 433 firewall vendors to see if we can assume that existing firewalls will 434 not drop packets including the the Router Alert Option (RAO) [12]. In 435 case existing firewalls drop packets having the router alert option, 436 then the RAO should not be the only element of the used 437 identification filter. 439 User application data flow identification, should be deterministic at 440 a specific address and port range level. This means that the 441 application clients uses a combination of an address and specific 442 transport port range.This combination should be configured on the 443 firewall. 445 In case a NAT is deployed on the path and it is NSIS-NATFW, the 446 assigned bind should be consistent with policy rules configured with 447 the NSIS unaware firewall. 449 Even though the deployed Firewall is not NSIS aware, the application 450 data would still be forwarded if existing interim solutions were used 451 such as a mix of stateless policy rules and flow based states with 452 initial packets sent in the outbound direction (inside to outside a 453 trust domain). 455 6. NATFW NSLP NTLP requirements 457 In this section we list two requirements for the NTLP raised by this 458 document. 460 o When NSIS signaling is used in presence of NSIS unware NATs then 461 raw IP MUST NOT be used. Network address and port translation 462 requires transport layer identifiers as mean to direct inbound 463 traffic to the right recipient. 465 o If IPsec is used to secure NSIS signaling messages then UDP 466 encapsulation for IPsec protected packets (see [4]) MUST be used 467 to ensure that IPsec does not break. IKE with extensions or IKEv2 468 is able to detect the presence of a NAT along the path. 470 7. Security Considerations 472 This document discusses various security issues for NAT/Firewall 473 signaling in migration scenarios. 475 Further security considerations can be found in [2]. 477 8. Open issues 479 Working on this document we identified to the following open issues 480 and actions that need to be taken: 482 o Add a network centric solution to address interim deployment 483 phases where the end host doesn't support yet the NSIS protocol 484 suite. 486 o Provide updates on the RAO firewall issues 488 o Update Section 3 with regards to the multiplexing/demultiplexing 489 of NSIS messages and user data on the same socket. 491 o Move the mediated authorization discussion in Section 4 to [2] 493 Normative References 495 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 496 Levels", March 1997. 498 [2] Stiemerling, M., Martin, M., Tschofenig, H. and C. Aoun, "A NAT/ 499 Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT 500 draft-ietf-nsis-nslp-natfw-01.txt, February 2004. 502 [3] "GIMPS: General Internet Messaging Protocol for Signaling", 503 draft-draft-ietf-nsis-ntlp-00 (work in progress), October 2003. 505 Informative References 507 [4] A. Huttunen et all, A., "UDP Encapsulation of IPsec Packets", 508 DRAFT draft-ietf-ipsec-udp-encaps-07.txt, Jan 2003. 510 [5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 511 Simple Traversal of User Datagram Protocol (UDP) Through 512 Network Address Translators (NATs)", RFC 3489, March 2003. 514 [6] Handley, M. and V. Jacobson, "SDP: Session Description 515 Protocol", RFC 2327, April 1998. 517 [7] ITU-T SG16, "Packet-based multimedia communications systems", 518 ITU-T H.323, November 2000. 520 [8] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for 521 SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in 522 progress), November 2001. 524 [9] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 525 draft-rosenberg-midcom-turn-01 (work in progress), March 2003. 527 [10] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore, 528 "Middlebox Communications (midcom) Protocol Requirements", RFC 529 3304, August 2002. 531 [11] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 532 Set-up with Media Authorization", RFC 3521, April 2003. 534 [12] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 536 [13] Manner, J., "Localized RSVP", draft-manner-lrsvp-03 (work in 537 progress), January 2004. 539 Authors' Addresses 541 Cedric Aoun 542 Nortel Networks 544 France 546 EMail: cedric.aoun@nortelnetworks.com 547 Marcus Brunner 548 Network Laboratories, NEC Europe Ltd. 549 Kurfuersten-Anlage 36 550 Heidelberg 69115 551 Germany 553 Phone: +49 (0) 6221 905 11 29 554 EMail: brunner@ccrle.nec.de 555 URI: http://www.brubers.org/marcus 557 Martin Stiemerling 558 Network Laboratories, NEC Europe Ltd. 559 Kurfuersten-Anlage 36 560 Heidelberg 69115 561 Germany 563 Phone: +49 (0) 6221 905 11 13 564 EMail: stiemerling@ccrle.nec.de 565 URI: 567 Miquel Martin 568 Network Laboratories, NEC Europe Ltd. 569 Kurfuersten-Anlage 36 570 Heidelberg 69115 571 Germany 573 Phone: +49 (0) 6221 905 11 16 574 EMail: miquel.martin@ccrle.nec.de 575 URI: 577 Hannes Tschofenig 578 Siemens AG 579 Otto-Hahn-Ring 6 580 Munich 81739 581 Germany 583 Phone: 584 EMail: Hannes.Tschofenig@siemens.com 585 URI: 587 Intellectual Property Statement 589 The IETF takes no position regarding the validity or scope of any 590 intellectual property or other rights that might be claimed to 591 pertain to the implementation or use of the technology described in 592 this document or the extent to which any license under such rights 593 might or might not be available; neither does it represent that it 594 has made any effort to identify any such rights. Information on the 595 IETF's procedures with respect to rights in standards-track and 596 standards-related documentation can be found in BCP-11. Copies of 597 claims of rights made available for publication and any assurances of 598 licenses to be made available, or the result of an attempt made to 599 obtain a general license or permission for the use of such 600 proprietary rights by implementors or users of this specification can 601 be obtained from the IETF Secretariat. 603 The IETF invites any interested party to bring to its attention any 604 copyrights, patents or patent applications, or other proprietary 605 rights which may cover technology that may be required to practice 606 this standard. Please address the information to the IETF Executive 607 Director. 609 Full Copyright Statement 611 Copyright (C) The Internet Society (2004). All Rights Reserved. 613 This document and translations of it may be copied and furnished to 614 others, and derivative works that comment on or otherwise explain it 615 or assist in its implementation may be prepared, copied, published 616 and distributed, in whole or in part, without restriction of any 617 kind, provided that the above copyright notice and this paragraph are 618 included on all such copies and derivative works. However, this 619 document itself may not be modified in any way, such as by removing 620 the copyright notice or references to the Internet Society or other 621 Internet organizations, except as needed for the purpose of 622 developing Internet standards in which case the procedures for 623 copyrights defined in the Internet Standards process must be 624 followed, or as required to translate it into languages other than 625 English. 627 The limited permissions granted above are perpetual and will not be 628 revoked by the Internet Society or its successors or assignees. 630 This document and the information contained herein is provided on an 631 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 632 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 633 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 634 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 635 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Acknowledgment 639 Funding for the RFC Editor function is currently provided by the 640 Internet Society.