idnits 2.17.1 draft-ietf-softwire-security-requirements-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. ** 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 : ---------------------------------------------------------------------------- ** 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 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 327: '...oftwire protocol MUST NOT assume that ...' RFC 2119 keyword, line 330: '... The Softwire MUST BE able to mutual...' RFC 2119 keyword, line 331: '...oftwire protocol MUST be able to estab...' RFC 2119 keyword, line 336: '... concentrator MUST BE protected agai...' RFC 2119 keyword, line 339: '...oftwire protocol MUST BE able to prote...' (12 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 19, 2006) is 6521 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) == Missing Reference: 'RFC 3193' is mentioned on line 92, but not defined == Missing Reference: 'RFC3948' is mentioned on line 399, but not defined == Missing Reference: 'RFC3947' is mentioned on line 400, but not defined == Missing Reference: 'RFC4306' is mentioned on line 369, but not defined ** Obsolete undefined reference: RFC 4306 (Obsoleted by RFC 5996) == Missing Reference: 'RFC4303' is mentioned on line 391, but not defined == Missing Reference: 'RFC1994' is mentioned on line 422, but not defined == Unused Reference: 'I-D.v6ops-tunneling-requirements' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 495, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-01 ** Downref: Normative reference to an Informational draft: draft-ietf-softwire-problem-statement (ref. 'I-D.softwire-problem-statement') -- Possible downref: Normative reference to a draft: ref. 'I-D.v6ops-tunneling-requirements' == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-04 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Yamamoto 3 Internet-Draft C. Williams 4 Expires: December 21, 2006 KDDI R&D Labs 5 F. Parent 6 Independent Consultant 7 H. Yokota 8 KDDI R&D Labs 9 June 19, 2006 11 Softwire Security Analysis and Requirements 12 draft-ietf-softwire-security-requirements-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 21, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document discusses the security requirements of softwire. 46 Authentication, integrity, confidentiality and replay protection of 47 the softwire control and data packets are discussed. Both hub and 48 spokes and mesh solutions are discussed. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Softwire Model . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1 Hub and Spokes . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2 Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Trust Relationship . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Softwire Security Threat Scenarios . . . . . . . . . . . . . . 6 59 6. Softwire Security Requirements . . . . . . . . . . . . . . . . 8 60 7. Guideline for IPSec usage . . . . . . . . . . . . . . . . . . 9 61 7.1 Softwire Security Protocol . . . . . . . . . . . . . . . . 9 62 7.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 10 63 7.2.1 PPP authentication . . . . . . . . . . . . . . . . . . 10 64 7.2.2 L2TPv2 authentication . . . . . . . . . . . . . . . . 10 65 7.2.3 IPsec authentication . . . . . . . . . . . . . . . . . 10 66 7.3 Inter-operability guidelines . . . . . . . . . . . . . . . 11 67 7.4 IPsec filtering details . . . . . . . . . . . . . . . . . 11 68 7.5 IPsec SPD entries example . . . . . . . . . . . . . . . . 11 69 7.5.1 IPv6 over IPv4 Softwire with L2TPv2 example . . . . . 11 70 7.5.2 IPv4 over IPv6 Softwire with example . . . . . . . . . 11 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 76 Intellectual Property and Copyright Statements . . . . . . . . 14 78 1. Introduction 80 The Softwire Working Group is developing methods for discovery, 81 control and encapsulation methods for connecting IPv4 networks across 82 IPv6 networks and IPv6 networks across IPv4 networks. Such IP based 83 protocols were defined as softwire. This document discusses the 84 security requirements based on the softwire problem statement by 85 analyzing security threat scenarios for both "Hubs and Spokes" and 86 "Mesh" [I-D.softwire-problem-statement]. 88 As softwire protocol, L2TP was adopted by the Softwire Working Group. 89 But L2TP does not define tunnel protection mechanism and vulnerable 90 for potential security attacks. Thus, the use of IPsec was discussed 91 to provide for tunnel authentication, confidentiality, integrity 92 checking and replay protection.[RFC 3193] However the usage of IPsec 93 is not always straightforward. This document provides the guidelines 94 for IPsec usage in terms of the softwire network scenarios. 96 2. Terminology 98 The terminology is based on the softwire problem statement document 99 [I-D.softwire-problem-statement]. The following terms are essential 100 for this document. 102 Softwire Concentrator (SC): The node terminating the softwire in the 103 service provider network. 105 Softwire Initiator (SI): The node initiating the softwire within the 106 customer network. 108 3. Softwire Model 110 3.1 Hub and Spokes 112 The Softwire initiator always resides in the customer network. The 113 node, in which the softwire initiator resides, can be the CPE access 114 device, another dedicated CPE router behind the original CPE access 115 device or any kind of host device such as PC, appliance, sensor etc. 117 The host device may not always have direct access to its home carrier 118 network, to which the user has subscribed. For example, the softwire 119 initiator in the laptop PC can attach to various access networks such 120 as Wi-Fi hot-spots, visited office network. Therefore, as shown in 121 Figure 1, the following three use cases should be considered: 123 Case 1: The softwire initiator connects to the softwire concentrator 124 that belongs to the home network service provider via the home 125 network access provider. The IP address of the host may be changed 126 periodically due to the home network service provider's policy. 128 Case 2: The softwire initiator connects to the softwire concentrator 129 that belongs to the home network service provider via the visited 130 network access provider. This is typical of nomadic access use case. 131 The host does not subscribe to the visited network access provider, 132 but this provider has some roaming agreement with the home network 133 service provider of the host. The IP address of the host may be 134 changed periodically due to the home network service provider's 135 policy. 137 Case 3: The softwire initiator connects to the softwire concentrator 138 that belongs to the visited network service provider via the visited 139 network access provider. This is also typical of nomadic access use 140 case. The host does not subscribe to the visited network service 141 provider, but this provider has some roaming agreement with the home 142 network service provider of the host. If this is the case, the IP 143 address of the host is determined by the visited network service 144 provider's policy. 146 The trust relationship for these three cases will also be different. 147 The security consideration must take them into account. In 148 particular, to allow cases 2 and 3, AAA interactions between the home 149 network service provider and visited network access/service provider 150 should be considered. The details of this scenario are given in 151 Section Section 4. 153 visited network visited network 154 access provider service provider 155 +---------------------------------+ 156 | | 157 +......v......+ +.....................|......+ 158 . . . v . 159 +------+ . (case 3) . . +------+ +--------+ . 160 | |=====================.==| | | | . 161 | SI |__.________ . . | SC |<---->| AAAv | . 162 | |---------- \ . . | | | | . 163 +------+ . \\ . . +------+ +--------+ . 164 . \\ . . ^ . 165 ^ +..........\\.+ +.....................|......+ 166 | \\ | 167 | (case 2) \\ | 168 | \\ | 169 | \\ | 170 | +............+ \\ +.....................|......+ 171 . . \\. v . 172 +------+ . . \\__+------+ +--------+ . 173 | | . (case 1) . ---| | | | . 174 | SI |=====================.==| SC |<---->| AAAh | . 175 | | . . . | | | | . 176 +------+ . . . +------+ +--------+ . 177 . . . . 178 +............+ +............................+ 179 home network home network 180 access provider service provider 182 Figure 1: Softwire hub and spokes authentication model 184 3.2 Mesh 186 The softwire initiator and concentrator model is no more applied to 187 the Mesh softwire. The Address Family Boundary Routers (AFBRs) are 188 advertising route (reachability information?) for relatively large 189 network islands. The individual fine-grained authentication is not 190 necessary. 192 Although the softwire for mesh must support authentication, it may be 193 deactivated in some circumstances. This means that the 194 authentication is done between AFBRs. However, if a routing protocol 195 is used to advertise the softwire encapsulation, it must activate 196 authentication. 198 In the data plane, the security mechanism must be supported. 200 4. Trust Relationship 202 To perform authentication between the SC and the SI, the AAA servers 203 need to be involved. One or more AAA servers should reside in the 204 same administrative domain as the SC to authenticate the SI. When 205 the SI is mobile, it may roam from the home network service/access 206 provider network to another (Cases 2 and 3 in Figure 1). In such a 207 situation, the SI may not always connect to the same SC. From the 208 SI's viewpoint, the AAA server that is in the same administrative 209 domain is called the home AAA server and those not in the same 210 administrative domain are called visited AAA servers. The trust 211 relationships between those nodes are as follows: 213 The SC and the AAA server in the same administrative domain must 214 share a trust relationship, which can be done statically or 215 dynamically by the network operator. When the SC needs to 216 authenticate the SI, the SC communicates with the AAA server to 217 request authentication and/or to obtain security information. 218 Therefore, the communication between the SC and the AAA server must 219 be protected. If the SI roams into a network that is not in the same 220 administrative domain, the visited AAA server (AAAv in Figure 1) 221 needs to communicate with the home AAA server (AAAh in Figure 1) that 222 has the SI's security information. The home and visited AAA servers, 223 therefore, must share a trust relationship and the connection between 224 them must also be protected. 226 It can be assumed that the SI and the home AAA server share a trust 227 relationship. The home AAA server provides security information on 228 the SI when it is requested by the visited AAA server. The SI and 229 the visited AAA server do not usually have a trust relationship; 230 however, if the SI can confirm that the home AAA server is involved 231 with the authentication of the SI and the visited AAA server does not 232 alter security information from the home AAA server, the visited AAA 233 server can be trusted by the SI. The communication between the SI, 234 the home and visited AAA servers must be protected. 236 The SI and the SC do not necessarily share a trust relationship 237 especially when the SI roams into a different administrative domain. 238 When they are mutually authenticated by means of e.g. AAA servers, 239 they can start trusting each other. Unless authentication is 240 successfully performed, the softwire protocol should not be continued 241 any further. 243 5. Softwire Security Threat Scenarios 245 Softwire can be used to connect IPv4 networks across public IPv6 246 networks and IPv6 networks across public IPv4 networks. The control 247 and data packets used during the softwire session are vulnerable to 248 attack. 250 A complete threat analysis of softwire requires examination of the 251 protocols used for the for the softwire setup, the encapsulation 252 method used to transport the payload, and other protocols used for 253 configuration (e.g., router advertisements, DHCP). 255 Threat analysis done for other protocols L2TP using IPsec [RFC3193], 256 PANA [RFC4016], NSIS [RFC4081], [I-D.rpsec-routing-threats] are 257 applicable here as well and should be used as reference. 259 Examples of attacks on softwire include: 261 1. An adversary may try to discover identities by snooping data 262 packets. 264 2. An adversary may try to modify packets (both control and data). 266 3. An adversary may try to hijack the softwire tunnel. 268 4. An adversary can launch denial of service attacks by terminating 269 softwire created tunnels. 271 5. An adversary may attempt to disrupt the softwire negotiation in 272 order to weaken or remove confidentiality protection. 274 6. An adversary may impersonate the softwire concentrator to 275 intercept traffic ("rogue" softwire concentrator). 277 7. If ingress filtering is not in place within the access network, a 278 number of DoS attack can happen: 280 * A malicious user can impersonate someone else's IPv4 address 281 during the set-up phase and redirect a tunnel to that IP 282 address. A then can, for example, start a high bandwidth 283 multimedia flow across that tunnel and saturate its victim's 284 uplink. 286 * A malicious user impersonates a large number of IPv4 addresses 287 and request tunnel of their behalf. That would quickly 288 saturate the ISP tunnel server infrastructure. 290 8. If ingress filtering is in place in the core ISP backbone but not 291 in the access network, the potential victims of the above 292 problems will be limited to the ISP's own customers. 294 9. If specific filtering is not in place in the ISP core network, 295 another kind of attack can happen. Customers from another ISP 296 could start using its tunneling infrastructure to get free IPv6 297 connectivity, transforming effectively the ISP into a IPv6 298 transit provider. 300 It is important to consider the differences between the hub and 301 spokes and the mesh solutions with respect to security 302 considerations. 304 For Hub and Spokes model, the SI needs to discover the softwire 305 concentrator. This involves sending solicitations (setup protocol). 306 Once the client has discovered the concentrator, the two will enter 307 authentication exchange. Once the access is granted, the client will 308 most likely exchange data with other nodes in the Internet. These 309 steps are vulnerable to man-in-the-middle (MITM), denial of service 310 (DoS), and service theft attacks, which are discussed in this 311 document. 313 For Mesh model, security threat is not serious because in most cases, 314 softwire is applied among the trusted domains through AFBRs. When 315 the softwire is used inside a provider network, "roaming" issues will 316 not be raised. 318 6. Softwire Security Requirements 320 Based on the security threat analysis in other sections in this 321 document, an enumeration of security requirements are summarized 322 below: 324 The tunnel set-up protocol must not introduce any new vulnerability 325 to the network. 327 The softwire protocol MUST NOT assume that the discovery process is 328 protected. 330 The Softwire MUST BE able to mutually authenticate the initiator and 331 the concentrator. The softwire protocol MUST be able to establish 332 keys between the initiator and the concentrator to protect the 333 Softwire messages. 335 The Softwire signaling communication between the client and the 336 concentrator MUST BE protected against eavesdropping and spoofing 337 attacks. 339 The Softwire protocol MUST BE able to protect itself against replay 340 attacks. 342 The Softwire protocol MUST BE able to protect the device identifier 343 against spoofing when it is exchanged between the initiator and the 344 concentrator. 346 The Softwire protocol MUST BE able to protect disconnect-type and 347 revocation-type messages. 349 The Softwire protocol MUST BE able to securely bind the authenticated 350 session to the device identifier of the client, to prevent service 351 theft. 353 Softwire security MUST meet the key management requirements of the 354 IPsec protocol suite. IKE SHOULD be supported for authentication, 355 security association negotiation, and key management 357 7. Guideline for IPSec usage 359 Note: this section only covers the h&s softwire model. The mesh 360 scenario will be covered at a later stage. 362 The Softwire security requirements state that control and data plane 363 must be able to provide payload security when desired [softwire- 364 problem-statement, section 2.11]. [RFC3193] discusses how L2TP can 365 use IPsec to provide tunnel authentication, privacy protection, 366 integrity checking and replay protection. 368 [RFC3193] can be applied in the softwire h&s model context. New 369 additions to IPsec ([RFC3948],[RFC3947],[RFC4306]) are necessary to 370 meet the softwire requirements were published after [RFC3193]. 372 The following sections will discuss [RFC3193] as applied in the 373 softwire hub&spoke model. 375 In softwire, L2TP is used in a voluntary tunneling model only. The 376 Softwire Initiator (SI) acts as a LAC and PPP endpoint. The L2TP 377 tunnel is always initiated from the SI. 379 The scope of the security is on the L2TP tunnel between the SI and 380 SC. If end to end security is required, a security protocol should 381 be used in the payload packets (out of scope of this document for 382 now). 384 7.1 Softwire Security Protocol 386 [RFC3193] section 2.1 defines the security requirement for L2TP. The 387 same requirements are used for the h&s softwire model. A softwire 388 security compliant implementation MUST implement the security 389 protocol requirements as defined in [RFC3193] section 2.1: 391 o IPsec ESP [RFC4303] in transport mode to secure both the L2TP 392 control and data packets. 394 o IKE MUST be supported for authentication, security association 395 negotiation and key management for IPsec (this is a SHOULD in 396 [RFC3193]) 398 o Since softwire must support NAT traversal, UDP encapsulation of 399 IPsec ESP packets [RFC3948] and negotiation of NAT-traversal in 400 IKE [RFC3947] MUST be supported. 402 7.2 Authentication 404 Softwire requirements for authentication vary from no-authentication 405 to mutual authentication between the SI and SC [I-D.softwire-problem- 406 statement, section 2.11]. The no-authentication mode SHOULD NOT be 407 used on public IP networks. 409 7.2.1 PPP authentication 411 PPP can provide mutual authentication between the SI and SC using 412 CHAP [RFC1994] during the connection establishment phase (LCP). PPP 413 CHAP authentication can be used when the SI and SC are on a trusted, 414 non-public IP network. 416 Since CHAP does not provide per-packet authentication, integrity, or 417 replay protection, PPP CHAP authentication MUST NOT be used on a 418 public IP network. 420 7.2.2 L2TPv2 authentication 422 L2TPv2 provides an optional CHAP-like [RFC1994] tunnel authentication 423 during the control connection establishment [RFC2661, 5.1.1]. The 424 same restrictions apply to L2TPv2 authentication and PPP CHAP 425 authentication. 427 7.2.3 IPsec authentication 429 pre-shared key, certificates, and (for IKEv2) an EAP exchange 431 identity (IP address, DNS name, and X.500 distinguished name) 433 Main mode vs. aggressive mode 435 IPsec authentication vs. PPP/L2TPv2 authentication: keep both? 436 [RFC3193, 5.1], user vs. machine authentication. 438 7.3 Inter-operability guidelines 440 The inter-operability guidelines in [RFC3193] concerning tunnel 441 teardown, fragmentation and per-packet security checks must be 442 followed. [Note: nothing specific to softwire.] 444 7.4 IPsec filtering details 446 The IPsec filtering details from [RFC3193] section 4 are applicable 447 to softwire h&s model. 449 Although the L2TP specification allows the responder (SC in softwire) 450 to use a new IP address when sending the SCCRP, a softwire 451 concentrator implementation SHOULD NOT do this ([RFC3193] section 4). 452 (NOTE: this point should be discussed on the mailing list. This 453 feature may be needed for "load-balancing" between SC) [Mote: To be 454 completed] 456 7.5 IPsec SPD entries example 458 The SPD examples in [RFC3193] appendix A can be applied to softwire 459 model. In that case, the initiator is always the client (SI), and 460 responder is the SC. 462 7.5.1 IPv6 over IPv4 Softwire with L2TPv2 example 464 (To be completed) 466 7.5.2 IPv4 over IPv6 Softwire with example 468 (To be completed) 470 8. Security Considerations 472 This document discusses security issues that should be considered in 473 the deployment of softwire. The requirements in Section 6, however, 474 are not fully discussed yet with respect to security in service 475 discovery, scaling, routing and multicast. 477 9. References 479 9.1 Normative References 481 [I-D.softwire-problem-statement] 482 Li, X., Durand, A., Ward, D., and S. Dawkins, "Softwire 483 Problem Statement", 484 draft-ietf-softwire-problem-statement-01 (work in 485 progress), February 2006. 487 [I-D.v6ops-tunneling-requirements] 488 Durand, A. and F. Parent, "Requirements for assisted 489 tunneling", 490 draft-durand-v6ops-assisted-tunneling-requirements-00 491 (work in progress), September 2004. 493 9.2 Informative References 495 [I-D.bellovin-useipsec] 496 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 497 draft-bellovin-useipsec-04 (work in progress), 498 September 2005. 500 [I-D.rpsec-routing-threats] 501 Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 502 Routing Protocols", draft-ietf-rpsec-routing-threats-07 503 (work in progress), October 2005. 505 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 506 "Securing L2TP using IPsec", RFC 3193, November 2001. 508 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 509 and Network Access (PANA) Threat Analysis and Security 510 Requirements", RFC 4016, March 2005. 512 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 513 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 515 Authors' Addresses 517 Shu Yamamoto 518 KDDI R&D Labs 519 2-1-15 Fujimino-shi 520 Saitama, 356-8502 521 Japan 523 Phone: 81 (49) 278-7311 524 Email: shu@kddilabs.jp 525 Carl Williams 526 KDDI R&D Labs 527 Palo Alto, CA 94301 528 USA 530 Phone: +1.650.279.5903 531 Email: carlw@mcsr-labs.org 533 Florent Parent 534 Independent Consultant 535 Quebec, QC 536 Canada 538 Phone: +1 418 265 7357 539 Email: Florent.Parent@mac.com 541 Hidetoshi Yokota 542 KDDI R&D Labs 543 2-1-15 Ohara 544 Fujimino, Saitama 356-8502 545 Japan 547 Phone: 81 (49) 278-7894 548 Email: yokota@kddilabs.jp 550 Intellectual Property Statement 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; nor does it represent that it has 557 made any independent effort to identify any such rights. Information 558 on the procedures with respect to rights in RFC documents can be 559 found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use of 564 such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository at 566 http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at 572 ietf-ipr@ietf.org. 574 Disclaimer of Validity 576 This document and the information contained herein are provided on an 577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 579 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 580 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 581 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 584 Copyright Statement 586 Copyright (C) The Internet Society (2006). This document is subject 587 to the rights, licenses and restrictions contained in BCP 78, and 588 except as set forth therein, the authors retain all their rights. 590 Acknowledgment 592 Funding for the RFC Editor function is currently provided by the 593 Internet Society.