idnits 2.17.1 draft-le-mip6-firewalls-01.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 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 532. ** 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 == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 11) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 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 283: '... As required by [MIP6], the Mobile Node and the Home Agent MUST use...' RFC 2119 keyword, line 286: '... Agents SHOULD use the Encapsulati...' RFC 2119 keyword, line 363: '...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 250 has weird spacing: '...service attac...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7219 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 468, but no explicit reference was found in the text == Unused Reference: 'STUN' is defined on line 475, 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: 13 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Franck Le 2 File: draft-le-mip6-firewalls-01.txt Stefano Faccin 3 Expires: Januray 2005 Basavaraj Patil 4 Nokia 5 H. Tschofenig 6 Siemens 7 July 2004 9 Mobile IPv6 and Firewalls 10 Problem statement 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 Firewalls are an integral aspect of a majority of IP networks today 38 given the state of security issues, threats and vulnerabilities to 39 data networks. IP networks today are predominantly based on IPv4 40 technology and hence firewalls have been designed for these 41 networks. IPv6 networks are growing at a slow rate. Firewalls for 42 IPv6 networks are still maturing and in development. 44 The IETF has recently standardized Mobile IPv6 which adds mobility 45 support to IPv6. Given the fact that Mobile IPv6 is a recent 46 standard, most firewalls available for IPv6 networks today do not 47 support Mobile IPv6. 49 Unless firewalls are aware of Mobile IPv6 protocol details, these 50 security devices will hamper large-scale deployment of the 51 protocol. This document presents in detail some of the issues that 52 people deploying IPv6 networks which include firewalls should 53 consider when expanding the scope to support Mobile IPv6 as well. 55 The issues are not only applicable to firewalls protecting 56 corporate networks, but are also applicable in 3G mobile networks 57 such as GPRS/UMTS and cdma2000 networks where packet filters are 58 implemented in the GGSN in GPRS/UMTS networks and the PDSN in 59 cdma2000 networks. 61 The goal of this Internet draft is to highlight the issues with 62 firewalls and Mobile IPv6 and act as an enabler for further 63 discussion. Issues identified here can be solved by developing 64 appropriate solutions in the MIP6 WG. 66 1. Introduction 68 Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile 69 IPv6 node to be reachable via its home IPv6 address irrespective of 70 any link that the mobile attaches to. This is possible as a result 71 of the extensions to IPv6 defined in the Mobile IPv6 specification 72 [MIP6]. 74 Mobile IPv6 protocol design also incorporates a feature termed as 75 Route Optimization. This set of extensions is a fundamental part 76 of the protocol that allows to optimize the routing of the packets 77 between a Mobile Node and its correspondent node and therefore the 78 performance of the communication. 80 In most cases, current firewall technologies however do not support 81 Mobile IPv6 or are even unaware of Mobile IPv6 headers and 82 extensions. Since most networks in the current business environment 83 deploy firewalls, this may prevent future large-scale deployment of 84 the Mobile IPv6 protocol. 86 This document presents in detail some of the issues that firewalls 87 present for Mobile IPv6 deployment, as well as the impact of each 88 issue. 90 2. Background information 92 2.1 Overview of stateful inspection packet filters 94 One set of issues is related to the way IP addresses are used in 95 Mobile IP, and the way state information is created and maintained 96 in stateful inspection packet filters. We refer to the internal 97 node as the node connected to the network protected by the 98 firewall, and to external node as the node outside the boundaries 99 of the network protected by the firewall. 101 Subsequently, we describe how stateful inspection packet filters 102 work: 104 When a MN connects to a TCP socket on another host in the Internet, 105 it provides, at the connection setup, the socket (IP address and 106 port) on which it expects to receive a response. 108 When that SYN packet is routed through the firewall, the firewall 109 makes an entry in its state table containing the destination socket 110 and the response socket, and then forwards the packet to the 111 destination. 113 When the response comes back, the filter looks up the packets 114 source and destination sockets in its state table: If they match an 115 expected response, the firewall lets the packet pass. If no table 116 entry exists, the packet is dropped since it was not requested from 117 inside the network. 119 The filter removes the state table entries when the TCP close 120 session negotiation packets are routed through, or after some 121 period of delay, usually a few minutes. This ensures that dropped 122 connections do not leave table holes open. 124 For UDP, similar state is created but since UDP is connectionless 125 and the protocol does not have indication of the beginning nor the 126 end of a session, the state is based only on timers. 128 2.2 Mobile IP6 issues with packet filtering in 3G networks 130 In 3G networks, packet filtering functionalities may be implemented 131 to prevent malicious nodes from flooding or launching other attacks 132 against the 3G subscribers. The packet filtering functionality of 133 3G networks are further described in [3GPP]. 135 In such case, packet filters are set up and applied to both uplink 136 and downlink traffic: outgoing and incoming data not matching the 137 packet filters is dropped. 139 The issues described in the following sections thus also apply to 140 3G networks. 142 3. Scenario when the external node is a Mobile Node 144 Let's assume a communication between an internal node A, and an 145 external Mobile Node B. The node A is in a network protected by a 146 firewall, and node B may also be protected by a firewall but this 147 section focuses on the issues related to the firewall protecting 148 the node A. Issues related to the firewall protecting node B are 149 further described in the following section. 151 +----------------+ +----+ 152 | | | HA | 153 | | +----+ 154 | | Home Agent 155 | +---+ +----+ of B 156 | | A | | FW | 157 | +---+ +----+ 158 | | +---+ 159 | | | B | 160 | | +---+ 161 +----------------+ External Mobile 162 Network protected Node 163 by a firewall 165 Figure 1. Issues between MIP6 and firewalls 166 when a firewall is protecting the CN 168 3.1 Return Routability Test 170 As specified in Mobile IPv6 [MIP6], a MN should base its 171 communication on the Home IP address of B, IP HoA B, and not on the 172 care-of-address that B obtains while attached to a link other than 173 its home link. 175 The state created by the stateful inspection packet filter 176 protecting A is therefore initially based on the IP address of A 177 (IP A) and the home address of the node B (IP HoA B). 179 If the Mobile Node B is connected to its home link, packets are 180 directly exchanged between the nodes A and B. If the Mobile Node B 181 is attached to any other link than its home link (in which case it 182 has a care-of-address), the session can still be maintained by 183 having the MN tunnel the traffic destined to the CN (Node A) via 184 its home agent [MIP6]. Packets forwarded by the Home Agent to the 185 node A will have the source IP address indicating the Home IP 186 address of B and the destination IP address indicating the IP 187 address of A. Such packets can thus pass the firewall functionality 188 protecting A. 190 However nodes A and B might be topologically close to each other 191 while B's Home Agent may be far away, resulting in a trombone 192 effect that can create delay and degrade the performance. 194 Route Optimization is a feature that enables a MN to communicate 195 directly with its CN, without involving the MN's Home Agent in the 196 data path. So in the current scenario the MN B can initiate the 197 route optimization procedure with Node A. Route optimization 198 requires the MN B to send a Binding Update to Node A in order to 199 create an entry in its binding cache that maps the MNs home address 200 to its current care-of-address. However, prior to sending the 201 binding update, the Mobile Node must first execute a Return 202 Routability Test: 204 - the Mobile Node B has to send a Home Test Init message via its 205 Home Agent and 207 - a Care of Test Init message directly to its Correspondent Node A. 209 The Care of Test Init message is sent using the new CoA of B as the 210 source address. Such a packet does not match any entry in the 211 firewall protecting A and as described in Section 2, the CoTi 212 message will thus be dropped by the firewall. As a consequence, the 213 RRT cannot be completed and route optimization cannot be applied. 214 Every packet has to go through the node B's Home Agent and tunneled 215 between B's Home Agent and B. 217 +----------------+ 218 | +----+ HoTI (HoA) +----+ 219 | | FW |<----------------|HA B| 220 | +----X +----+ 221 | +---+ | ^ (CoTI is dropped ^ 222 | | A | | | by FW) | 223 | +---+ | | | HoTI 224 | | | | 225 | | | CoTI (CoA)+---+ 226 | | +------------------| B | 227 +----------------+ +---+ 228 Network protected External Mobile 229 by a firewall Node 231 Figure 2. Issues with Return Routability Test 233 3.2 Issues with Firewall Status Update 235 Even if firewalls are made MIPv6 aware (which might require a 236 different Binding Update security solution) a firewall might still 237 drop packets coming from the new CoA since these incoming packets 238 do not match any existing entry. 240 The packet filters in the firewall need to be updated with the COA 241 of the MN in addition to its HoA. 243 Requiring the stateful inspection filters to update the connection 244 state upon detecting Binding Update messages from a node outside 245 the network protected by the firewall does not appear feasible nor 246 desirable, since currently the firewall does not have any mean to 247 verify the validity of Binding Update messages and to therefore 248 securely modify the state information. Changing the firewall 249 states without verifying the validity of the Binding Update 250 messages could lead to denial of service attacks. Malicious nodes 251 may send faked Binding Update forcing the firewall to change its 252 state information, and therefore leading the firewall to drop 253 packets from the connections that use the legitimate addresses. An 254 adversary might also use an address update to enable its own 255 traffic to enter the network. 257 4. Scenario when the inner node is a Mobile Node 259 Let's assume a communication between an internal Mobile Node A, 260 protected by a firewall, and an external node B. B can also be a 261 Mobile Node protected by a firewall and issues raised in Section 3 262 apply in such case. 264 +----------------+ +----+ 265 | | | HA | 266 | | +----+ 267 | | Home Agent 268 | +---+ +----+ of A +---+ 269 | | A | | FW | | B | 270 | +---+ +----+ +---+ 271 |Internal | External 272 | MN | Node 273 | | 274 +----------------+ 275 Network protected 277 Figure 3. Issues between MIP6 and firewalls 278 when a firewall is protecting the MN 280 4.1 Issues with Binding Updates and Acknowledgements between the Mobile 281 Nodes and their Home Agent 283 As required by [MIP6], the Mobile Node and the Home Agent MUST use 284 IPsec to protect the integrity and authenticity of the Binding 285 Updates and Acknowledgements. Both the Mobile Nodes and the Home 286 Agents SHOULD use the Encapsulating Security Payload (ESP). 288 Many firewalls would however drop ESP packets (default behavior). 289 This may cause the Binding Updates and Acknowledgements between the 290 Mobile Nodes and their Home Agent to be dropped. 292 4.2 Issues with Reachability 293 One of the main advantages of Mobile IPv6 is that it allows the 294 Mobile Node to be always reachable thanks to the Home Agent. A node 295 desiring to establish a communication will send a packet to the 296 Home Address of the MN which causes the packet to be routed to the 297 home link of the MN. The Home agent intercepts the packet destined 298 for the MN and forwards it to the MNs current point of attachment 299 which is indicated by its care-of-address. 301 When considering firewalls, (e.g. when the Mobile Node roams to a 302 network protected by a firewall), the packet forwarded from the 303 Home Agent to the Mobile Node CoA may be dropped at the firewall 304 since it does not match any existing entry. The following further 305 describes the problem that might occur: 307 When entering the visited network, the MN first acquires a Care of 308 Address and then sends a Binding Update to its Home Agent. This 309 message creates a state in the firewall: 311 - it may be a state for the IPsec packet (in the case, the Binding 312 Update message is protected by IPsec) 314 - or it may be a state for a mobility header in case IPsec is not 315 used, but the security of the Binding Update is being provided by 316 some other means such as an authentication option as specified in 317 [AUTH] to solve the issue described in Section 4.1 319 The Binding Acknowledgement response can pass the firewall due to 320 the created state, and be delivered to the Mobile Node. 322 Some firewalls may leave the created state open for a while 323 (implementation dependent), whereas other firewalls may delete the 324 state upon receiving the Binding Acknowledgement message. 326 Let's assume a Correspondent Node tries to initiate a communication 327 with a Mobile Node. The Correspondent Node sends a packet to the 328 Mobile Node's home address. The packet is intercepted by the MN's 329 Home Agent which tunnels it to the MN's CoA. 331 As described in Section 2, the lifetime corresponding to the state 332 in the firewall may have been expired and the state may have been 333 removed. In such case, the incoming packet sent from the CN does 334 not match any existing entry and is therefore dropped at the 335 firewall. 337 Even if the state created above has not expired yet, the state 338 created is for the Binding Update message (IPsec or Mobility 339 Header) whereas the packet sent from the CN is received under the 340 form of an IP in IP packet. The latter does not match any existing 341 entry and is also dropped. 343 4.3 Return Routability Test 345 Security of Mobile IPv6 Binding Update between the MN and the CN is 346 based on the RRT mechanism, the routing infrastructure and secret 347 sharing (see [MIP6]). Since some RRT messages are routed via the 348 home network, the strong trust relationship between the mobile node 349 and the home agent (and the usage of IPsec ESP) is important. As 350 specified in Mobile IPv6 [MIP6] in Section 5.2.5: 352 "For improved security, the data passed between the Home Agent and 353 the Mobile Node is made immune to inspection and passive attacks. 354 Such protection is gained by encrypting the home keygen token as it 355 is tunneled from the Home Agent to the Mobile Node as specified in 356 Section 10.4.6." 358 Section 10.4.6 furthermore specifies: 360 "The return routability procedure described in Section 5.2.5 361 assumes that the confidentiality of the Home Test Init and Home 362 Test messages is protected as they are tunneled between the Home 363 Agent to the Mobile Node. Therefore, the Home Agent MUST support 364 tunnel mode IPsec ESP for the protection of packets belonging to 365 the return routability procedure.". 367 This assumption is valid in some environments, however for networks 368 protected by a firewall, the requirement can be an issue. 370 Typically firewalls need to filter the packets based on the 371 source/destination IP addresses and the TCP/UDP source/destination 372 ports numbers. When a packet is encrypted using IPsec ESP, such 373 information is not available (in particular the port numbers), 374 therefore firewalls may drop the Home Test messages forwarded by 375 the HA to the MNs CoA. The result is that the MN cannot complete 376 the RRT procedure, and consequently cannot perform route 377 optimization by sending any Binding Update messages. 379 When ESP is applied, the firewall cannot differentiate packets 380 containing the Mobility Header defined by MIPv6, i.e., packets for 381 which Mobile IPv6 is used, from other packets. In order to support 382 RRT, one possible idea could be to let the firewall pass all ESP 383 packets coming from the MNs Home Agent. This may, however, not be 384 desirable since it would allow several types of attacks (e.g. 385 flooding) to be carried out against the MN. In cellular networks 386 such flooding may result in attacks such as overbilling since the 387 user is required to pay for all air-interface utilization. 389 A common approach, which is also used for NAT traversal, is to 390 apply UDP encapsulation of IPsec packets. Unlike with NAT traversal 391 it is not possible to detect the presence of a Firewall 392 automatically in the same fashion as with a NAT. A NAT modifies the 393 source IP address when an IP packet travels from the private to the 394 public addressing space. For a Firewall this is not true. Hence, 395 UDP encapsulation needs to be enabled proactively. 397 The Mobile Node would have to send UDP packets to the Home Agent to 398 create the corresponding necessary state in the firewall. The Home 399 Agent should also encapsulate the HoT message in a UDP datagram. 401 As other possible solutions, the home keygen token could be 402 encrypted not using IPsec ESP but specific MIP6 fields within the 403 HoT message so that the packet still appears as a Mobility Header 404 one to the firewall as specified in [AUTH]. 406 4.4 Issues with Change of CoA 408 The internal node A may change its CoA within the network which is 409 protected by a firewall. Node A updates its mobility binding at the 410 Home Agent by sending a Binding Update. Node A may also send 411 Binding Update to its correspondent nodes. 413 However, even if firewalls are made MIPv6 aware to address the 414 issues described in sections 4.1, 4.2 and 4.3, a firewall might 415 still drop incoming packets sent to the new CoA since these 416 incoming packets do not match any existing entry. 418 The packet filters in the firewall needs to be updated with the new 419 COA of the MN. 421 4.5 Change of firewall 423 When the MN A moves, it may move to a link that is served by a 424 different firewall. Node A might be sending BU to its CN, however 425 incoming packets may be dropped at the firewall since the firewall 426 on the new link that the MN attaches to does not have any state 427 that is associated with the MN. 429 5. Conclusion 431 Current firewalls may not only prevent route optimization but may 432 also prevent communications to be established in some cases. This 433 document describes some of the issues between the Mobile IP 434 protocol and current firewall technologies. 436 The authors consider the problems presented in this document quite 437 relevant to deployments of Mobile IPv6 and intend this information 438 be available to the community, so that network administrators who 439 intend to deploy Mobile IPv6 can consider them, and so that 440 solutions/tools can also be developed to solve the identified 441 problems. 443 6. Security Considerations 445 This document describes several issues that exist between the 446 Mobile IPv6 protocol and firewalls. 448 Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing 449 traffic. 451 If the firewall configuration is modified in order to support the 452 Mobile IPv6 protocol but not properly configured, many attacks may 453 be possible as outlined above: malicious nodes may be able to 454 launch different types of denial of service attacks. 456 7. References 458 [3GPP] X. Chen, M. Watson, J. Wiljakka and J. Rinne 459 Problem Statement for MIPv6 Interactions with GPRS/UMTS 460 Packet Filtering IETF internet draft , July 2004 463 [AUTH] A. Patel, K. Leung, M. Khalil, H. Akhtar and 464 K. Chowdhury, Authentication Protocol for Mobile IPv6, 465 IETF internet draft , May 24, 2004 468 [CHES] William R. Cheswick and Steve M. Bellovin 469 Firewalls and Internet Security, Repelling the Wily 470 Hacker 472 [MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support 473 in IPv6", RFC 3775, June 2004 475 [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and 476 R. Mahy, "STUN - Simple Traversal of User Datagram 477 Protocol (UDP) Through Network Address Translators 478 (NATs)", RFC 3489, March 2003. 480 8. Author's Addresses: 482 Franck Le 483 Nokia Research Center, Dallas 484 6000 Connection Drive 485 Irving, TX-75039, USA. 487 E-Mail: franck.le@nokia.com 488 Phone : +1 972 374 1256 490 Stefano Faccin 491 Nokia Research Center, Dallas 492 6000 Connection Drive 493 Irving, TX-75039. USA. 495 E-Mail: stefano.faccin@nokia.com 496 Phone : +1 972 894 4994 498 Basavaraj Patil 499 Nokia, Dallas 500 6000 Connection Drive 501 Irving, TX-75039, USA. 503 EMail: Basavaraj.Patil@nokia.com 504 Phone: +1 972-894-6709 506 Hannes Tschofenig 507 Siemens 508 Otto-Hahn-Ring 6 509 Munich, Bayern 81739 510 Germany 512 EMail: Hannes.Tschofenig@siemens.com 514 9. IPR Statement 516 Intellectual Property Statement 518 The IETF takes no position regarding the validity or scope of any 519 Intel- lectual Property Rights or other rights that might be 520 claimed to pertain to the implementation or use of the technology 521 described in this docu- ment or the extent to which any license 522 under such rights might or might not be available; nor does it 523 represent that it has made any independent effort to identify any 524 such rights. Information on the procedures with respect to rights 525 in RFC documents can be found in BCP 78 and BCP 79. 527 Copies of IPR disclosures made to the IETF Secretariat and any 528 assurances of licenses to be made available, or the result of an 529 attempt made to obtain a general license or permission for the use 530 of such proprietary rights by implementers or users of this 531 specification can be obtained from the IETF on-line IPR repository 532 at http://www.ietf.org/ipr. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary 536 rights that may cover technology that may be required to implement 537 this stan- dard. Please address the information to the IETF at 538 ietf-ipr@ietf.org. 540 Disclaimer of Warranty 542 This document and the information contained herein are provided on 543 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 544 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 545 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 546 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 547 THE USE OF THE INFORMA- TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 548 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 549 PARTICULAR PURPOSE. 551 Copyright Statement 553 Copyright (C) The Internet Society (2004). This document is 554 subject to the rights, licenses and restrictions contained in BCP 555 78, and except as set forth therein, the authors retain all their 556 rights.