--- 1/draft-ietf-opsec-filter-caps-04.txt 2007-03-01 22:13:42.000000000 +0100 +++ 2/draft-ietf-opsec-filter-caps-05.txt 2007-03-01 22:13:42.000000000 +0100 @@ -1,21 +1,21 @@ None. C. Morrow Internet-Draft UUNET Technologies Intended status: Informational G. Jones -Expires: March 5, 2007 The MITRE Corporation +Expires: September 2, 2007 V. Manral IP Infusion - September 1, 2006 + March 1, 2007 Filtering and Rate Limiting Capabilities for IP Network Infrastructure - draft-ietf-opsec-filter-caps-04 + draft-ietf-opsec-filter-caps-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,90 +26,88 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 5, 2007. + This Internet-Draft will expire on September 2, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract - [I-D.ietf-opsec-current-practices] lists operator practices related - to securing networks. This document lists filtering and rate - limiting capabilities needed to support those practices. - Capabilities are limited to filtering and rate limiting packets as - they enter or leave the device. Route filters and service specific - filters (e.g. SNMP, telnet) are not addressed. + [RFC4778] lists operator practices related to securing networks. + This document lists filtering and rate limiting capabilities needed + to support those practices. Capabilities are limited to filtering + and rate limiting packets as they enter or leave the device. Route + filters and service specific filters (e.g. SNMP, telnet) are not + addressed. Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade-offs, etc. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Packet Selection for Management and Data Plane Controls . . . 6 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 - 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 8 + 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10 - 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 11 - 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 12 - 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14 - 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 14 - 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15 - 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16 - 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17 - 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1. Filter Counters Displayed Per Application . . . . . . . . 18 - 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18 - 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19 - 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20 - 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21 - 7. Additional Operational Practices . . . . . . . . . . . . . . . 23 - 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23 - 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23 - 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23 - 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23 - 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 9. Non-normative References . . . . . . . . . . . . . . . . . . . 26 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . . . 29 + 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10 + 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 11 + 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 13 + 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13 + 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 14 + 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 15 + 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 16 + 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Filter Counters Displayed Per Application . . . . . . . . 17 + 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 17 + 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 18 + 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 19 + 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 20 + 7. Additional Operational Practices . . . . . . . . . . . . . . . 22 + 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 22 + 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 22 + 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 22 + 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 22 + 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 9. Non-normative References . . . . . . . . . . . . . . . . . . . 25 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . . . . 28 1. Introduction - This document is defined in the context of - [I-D.ietf-opsec-current-practices]. - [I-D.ietf-opsec-current-practices] defines the goals, motivation, - scope, definitions, intended audience, threat model, potential - attacks and give justifications for each of the practices. Many of - the capabilities listed here refine or add to capabilities listed in - [RFC3871]. + This document is defined in the context of [RFC4778]. [RFC4778] + defines the goals, motivation, scope, definitions, intended audience, + threat model, potential attacks and give justifications for each of + the practices. Many of the capabilities listed here refine or add to + capabilities listed in [RFC3871]. Also see [I-D.lewis-infrastructure-security] for a useful description of techniques for protecting infrastructure devices, including the use of filtering. 1.1. Threat Model Threats in today's networked environment range from simple packet floods with overwhelming bandwidth toward a leaf network to subtle attacks aimed at subverting known vulnerabilities in existing @@ -161,27 +159,27 @@ o Capability (what) o Supported Practices (why) o Current Implementations (how) o Considerations (caveats, resource issues, protocol issues, etc.) The Capability section describes a feature to be supported by the device. The Supported Practice section cites practices described in - [I-D.ietf-opsec-current-practices] that are supported by this - capability. The Current Implementation section is intended to give - examples of implementations of the capability, citing technology and - standards current at the time of writing. It is expected that the - choice of features to implement the capabilities will change over - time. The Considerations section lists operational and resource - constraints, limitations of current implementations, trade-offs, etc. + [RFC4778] that are supported by this capability. The Current + Implementation section is intended to give examples of + implementations of the capability, citing technology and standards + current at the time of writing. It is expected that the choice of + features to implement the capabilities will change over time. The + Considerations section lists operational and resource constraints, + limitations of current implementations, trade-offs, etc. 2. Packet Selection for Management and Data Plane Controls In this document Section 3 describes a number of criteria for performing packet selection. It is assumed in this document that o all of these criteria can be used to select packets for both filtering and rate limiting packets, o management plane controls can be implemented by applying these @@ -201,35 +199,33 @@ 3.1. Select Traffic on All Interfaces Capability. The device provides a means to filter IP packets on any interface implementing IP. Supported Practices. - * Security Practices for Device Management - ([I-D.ietf-opsec-current-practices], Section 2.2.2) + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) * Security Practices for Data Path ([I-D.ietf-opsec-current- practices], Section 2.3.2) * Security Practices for Software Upgrades and Configuration Integrity/Validation ([I-D.ietf-opsec-current-practices], Section 2.5.2) - * Data Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.1) + * Data Plane Filtering ([RFC4778], Section 2.7.1) - * Management Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.2) + * Management Plane Filtering ([RFC4778], Section 2.7.2) * Profile Current Traffic (Section 7.1) * Block Malicious Packets (Section 7.2) Current Implementations. Many devices currently implement access control lists or filters that allow filtering based on protocol and/or source/destination address and or source/destination port and allow these filters to @@ -233,38 +229,35 @@ Many devices currently implement access control lists or filters that allow filtering based on protocol and/or source/destination address and or source/destination port and allow these filters to be applied to interfaces. Considerations. None. 3.2. Select Traffic To the Device - Capability. It is possible to apply the filtering mechanism to traffic that is addressed directly to the device via any of its interfaces - including loopback interfaces. Supported Practices. - * Security Practices for Device Management - ([I-D.ietf-opsec-current-practices], Section 2.2.2) + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) * Security Practices for Software Upgrades and Configuration - Integrity/Validation ([I-D.ietf-opsec-current-practices], - Section 2.5.2) + Integrity/Validation ([RFC4778], Section 2.5.2) - * Management Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.2) + * Management Plane Filtering ([RFC4778], Section 2.7.2) Current Implementations. Many devices currently implement access control lists or filters that allow filtering based on protocol and/or source/destination address and or source/destination port and allow these filters to be applied to services offered by the device. Examples of this might include filters that permit only BGP from peers and SNMP and SSH from an authorized management segment and @@ -277,25 +270,23 @@ 3.3. Select Transit Traffic Capability. It is possible to apply the filtering mechanism to traffic that will transit the device via any of its interfaces. Supported Practices. - * Security Practices for Data Path - ([I-D.ietf-opsec-current-practices], Section 2.3.2) - * Data Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.1) + * Security Practices for Data Path ([RFC4778], Section 2.3.2) + * Data Plane Filtering ([RFC4778], Section 2.7.1) Current Implementations. Many devices currently implement access control lists or filters that allow filtering based on protocol and/or source/destination address and or source/destination port and allow these filters to be applied to the interfaces on the device in order to protect assets attached to the network. Examples of this may include filtering all traffic save SMTP (tcp/25) destined to a mail server. A common use of this today @@ -310,35 +301,32 @@ 3.4. Select Inbound and/or Outbound Capability. It is possible to filter both incoming and outgoing traffic on any interface. Supported Practices. - * Security Practices for Device Management - ([I-D.ietf-opsec-current-practices], Section 2.2.2) + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) - * Security Practices for Data Path - ([I-D.ietf-opsec-current-practices], Section 2.3.2) + * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration - Integrity/Validation ([I-D.ietf-opsec-current-practices], - Section 2.5.2) + Integrity/Validation ([RFC4778], Section 2.5.2) - * Data Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.1) + * Data Plane Filtering ([RFC4778], Section 2.7.1) + + * Management Plane Filtering ([RFC4778], Section 2.7.2) - * Management Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.2) Current Implementations. It might be desirable on a border router, for example, to apply an egress filter outbound on the interface that connects a site to its external ISP to drop outbound traffic that does not have a valid internal source address. Inbound, it might be desirable to apply a filter that blocks all traffic from a site that is known to forward or originate large amounts of junk mail. Considerations. @@ -350,35 +338,31 @@ 3.5. Select by Protocols Capability. The device provides a means to filter traffic based on the value of the protocol field in the IP header. Supported Practices. - * Security Practices for Device Management - ([I-D.ietf-opsec-current-practices], Section 2.2.2) + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) - * Security Practices for Data Path - ([I-D.ietf-opsec-current-practices], Section 2.3.2) + * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration - Integrity/Validation - ([I-D.ietf-opsec-current-practices],Section 2.5.2) + Integrity/Validation ([RFC4778],Section 2.5.2) - * Data Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.1) + * Data Plane Filtering ([RFC4778], Section 2.7.1) - * Management Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.2) + * Management Plane Filtering ([RFC4778], Section 2.7.2) Current Implementations. Some denial of service attacks are based on the ability to flood the victim with ICMP traffic. One quick way (admittedly with some negative side effects) to mitigate the effects of such attacks is to drop all ICMP traffic headed toward the victim. Considerations. @@ -382,44 +366,39 @@ Considerations. Being able to filter on protocol is necessary to allow implementation of policy, secure operations and for support of incident response. Filtering all traffic to a destination host is not often possible, business requirements will dictate that critical traffic be permitted if at all possible. 3.6. Select by Addresses - Capability. The device is able to control the flow of traffic based on source and/or destination IP address or blocks of addresses such as Classless Inter-Domain Routing (CIDR) blocks. Supported Practices. - * Security Practices for Device Management - ([I-D.ietf-opsec-current-practices], Section 2.2.2) + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) - * Security Practices for Data Path - ([I-D.ietf-opsec-current-practices], Section 2.3.2) + * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration - Integrity/Validation ([I-D.ietf-opsec-current-practices], - Section 2.5.2 + Integrity/Validation ([RFC4778], Section 2.5.2 - * Data Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.1) + * Data Plane Filtering ([RFC4778], Section 2.7.1) - * Management Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.2) + * Management Plane Filtering ([RFC4778], Section 2.7.2) Current Implementations. One example of the use of address based filtering is to implement ingress filtering per [RFC2827] Considerations. The capability to filter on addresses and address blocks is a fundamental tool for establishing boundaries between different @@ -432,35 +411,30 @@ The filtering mechanism supports filtering based on the value(s) of any portion of the protocol headers for IP, ICMP, UDP and TCP by specifying fields by name (e.g., "protocol = ICMP") rather than bit- offset/length/numeric value (e.g., 72:8 = 1). It supports arbitrary header-based filtering (possibly using bit- offset/length/value) of all other protocols. Supported Practices. - * Security Practices for Device Management - ([I-D.ietf-opsec-current-practices], Section 2.2.2) - - * Security Practices for Data Path - ([I-D.ietf-opsec-current-practices], Section 2.3.2) + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) + * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration - Integrity/Validation ([I-D.ietf-opsec-current-practices], - Section 2.5.2) + Integrity/Validation ([RFC4778], Section 2.5.2) - * Data Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.1) + * Data Plane Filtering ([RFC4778], Section 2.7.1) - * Management Plane Filtering ([I-D.ietf-opsec-current-practices], - Section 2.7.2) + * Management Plane Filtering ([RFC4778], Section 2.7.2) Current Implementations. This capability implies that it is possible to filter based on TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and ICMP type and code fields. One common example is to reject "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit set+ACK,FIN and RST bits clear). Another common example is the ability to control what services are allowed in/out of a network. It may be desirable to only allow inbound @@ -484,22 +458,21 @@ Capability. The device provides a mechanism to allow the specification of the action to be taken when a filter rule matches. Actions include "permit" (allow the traffic), "reject" (drop with appropriate notification to sender), and "drop" (drop with no notification to sender). Supported Practices. - * Data Origin Authentication ([I-D.ietf-opsec-current-practices], - Section 2.3.3) + * Data Origin Authentication ([RFC4778], Section 2.3.3) Current Implementations. Assume that your management devices for deployed networking devices live on several subnets, use several protocols, and are controlled by several different parts of your organization. There might exist a reason to have disparate policies for access to the devices from these parts of the organization. Actions such as "permit", "reject", and "drop" are essential in @@ -527,21 +501,21 @@ actions include "transmit" (permit the traffic because it's below the specified limit), "limit" (limit traffic because it exceeds the specified limit). Limits should be applicable by both bits per second and packets per timeframe (possible timeframes might include second, minute, hour). Limits should able to be placed in both inbound and outbound directions. Supported Practices. * Denial of Service Tracking/Tracing with Rate Limiting - ([I-D.ietf-opsec-current-practices], Section 2.8.4) + ([RFC4778], Section 2.8.4) Current Implementations. Assume that your management devices for deployed networking devices live on several subnets, use several protocols, and are controlled by several different parts of your organization. There might exist a reason to have disparate policies for access to the devices from these parts of the organization with respect to priority access to these services. Rate Limits may be used to enforce these prioritizations. @@ -565,29 +539,27 @@ Capability. It is possible to log all filter actions. The logging capability is able to capture at least the following data: * permit/reject/drop status * source and destination IP address * source and destination ports (if applicable to the protocol) - * which network element received or was sending the packet (interface, MAC address or other layer 2 information that identifies the previous hop source of the packet). Supported Practices. - * Logging Security Practices([I-D.ietf-opsec-current-practices], - Section 2.6.2) + * Logging Security Practices([RFC4778], Section 2.6.2) Current Implementations. Actions such as "permit", "reject", "drop" are essential in defining the security policy for the services offered by the network devices. Auditing the frequency, sources and destinations of these attempts is essential for tracking ongoing issues today. Considerations. @@ -600,22 +572,21 @@ syslog or other similar network logging mechanism. 4.4. Specify Log Granularity Capability. It is possible to enable/disable logging on a per rule basis. Supported Practices. - * Logging Security Practices([I-D.ietf-opsec-current-practices], - Section 2.6.2) + * Logging Security Practices([RFC4778], Section 2.6.2) Current Implementations. If a filter is defined that has several rules, and one of the rules denies telnet (tcp/23) connections, then it should be possible to specify that only matches on the rule that denies telnet should generate a log message. Considerations. @@ -816,23 +787,23 @@ that may be important in certain operational environments. Finally, if key infrastructure devices crash or experience severe performance degradation when filtering under heavy load, or even have the reputation of doing so, it is likely that security personnel will be forbidden, by policy, from using filtering in ways that would otherwise be appropriate for fear that it might cause unnecessary service disruption. 7. Additional Operational Practices - This section describes practices not covered in - [I-D.ietf-opsec-current-practices]. They are included here to - provide justification for capabilities that reference them. + This section describes practices not covered in [RFC4778]. They are + included here to provide justification for capabilities that + reference them. 7.1. Profile Current Traffic This capability allows a network operator to monitor traffic across an active interface in the network at a minimal level. This helps to determine probable cause for interface or network problems. The ability to separate and distinguish traffic at a layer-3 or layer-4 level allows the operator to characterize beyond simple interface counters the traffic in question. This is critical because @@ -874,112 +845,100 @@ This enables the implementation of filters on whichever services are necessary. To the extent that filtering causes degradation, it may not be possible to apply filters that implement the appropriate policies. 8. Security Considerations General Security is the subject matter of this entire memo. The - capabilities listed cite practices in - [I-D.ietf-opsec-current-practices] that they are intended to - support. [I-D.ietf-opsec-current-practices] defines the threat - model, practices and lists justifications for each practice. + capabilities listed cite practices in [RFC4778] that they are + intended to support. [RFC4778] defines the threat model, + practices and lists justifications for each practice. 9. Non-normative References - [I-D.ietf-opsec-current-practices] - Kaeo, M., "Operational Security Current Practices", - draft-ietf-opsec-current-practices-04 (work in progress), - June 2006. - [I-D.lewis-infrastructure-security] Lewis, D., "Service Provider Infrastructure Security", draft-lewis-infrastructure-security-00 (work in progress), June 2006. [I-D.savola-rtgwg-backbone-attacks] Savola, P., "Backbone Infrastructure Attacks and - Protections", draft-savola-rtgwg-backbone-attacks-01 (work - in progress), June 2006. + Protections", draft-savola-rtgwg-backbone-attacks-03 (work + in progress), January 2007. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. + [RFC4778] Kaeo, M., "Operational Security Current Practices in + Internet Service Provider Environments", RFC 4778, + January 2007. + Appendix A. Acknowledgments The authors gratefully acknowledge the contributions of: o Merike Kaeo for help aligning these capabilities with supported practices - o The MITRE Corporation for supporting development of this document. - NOTE: The editor's affiliation with The MITRE Corporation is - provided for identification purposes only, and is not intended to - convey or imply MITRE's concurrence with, or support for, the - positions, opinions or viewpoints expressed by the editor. - Authors' Addresses Christopher L. Morrow UUNET Technologies 21830 UUNet Way Ashburn, Virginia 21047 U.S.A. Phone: +1 703 886 3823 Email: chris@uu.net George M. Jones - The MITRE Corporation - 7515 Colshire Drive, M/S WEST - McLean, Virginia 22102-7508 - U.S.A. Phone: +1 703 488 9740 - Email: gmjones@mitre.org + Email: gmj3871@pobox.com Vishwas Manral IP Infusion Ground Floor, 5th Cross Road, Off 8th Main Road Bangalore, 52 India Phone: +91-80-4113-1268 Email: vishwas@ipinfusion.com Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information