idnits 2.17.1 draft-ietf-mip6-firewalls-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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 561. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MIP6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 311: '... As required by [MIP6], the Mobile Node and the Home Agent MUST use...' RFC 2119 keyword, line 314: '... Agents SHOULD use the Encapsulati...' RFC 2119 keyword, line 392: '...Therefore, the Home Agent MUST support...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 278 has weird spacing: '...service attac...' == Line 471 has weird spacing: '...stalled there...' -- 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 (August 2004) is 7194 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: 'CHES' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'STUN' is defined on line 505, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'CHES' ** Obsolete normative reference: RFC 3775 (ref. 'MIP6') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Franck Le 3 File: draft-ietf-mip6-firewalls-00.txt Stefano Faccin 4 Expires: February 2005 Basavaraj Patil 5 Nokia 6 H. Tschofenig 7 Siemens 8 August 2004 10 Mobile IPv6 and Firewalls 11 Problem statement 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than a "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 Firewalls are an integral aspect of a majority of IP networks today 39 given the state of security in the Internet, threats and 40 vulnerabilities to data networks. IP networks today are 41 predominantly based on IPv4 technology and hence firewalls have 42 been designed for these networks. Deployment of IPv6 networks is 43 currently progressing, albeit at a slower pace. Firewalls for IPv6 44 networks are still maturing and in development. 46 Mobility support for IPv6 has now been standardized as specified in 47 RFC3775 [MIP6]. Given the fact that Mobile IPv6 is a recent 48 standard, most firewalls available for IPv6 networks today do not 49 support Mobile IPv6. 51 Unless firewalls are aware of Mobile IPv6 protocol details, these 52 security devices will interfere in the smooth operation of the 53 protocol and can be a detriment to deployment. This document 54 presents in detail some of the issues that people deploying IPv6 55 networks which include firewalls should consider when expanding the 56 scope to support Mobile IPv6 as well. 58 The issues are not only applicable to firewalls protecting 59 enterprise networks, but are also applicable in 3G mobile networks 60 such as GPRS/UMTS and cdma2000 networks where packet filters are 61 implemented in the GGSN in GPRS/UMTS networks and the PDSN in 62 cdma2000 networks. 64 The goal of this Internet draft is to highlight the issues with 65 firewalls and Mobile IPv6 and act as an enabler for further 66 discussion. Issues identified here can be solved by developing 67 appropriate solutions in the MIP6 WG. 69 1. Introduction 71 Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile 72 IPv6 node to be reachable via its home IPv6 address irrespective of 73 any link that the mobile attaches to. This is possible as a result 74 of the extensions to IPv6 defined in the Mobile IPv6 specification 75 [MIP6]. 77 Mobile IPv6 protocol design also incorporates a feature termed as 78 Route Optimization. This set of extensions is a fundamental part 79 of the protocol that enables optimized routing of packets between a 80 Mobile Node and its correspondent node and therefore the 81 performance of the communication. 83 In most cases, current firewall technologies however do not support 84 Mobile IPv6 or are even unaware of Mobile IPv6 headers and 85 extensions. Since most networks in the current business environment 86 deploy firewalls, this may prevent future large-scale deployment of 87 the Mobile IPv6 protocol. 89 This document presents in detail some of the issues that firewalls 90 present for Mobile IPv6 deployment, as well as the impact of each 91 issue. 93 2. Background information 95 2.1 Overview of stateful inspection packet filters 97 One set of issues is related to the way IP addresses are used in 98 Mobile IP, and the way state information is created and maintained 99 in stateful inspection packet filters. We refer to the internal 100 node as the node connected to the network protected by the 101 firewall, and to external node as the node outside the boundaries 102 of the network protected by the firewall. 104 Subsequently, we describe how stateful inspection packet filters 105 work: 107 When a MN connects to a TCP socket on another host in the Internet, 108 it provides, at the connection setup, the socket (IP address and 109 port) on which it expects to receive a response. 111 When that SYN packet is routed through the firewall, the firewall 112 makes an entry in its state table containing the destination socket 113 and the response socket, and then forwards the packet to the 114 destination. 116 When the response comes back, the filter looks up the packets 117 source and destination sockets in its state table: If they match an 118 expected response, the firewall lets the packet pass. If no table 119 entry exists, the packet is dropped since it was not requested from 120 inside the network. 122 The filter removes the state table entries when the TCP close 123 session negotiation packets are routed through, or after some 124 period of delay, usually a few minutes. This ensures that dropped 125 connections do not leave table holes open. 127 For UDP, similar state is created but since UDP is connectionless 128 and the protocol does not have indication of the beginning nor the 129 end of a session, the state is based only on timers. 131 2.2 Mobile IP6 issues with packet filtering in 3G networks 133 In 3G networks, packet filtering functionalities may be implemented 134 to prevent malicious nodes from flooding or launching other attacks 135 against the 3G subscribers. The packet filtering functionality of 136 3G networks are further described in [3GPP]. 138 In such case, packet filters are set up and applied to both uplink 139 and downlink traffic: outgoing and incoming data not matching the 140 packet filters is dropped. 142 The issues described in the following sections thus also apply to 143 3G networks. 145 3. Analysis of various scenarios involving MIP6 nodes and firewalls 147 The following section describes various scenarios involving MIP6 148 nodes and firewalls and presents the issues related to each 149 scenario. 151 In the following section, the node in a network protected by a 152 firewall will be refered to the inner node, and the node in the 153 external network will be refered to the external node. 155 +----------------+ 156 | | 157 | | 158 | | 159 | +---+ +----+ 160 | | A | | FW | 161 | +---+ +----+ 162 |Inner Node | +---+ 163 | | | B | 164 | | +---+ 165 +----------------+ External Node 166 Network protected 167 by a firewall 169 Figure 1. Illustration of inner and external nodes 171 3.1 Scenario when the external node is a Mobile Node 173 Let's assume a communication between an internal node A, and an 174 external Mobile Node B. The node A is in a network protected by a 175 firewall, and node B may also be protected by a firewall but this 176 section focuses on the issues related to the firewall protecting 177 the node A. Issues related to the firewall protecting node B are 178 further described in the following section. 180 +----------------+ +----+ 181 | | | HA | 182 | | +----+ 183 | | Home Agent 184 | +---+ +----+ of B 185 | | A | | FW | 186 | +---+ +----+ 187 | | +---+ 188 | | | B | 189 | | +---+ 190 +----------------+ External Mobile 191 Network protected Node 192 by a firewall 194 Figure 2. Issues between MIP6 and firewalls 195 when a firewall is protecting the CN 197 3.1.1 Return Routability Test sp 198 As specified in Mobile IPv6 [MIP6], a MN should base its 199 communication on the Home IP address of B, IP HoA B, and not on the 200 care-of-address that B obtains while attached to a link other than 201 its home link. 203 The state created by the stateful inspection packet filter 204 protecting A is therefore initially based on the IP address of A 205 (IP A) and the home address of the node B (IP HoA B). 207 If the Mobile Node B is connected to its home link, packets are 208 directly exchanged between the nodes A and B. If the Mobile Node B 209 is attached to any other link than its home link (in which case it 210 has a care-of-address), the session can still be maintained by 211 having the MN tunnel the traffic destined to the CN (Node A) via 212 its home agent [MIP6]. Packets forwarded by the Home Agent to the 213 node A will have the source IP address indicating the Home IP 214 address of B and the destination IP address indicating the IP 215 address of A. Such packets can thus pass the firewall functionality 216 protecting A. 218 However nodes A and B might be topologically close to each other 219 while B's Home Agent may be far away, resulting in a trombone 220 effect that can create delay and degrade the performance. 222 Route Optimization is a feature that enables a MN to communicate 223 directly with its CN, without involving the MN's Home Agent in the 224 data path. So in the current scenario the MN B can initiate the 225 route optimization procedure with Node A. Route optimization 226 requires the MN B to send a Binding Update to Node A in order to 227 create an entry in its binding cache that maps the MNs home address 228 to its current care-of-address. However, prior to sending the 229 binding update, the Mobile Node must first execute a Return 230 Routability Test: 232 - the Mobile Node B has to send a Home Test Init message via its 233 Home Agent and 235 - a Care of Test Init message directly to its Correspondent Node A. 237 The Care of Test Init message is sent using the new CoA of B as the 238 source address. Such a packet does not match any entry in the 239 firewall protecting A and as described in Section 2, the CoTi 240 message will thus be dropped by the firewall. As a consequence, the 241 RRT cannot be completed and route optimization cannot be applied. 242 Every packet has to go through the node B's Home Agent and tunneled 243 between B's Home Agent and B. 245 +----------------+ 246 | +----+ HoTI (HoA) +----+ 247 | | FW |<----------------|HA B| 248 | +----X +----+ 249 | +---+ | ^ (CoTI is dropped ^ 250 | | A | | | by FW) | 251 | +---+ | | | HoTI 252 | | | | 253 | | | CoTI (CoA)+---+ 254 | | +------------------| B | 255 +----------------+ +---+ 256 Network protected External Mobile 257 by a firewall Node 259 Figure 3. Issues with Return Routability Test 261 3.1.2 Issues with Firewall Status Update 263 Even if firewalls are made MIPv6 aware (which might require a 264 different Binding Update security solution) a firewall might still 265 drop packets coming from the new CoA since these incoming packets 266 do not match any existing entry. 268 The packet filters in the firewall need to be updated with the COA 269 of the MN in addition to its HoA. 271 Requiring the stateful inspection filters to update the connection 272 state upon detecting Binding Update messages from a node outside 273 the network protected by the firewall does not appear feasible nor 274 desirable, since currently the firewall does not have any means to 275 verify the validity of Binding Update messages and to therefore 276 securely modify the state information. Changing the firewall 277 states without verifying the validity of the Binding Update 278 messages could lead to denial of service attacks. Malicious nodes 279 may send faked Binding Update forcing the firewall to change its 280 state information, and therefore leading the firewall to drop 281 packets from the connections that use the legitimate addresses. An 282 adversary might also use an address update to enable its own 283 traffic to enter the network. 285 3.2 Scenario when the inner node is a Mobile Node 287 Let's assume a communication between an internal Mobile Node A, 288 protected by a firewall, and an external node B. B can also be a 289 Mobile Node protected by a firewall and issues raised in Section 3 290 apply in such case. 292 +----------------+ +----+ 293 | | | HA | 294 | | +----+ 295 | | Home Agent 296 | +---+ +----+ of A +---+ 297 | | A | | FW | | B | 298 | +---+ +----+ +---+ 299 |Internal | External 300 | MN | Node 301 | | 302 +----------------+ 303 Network protected 305 Figure 4. Issues between MIP6 and firewalls 306 when a firewall is protecting the MN 308 3.2.1 Issues with Binding Updates and Acknowledgements between the 309 Mobile Nodes and their Home Agent 311 As required by [MIP6], the Mobile Node and the Home Agent MUST use 312 IPsec to protect the integrity and authenticity of the Binding 313 Updates and Acknowledgements. Both the Mobile Nodes and the Home 314 Agents SHOULD use the Encapsulating Security Payload (ESP). 316 Many firewalls would however drop ESP packets (default behavior). 317 This may cause the Binding Updates and Acknowledgements between the 318 Mobile Nodes and their Home Agent to be dropped. 320 3.2.2 Issues with Reachability 322 One of the main advantages of Mobile IPv6 is that it allows the 323 Mobile Node to be always reachable thanks to the Home Agent. A node 324 desiring to establish a communication will send a packet to the 325 Home Address of the MN which causes the packet to be routed to the 326 home link of the MN. The Home agent intercepts the packet destined 327 for the MN and forwards it to the MNs current point of attachment 328 which is indicated by its care-of-address. 330 When considering firewalls, (e.g. when the Mobile Node roams to a 331 network protected by a firewall), the packet forwarded from the 332 Home Agent to the Mobile Node CoA may be dropped at the firewall 333 since it does not match any existing entry. The following further 334 describes the problem that might occur: 336 When entering the visited network, the MN first acquires a Care of 337 Address and then sends a Binding Update to its Home Agent. This 338 message creates a state in the firewall: 340 - it may be a state for the IPsec packet (in the case, the Binding 341 Update message is protected by IPsec) 343 - or it may be a state for a mobility header in case IPsec is not 344 used, but the security of the Binding Update is being provided by 345 some other means such as an authentication option as specified in 346 [AUTH] to solve the issue described in Section 4.1 348 The Binding Acknowledgement response can pass the firewall due to 349 the created state, and be delivered to the Mobile Node. 351 Some firewalls may leave the created state open for a while 352 (implementation dependent), whereas other firewalls may delete the 353 state upon receiving the Binding Acknowledgement message. 355 Let's assume a Correspondent Node tries to initiate a communication 356 with a Mobile Node. The Correspondent Node sends a packet to the 357 Mobile Node's home address. The packet is intercepted by the MN's 358 Home Agent which tunnels it to the MN's CoA. 360 As described in Section 2, the lifetime corresponding to the state 361 in the firewall may have been expired and the state may have been 362 removed. In such case, the incoming packet sent from the CN does 363 not match any existing entry and is therefore dropped at the 364 firewall. 366 Even if the state created above has not expired yet, the state 367 created is for the Binding Update message (IPsec or Mobility 368 Header) whereas the packet sent from the CN is received under the 369 form of an IP in IP packet. The latter does not match any existing 370 entry and is also dropped. 372 3.2.3 Return Routability Test 374 Security of Mobile IPv6 Binding Update between the MN and the CN is 375 based on the RRT mechanism, the routing infrastructure and secret 376 sharing (see [MIP6]). Since some RRT messages are routed via the 377 home network, the strong trust relationship between the mobile node 378 and the home agent (and the usage of IPsec ESP) is important. As 379 specified in Mobile IPv6 [MIP6] in Section 5.2.5: 381 "For improved security, the data passed between the Home Agent and 382 the Mobile Node is made immune to inspection and passive attacks. 383 Such protection is gained by encrypting the home keygen token as it 384 is tunneled from the Home Agent to the Mobile Node as specified in 385 Section 10.4.6." 387 Section 10.4.6 furthermore specifies: 389 "The return routability procedure described in Section 5.2.5 390 assumes that the confidentiality of the Home Test Init and Home 391 Test messages is protected as they are tunneled between the Home 392 Agent to the Mobile Node. Therefore, the Home Agent MUST support 393 tunnel mode IPsec ESP for the protection of packets belonging to 394 the return routability procedure.". 396 This assumption is valid in some environments, however for networks 397 protected by a firewall, the requirement can be an issue. 399 Typically firewalls need to filter the packets based on the 400 source/destination IP addresses and the TCP/UDP source/destination 401 ports numbers. When a packet is encrypted using IPsec ESP, such 402 information is not available (in particular the port numbers), 403 therefore firewalls may drop the Home Test messages forwarded by 404 the HA to the MNs CoA. The result is that the MN cannot complete 405 the RRT procedure, and consequently cannot perform route 406 optimization by sending any Binding Update messages. 408 When ESP is applied, the firewall cannot differentiate packets 409 containing the Mobility Header defined by MIPv6, i.e., packets for 410 which Mobile IPv6 is used, from other packets. In order to support 411 RRT, one possible idea could be to let the firewall pass all ESP 412 packets coming from the MNs Home Agent. This may, however, not be 413 desirable since it would allow several types of attacks (e.g. 414 flooding) to be carried out against the MN. In cellular networks 415 such flooding may result in attacks such as overbilling since the 416 user is required to pay for all air-interface utilization. 418 A common approach, which is also used for NAT traversal, is to 419 apply UDP encapsulation of IPsec packets. Unlike with NAT traversal 420 it is not possible to detect the presence of a Firewall 421 automatically in the same fashion as with a NAT. A NAT modifies the 422 source IP address when an IP packet travels from the private to the 423 public addressing space. For a Firewall this is not true. Hence, 424 UDP encapsulation needs to be enabled proactively. 426 The Mobile Node would have to send UDP packets to the Home Agent to 427 create the corresponding necessary state in the firewall. The Home 428 Agent should also encapsulate the HoT message in a UDP datagram. 430 As other possible solutions, the home keygen token could be 431 encrypted not using IPsec ESP but specific MIP6 fields within the 432 HoT message so that the packet still appears as a Mobility Header 433 one to the firewall as specified in [AUTH]. 435 3.2.4 Issues with Change of CoA 436 The internal node A may change its CoA within the network which is 437 protected by a firewall. Node A updates its mobility binding at the 438 Home Agent by sending a Binding Update. Node A may also send 439 Binding Update to its correspondent nodes. 441 However, even if firewalls are made MIPv6 aware to address the 442 issues described in sections 4.1, 4.2 and 4.3, a firewall might 443 still drop incoming packets sent to the new CoA since these 444 incoming packets do not match any existing entry. 446 The packet filters in the firewall needs to be updated with the new 447 COA of the MN. 449 3.2.5 Change of firewall 451 When the MN A moves, it may move to a link that is served by a 452 different firewall. Node A might be sending BU to its CN, however 453 incoming packets may be dropped at the firewall since the firewall 454 on the new link that the MN attaches to does not have any state 455 that is associated with the MN. 457 4. Conclusion 459 Current firewalls may not only prevent route optimization but may 460 also prevent communications to be established in some cases. This 461 document describes some of the issues between the Mobile IP 462 protocol and current firewall technologies. 464 This document captures the various issues involved in the 465 deployment of Mobile IPv6 in networks that would invariably include 466 firewalls. A number of different scenarios are described which 467 include configurations where the mobile node, correspondent node 468 and home agent exist across various boundaries delimited by the 469 firewalls. This enables a better understanding of the issues when 470 deploying Mobile IPv6 as well as providing an understanding for 471 firewall design and policies to be installed therein. 473 5. Security Considerations 475 This document describes several issues that exist between the 476 Mobile IPv6 protocol and firewalls. 478 Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing 479 traffic. 481 If the firewall configuration is modified in order to support the 482 Mobile IPv6 protocol but not properly configured, many attacks may 483 be possible as outlined above: malicious nodes may be able to 484 launch different types of denial of service attacks. 486 6. References 488 [3GPP] X. Chen, M. Watson, J. Wiljakka and J. Rinne 489 Problem Statement for MIPv6 Interactions with GPRS/UMTS 490 Packet Filtering IETF internet draft , July 2004 493 [AUTH] A. Patel, K. Leung, M. Khalil, H. Akhtar and 494 K. Chowdhury, Authentication Protocol for Mobile IPv6, 495 IETF internet draft , May 24, 2004 498 [CHES] William R. Cheswick and Steve M. Bellovin 499 Firewalls and Internet Security, Repelling the Wily 500 Hacker 502 [MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support 503 in IPv6", RFC 3775, June 2004 505 [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and 506 R. Mahy, "STUN - Simple Traversal of User Datagram 507 Protocol (UDP) Through Network Address Translators 508 (NATs)", RFC 3489, March 2003. 510 8. Author's Addresses: 512 Franck Le 513 Nokia Research Center, Dallas 514 6000 Connection Drive 515 Irving, TX-75039, USA. 517 E-Mail: franck.le@nokia.com 518 Phone : +1 972 374 1256 520 Stefano Faccin 521 Nokia Research Center, Dallas 522 6000 Connection Drive 523 Irving, TX-75039. USA. 525 E-Mail: stefano.faccin@nokia.com 526 Phone : +1 972 894 4994 527 Basavaraj Patil 528 Nokia, Dallas 529 6000 Connection Drive 530 Irving, TX-75039, USA. 532 EMail: Basavaraj.Patil@nokia.com 533 Phone: +1 972-894-6709 535 Hannes Tschofenig 536 Siemens 537 Otto-Hahn-Ring 6 538 Munich, Bayern 81739 539 Germany 541 EMail: Hannes.Tschofenig@siemens.com 543 9. IPR Statement 545 Intellectual Property Statement 547 The IETF takes no position regarding the validity or scope of any 548 Intel- lectual Property Rights or other rights that might be 549 claimed to pertain to the implementation or use of the technology 550 described in this docu- ment or the extent to which any license 551 under such rights might or might not be available; nor does it 552 represent that it has made any independent effort to identify any 553 such rights. Information on the procedures with respect to rights 554 in RFC documents can be found in BCP 78 and BCP 79. 556 Copies of IPR disclosures made to the IETF Secretariat and any 557 assurances of licenses to be made available, or the result of an 558 attempt made to obtain a general license or permission for the use 559 of such proprietary rights by implementers or users of this 560 specification can be obtained from the IETF on-line IPR repository 561 at http://www.ietf.org/ipr. 563 The IETF invites any interested party to bring to its attention any 564 copyrights, patents or patent applications, or other proprietary 565 rights that may cover technology that may be required to implement 566 this stan- dard. Please address the information to the IETF at 567 ietf-ipr@ietf.org. 569 Disclaimer of Warranty 571 This document and the information contained herein are provided on 572 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 573 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 574 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 575 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 576 THE USE OF THE INFORMA- TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 577 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 578 PARTICULAR PURPOSE. 580 Copyright Statement 582 Copyright (C) The Internet Society (2004). This document is 583 subject to the rights, licenses and restrictions contained in BCP 584 78, and except as set forth therein, the authors retain all their 585 rights.