Network Working Group M. Kaeo Request for Comments: 4778 Double Shot Security, Inc. Category: Informational January 2007 Current Operational Security Practices in Internet Service Provider Environments Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Operational Security Impact from Threats . . . . . . . . . 5 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 2. Protected Operational Functions . . . . . . . . . . . . . . . 8 2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 8 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 10 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 18 2.5. Software Upgrades and Configuration Integrity/Validation . . . . . . . . . . . . . . . . . . . 22 2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 26 2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 29 2.8. Denial-of-Service Tracking/Tracing . . . . . . . . . . . . 30 3. Security Considerations . . . . . . . . . . . . . . . . . . . 32 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Normative References . . . . . . . . . . . . . . . . . . . 33 5.2. Informational References . . . . . . . . . . . . . . . . . 33 Appendix A. Protocol Specific Attacks . . . . . . . . . . . . . . 34 A.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 34 A.2. IPv4 Protocol-Based Attacks . . . . . . . . . . . . . . . 34 A.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 36
focuses solely on documenting currently deployed security mechanisms for layer 2 and layer 3 network infrastructure devices. Although primarily focused on IPv4, many of the same practices can (and should) apply to IPv6 networks. Both IPv4 and IPv6 network infrastructures are taken into account in this survey. RFC2828]. Every operational network is subject to a multitude of threat actions, or attacks, i.e., an assault on system security that derives from an intelligent act that is a deliberate attempt to evade security services, and violate the security policy of a system [RFC2828]. Many of the threats to a network infrastructure occur from an instantiation (or combination) of the following: Reconnaissance: An attack whereby information is gathered to ascertain the network topology or specific device information, which can be further used to exploit known vulnerabilities Man-In-The-Middle: An attack where a malicious user impersonates either the sender or recipient of a communication stream while inserting, modifying, or dropping certain traffic. This type of attack also covers phishing and session hijacks. Protocol Vulnerability Exploitation: An attack that takes advantage of known protocol vulnerabilities due to design or implementation flaws to cause inappropriate behavior. Message Insertion: This can be a valid message (it could be a reply attack, which is a scenario where a message is captured and resent at a later time). A message can also be inserted with any of the fields in the message being spoofed, such as IP addresses, port numbers, header fields, or even packet content. Flooding is also part of this threat instantiation. Message Diversion/Deletion: An attack where legitimate messages are removed before they can reach the desired recipient, or are re-directed to a network segment that is normally not part of the data path. Message Modification: This is a subset of a message insertion attack where a previous message has been captured and modified before being retransmitted. The message can be captured using a man-in-the-middle attack or message diversion.
Note that sometimes denial-of-service attacks are listed as separate categories. A denial-of-service is a consequence of an attack and can be the result of too much traffic (i.e., flooding), exploiting protocol exploitation, or inserting/deleting/diverting/modifying messages. RFC3552]. On-path vs Off-path Attacks In order for a datagram to be transmitted from one host to another, it generally must traverse some set of intermediate links and routers. Such routers are naturally able to read, modify, or remove any datagram transmitted along that path. This makes it much easier to mount a wide variety of attacks if you are on-path. Off-path hosts can transmit arbitrary datagrams that appear to come from any host but cannot necessarily receive datagrams intended for other hosts. Thus, if an attack depends on being able to receive data, off-path hosts must first subvert the topology in order to place themselves on-path. This is by no means impossible, but is not necessarily trivial [RFC3552]. A more subtle attack is one where the traffic-mirroring capability of a device is hijacked and the traffic is diverted to a compromised host since the network topology may not need to be subverted.
Insider vs Outsider Attacks An "insider attack" is initiated from inside a given security perimeter by an entity that is authorized to access system resources, but uses them in a way not approved by those who granted the authorization. An "outside attack" is initiated from outside the perimeter by an unauthorized or illegitimate user of the system. Deliberate Attacks vs Unintentional Events A deliberate attack is where a miscreant intentionally performs an assault on system security. However, there are also instances where unintentional events cause the same harm, yet are performed without malicious intent. Configuration errors and software bugs can be as devastating to network availability as any deliberate attack on the network infrastructure. The attack source can be a combination of any of the above, all of which need to be considered when trying to ascertain the impact any attack can have on the availability and reliability of the network. It is nearly impossible to stop insider attacks or unintentional events. However, if appropriate monitoring mechanisms are in place, these attacks can also be detected and mitigated as with any other attack source. The amount of effort it takes to identify and trace an attack is, of course, dependent on the resourcefulness of the attacker. Any of the specific attacks discussed further in this document will elaborate on malicious behavior, which are sourced by an "outsider" and are deliberate attacks. Some further elaboration will be given to the feasibility of passive vs active and on-path vs off-path attacks to show the motivation behind deploying certain security features.
Deception A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. Disruption A circumstance or event that interrupts or prevents the correct operation of system services and functions. A broad variety of attacks, collectively called denial of service attacks, threaten the availability of systems and bandwidth to legitimate users. Many such attacks are designed to consume machine resources, making it difficult or impossible to serve legitimate users. Other attacks cause the target machine to crash, completely denying service to users. Usurpation A circumstance or event that results in control of system services or functions by an unauthorized entity. Most network infrastructure systems are only intended to be completely accessible to certain authorized individuals. Should an unauthorized person gain access to critical layer 2/layer 3 infrastructure devices or services, they could cause great harm to the reliability and availability of the network. A complete description of threat actions that can cause these threat consequences can be found in [RFC2828]. Typically, a number of different network attacks are used in combination to cause one or more of the above-mentioned threat consequences. An example would be a malicious user who has the capability to eavesdrop on traffic. First, he may listen in on traffic for a while, doing reconnaissance work and ascertaining which IP addresses belong to specific devices, such as routers. Were this miscreant to obtain information, such as a router password sent in cleartext, he can then proceed to compromise the actual router. From there, the miscreant can launch various active attacks, such as sending bogus routing updates to redirect traffic or capture additional traffic to compromise other network devices. While this document enumerates which countermeasures ISPs are deploying today, a useful generic analysis of actual backbone infrastructure attacks and the appropriate countermeasures can be found in [RTGWG].
accessed which location and at what time. Most cardkey systems have a fail-back "master key" in case the card system is down. This "master key" usually has limited access and its use is also carefully logged (which should only happen if the card-key system is NOT online/functional). All console access is always password protected and the login time is set to time out after a specified amount of inactivity - typically between 3-10 minutes. The type of privileges that you obtain from a console login varies between separate vendor devices. In some cases you get initial basic access and need to perform a second authentication step to get more privileged access (i.e., enable or root). In other vendors, you get the more privileged access when you log into the console as root, without requiring a second authentication step. How ISPs manage these logins vary greatly, although many of the larger ISPs employ some sort of AAA mechanism to help automate privilege-level authorization and utilize the automation to bypass the need for a second authentication step. Also, many ISPs define separate classes of users to have different privileges while logged onto the console. Typically, all console access is provided via an out-of-band (OOB) management infrastructure, which is discussed in Section 2.2 of this document.
o Auditing/Logging - All access to the physical locations of the infrastructure equipment is logged via electronic card-key systems. All console access is logged (refer to Section 2.2 of this document for more details). o DoS Mitigation - Not applicable. Section 2.2 of this document. The physical and logical authentication and logging systems should be run independently of each other and should reside in different physical locations. These systems need to be secured to ensure that they themselves will not be compromised, which could give the intruder valuable authentication and logging information. Social engineering plays a big role in many physical access compromises. Most ISPs have set up training classes and awareness programs to educate company personnel to deny physical access to people who are not properly authenticated or authorized to have physical access to critical infrastructure devices.
disabled. Note that file transfer protocols (TFTP, FTP, and SCP) will be covered in Section 2.5 of this document.
Each individual user in the AAA database is configured with specific authorization capability. Specific commands are either individually denied or permitted, depending on the capability of the device to be accessed. Multiple privilege levels are deployed. Most individuals are authorized with basic authorization to perform a minimal set of commands, while a subset of individuals are authorized to perform more privileged commands. Securing the AAA server is imperative and access to the AAA server itself is strictly controlled. When an individual leaves the company, his/her AAA account is immediately deleted and the TACACS/RADIUS shared secret is reset for all devices. Some management functions are performed using command line interface (CLI) scripting. In these scenarios, a dedicated user is used for the identity in scripts that perform CLI scripting. Once authenticated, these scripts control which commands are legitimate, depending on authorization rights of the authenticated individual. SSH is always used for virtual terminal access to provide for an encrypted communication channel. There are exceptions due to equipment limitations which are described in the additional considerations section. If SNMP is used for management, it is for read queries only and restricted to specific hosts. If possible, the view is also restricted to only send the information that the management station needs, rather than expose the entire configuration file with the read-only SNMP community. The community strings are carefully chosen to be difficult to crack and there are procedures in place to change these community strings between 30-90 days. If systems support two SNMP community strings, the old string is replaced by first configuring a second, newer community string and then migrating over from the currently used string to the newer one. Most large ISPs have multiple SNMP systems accessing their routers so it takes more then one maintenance period to get all the strings fixed in all the right systems. SNMP RW is not used and is disabled by configuration. Access control is strictly enforced for infrastructure devices by using stringent filtering rules. A limited set of IP addresses are allowed to initiate connections to the infrastructure devices and are specific to the services to which they are to limited (i.e., SSH and SNMP). All device management access is audited and any violations trigger alarms that initiate automated email, pager, and/or telephone notifications. AAA servers keep track of the authenticated entity as well as all the commands that were carried out on a specific device. Additionally, the device itself logs any access control violations (i.e., if an SSH request comes in from an IP address that is not
explicitly permitted, that event is logged so that the offending IP address can be tracked down and investigations made as to why it was trying to access a particular infrastructure device) RFC2827] and BCP84 [RFC3704] guidelines (discussed in Section 2.5), then the risk of spoofing is mitigated, barring a compromised internal system. Also, using SSH for device access ensures that no one can spoof the traffic during the SSH session. o Access Control - Management traffic is filtered to allow only specific IP addresses to have access to the infrastructure devices. o Data Integrity - Using SSH provides data integrity and ensures that no one has altered the management data in transit. o Data Confidentiality - Using SSH provides data confidentiality. o Auditing/Logging - Using AAA provides an audit trail for who accessed which device and which operations were performed. o DoS Mitigation - Using packet filters to allow only specific IP addresses to have access to the infrastructure devices. This limits but does not prevent spoofed DoS attacks directed at an infrastructure device. However, the risk is lowered by using a separate physical network for management purposes.
RFC2827] and BCP84 [RFC3704] guidelines for ingress filtering. BCP38 recommends filtering ingress packets with obviously spoofed and/or 'reserved' source addresses to limit the effects of denial-of-service attacks, while BCP84 extends the recommendation for multi-homed environments. Filters are also used to help alleviate issues between service providers. Without any filtering, an inter-exchange peer could steal transit just by using static routes, and essentially redirect data traffic. Therefore, some ISPs have implemented ingress/egress filters that block unexpected source and destination addresses not defined in the above-mentioned documents. Null routes and black-hole triggered routing [RFC3882] are used to deter any detected malicious traffic streams. These two techniques are described in more detail in Section 2.8 below. Most ISPs consider layer 4 filtering useful, but it is only implemented if performance limitations allow for it. Since it poses a large administrative overhead and ISPs are very much opposed to acting as the Internet firewall, Layer 4 filtering is typically
implemented as a last option. Netflow is used for tracking traffic flows, but there is some concern whether sampling is good enough to detect malicious behavior. Unicast Reverse Path Forwarding (RPF) is not consistently implemented. Some ISPs are in the process of doing so, while other ISPs think that the perceived benefit of knowing that spoofed traffic comes from legitimate addresses are not worth the operational complexity. Some providers have a policy of implementing uRPF at link speeds of Digital Signal 3 (DS3) and below, which was due to the fact that all hardware in the network supported uRPF for DS3 speeds and below. At higher-speed links, the uRPF support was inconsistent and it was easier for operational people to implement a consistent solution. BCP38, BCP84, and uRPF are deployed at network edges it can ensure that any spoofed traffic comes from at least a legitimate IP address and can be tracked. o Access Control - IP address filtering and layer 4 filtering is used to deny forbidden protocols and limit traffic destined for infrastructure device itself. Filters are also used to block unexpected source/destination addresses. o Data Integrity - Not applicable. o Data Confidentiality - Not applicable. o Auditing/Logging - Filtering exceptions are logged for potential attack traffic. o DoS Mitigation - Black-hole triggered filtering and rate-limiting are used to limit the risk of DoS attacks.
Rate limiting is used by some ISPs, although other ISPs believe it is not really useful, since attackers are not well-behaved and it doesn't provide any operational benefit over the complexity. Some ISPs feel that rate limiting can also make an attacker's job easier by requiring the attacker to send less traffic to starve legitimate traffic that is part of a rate limiting scheme. Rate limiting may be improved by developing flow-based rate-limiting capabilities with filtering hooks. This would improve the performance as well as the granularity over current capabilities. Lack of consistency regarding the ability to filter, especially with respect to performance issues, cause some ISPs not to implement BCP38 and BCP84 guidelines for ingress filtering. One such example is at edge boxes, where up to 1000 T1s connecting into a router with an OC-12 (Optical Carrier) uplink. Some deployed devices experience a large performance impact with filtering, which is unacceptable for passing customer traffic through, though ingress filtering (uRPF) might be applicable at the devices that are connecting these aggregation routers. Where performance is not an issue, the ISPs make a tradeoff between management versus risk.
party or cause legitimate traffic to never reach its intended destination. RFC3682] (sometimes also referred to as the TTL-Hack). The GTSM feature is used for protocols such as the Border Gateway Protocol (BGP), and makes use of a packet's Time To Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating peers. If GTSM is used, it is typically deployed only in limited scenarios between internal BGP peers due to lack of consistent support between vendor products and operating system versions. Packet filters are used to limit which systems can appear as a valid peer, while route filters are used to limit which routes are believed to be from a valid peer. In the case of BGP routing, a variety of policies are deployed to limit the propagation of invalid routing information. These include: incoming and outgoing prefix filters for BGP customers, incoming and outgoing prefix filters for peers and upstream neighbors, incoming AS-PATH filter for BGP customers, outgoing AS-PATH filter towards peers and upstream neighbors, route dampening and rejecting selected attributes and communities. Consistency between these policies varies greatly and there is a definite distinction whether the other end is an end-site vs an internal peer vs another big ISP or customer. Mostly ISPs do prefix-filter their end-site customers, but due to the operational constraints of maintaining large prefix filter lists, many ISPs are starting to depend on BGP AS-PATH filters to/from their peers and upstream neighbors. In cases where prefix lists are not used, operators often define a maximum prefix limit per peer to prevent misconfiguration (e.g., unintentional de-aggregation or neighbor routing policy mis-configuration) or overload attacks. ISPs need to coordinate with each other what the expected prefix exchange is, and increase this number by some sane amount. It is important for ISPs to pad the max-prefix number enough to allow for valid swings in routing announcements, preventing an unintentional shut down of the BGP session. Individual implementation amongst ISPs are unique, and depending on equipment supplier(s), different implementation options
are available. Most equipment vendors offer implementation options ranging from just logging excessive prefixes being received, to automatically shutting down the session. If the option of reestablishing a session after some pre-configured idle timeout has been reached is available, it should be understood that automatically reestablishing the session may potentially introduce instability continuously into the overall routing table if a policy mis-configuration on the adjacent neighbor is causing the condition. If a serious mis-configuration on a peering neighbor has occurred, then automatically shutting down the session and leaving it shut down until being manually cleared, is sometimes best and allows for operator intervention to correct as needed. Some large ISPs require that routes be registered in an Internet Routing Registry (IRR), which can then be part of the Routing Assets Database (RADb) - a public registry of routing information for networks in the Internet that can be used to generate filter lists. Some ISPs, especially in Europe, require registered routes before agreeing to become an eBGP peer with someone. Many ISPs also do not propagate interface IP addresses to further reduce attack vectors on routers and connected customers.
o DoS Mitigation - Many DoS attacks are mitigated using a combination of techniques including: MD5 authentication, the GTSM feature, filtering routing advertisements to bogons, and filtering routing advertisements to one's own network.
Active attacks are possible for both on-path and off-path scenarios. For on-path active attacks, the situation is the same as for a passive attack, where either a device has to already be compromised or a device can be inserted into the path. For off-path active attacks, the attacks are generally limited to message insertion or modification where the attacker may wish to load illegal software or configuration files to an infrastructure device. Note that similar issues are relevant when software updates are downloaded from a vendor site to an ISPs network management system that is responsible for software updates and/or configuration information.
hang and become inoperable. Spoofed configuration files can be hard to detect, especially when the only added command is to allow a miscreant access to that device by entering a filter allowing a specific host access and configuring a local username/password database entry for authentication to that device.
Filters are used to limit access to uploading/downloading configuration files and system images to specific IP addresses and protocols. The software images perform Cyclic Redundancy Checks (CRC) and the system binaries use the MD5 algorithm to validate integrity. Many ISPs expressed interest in having software image integrity validation based on the MD5 algorithm for enhanced security. In all configuration files, most passwords are stored in an encrypted format. Note that the encryption techniques used in varying products can vary and that some weaker encryption schemes may be subject to off-line dictionary attacks. This includes passwords for user authentication, MD5-authentication shared secrets, AAA server shared secrets, NTP shared secrets, etc. For older software that may not support this functionality, configuration files may contain some passwords in readable format. Most ISPs mitigate any risk of password compromise by either storing these configuration files without the password lines or by requiring authenticated and authorized access to the configuration files that are stored on protected OOB management devices. Automated security validation is performed on infrastructure devices using Network Mapping (Nmap) and Nessus to ensure valid configuration against many of the well-known attacks.
o Data Confidentiality - If the SCP protocol is used then there is confidentiality of the downloaded/uploaded configuration files and system images. o Auditing/Logging - All access and activity relating to downloading/uploading system images and configuration files are logged via AAA services and filter exception rules. o DoS Mitigation - A combination of filtering and CRC-check/ MD5-based integrity checks are used to mitigate the risks of DoS attacks. If the software updates and configuration changes are performed via an OOB management system, this is also added protection.
addresses and layer 4 port numbers as well as a timestamp. The syslog protocol is used to transfer the logged data between the infrastructure device to the syslog server. Many ISPs use the OOB management network to transfer syslog data since there is virtually no security performed between the syslog server and the device. All ISPs have multiple syslog servers - some ISPs choose to use separate syslog servers for varying infrastructure devices (i.e., one syslog server for backbone routers, one syslog server for customer edge routers, etc.) The timestamp is derived from NTP, which is generally configured as a flat hierarchy at stratum1 and stratum2 to have less configuration and less maintenance. Consistency of configuration and redundancy is the primary goal. Each router is configured with several stratum1 server sources, which are chosen to ensure that proper NTP time is available, even in the event of varying network outages. In addition to logging filtering exceptions, the following is typically logged: routing protocol state changes, all device access (regardless of authentication success or failure), all commands issued to a device, all configuration changes, and all router events (boot-up/flaps). The main function of any of these log messages is to see what the device is doing as well as to try and ascertain what certain malicious attackers are trying to do. Since syslog is an unreliable protocol, when routers boot or lose adjacencies, not all messages will get delivered to the remote syslog server. Some vendors may implement syslog buffering (e.g., buffer the messages until you have a route to the syslog destination), but this is not standard. Therefore, operators often have to look at local syslog information on a device (which typically has very little memory allocated to it) to make up for the fact that the server-based syslog files can be incomplete. Some ISPs also put in passive devices to see routing updates and withdrawals and do not rely solely on the device for log files. This provides a backup mechanism to see what is going on in the network in the event that a device may 'forget' to do syslog if the CPU is busy. The logs from the various syslog server devices are generally transferred into databases at a set interval that can be anywhere from every 10 minutes to every hour. One ISP uses Rsync to push the data into a database, and then the information is sorted manually by someone SSH'ing to that database.
than 5% of an offered load. This is largely due to the large amounts of DoS traffic, which continually requires investigation and mitigation. At last count, the number of hosts making up large distributed DoS botnets exceeded 1 million hosts. New techniques are continually evolving to automate the process of detecting DoS sources and mitigating any adverse effects as quickly as possible. At this time, ISPs are using a variety of mitigation techniques including: sinkhole routing, black hole triggered routing, uRPF, rate limiting, and specific control plane traffic enhancements. Each of these techniques will be detailed below. http://www.nanog.org/mtg-0402/pdf/morrow.pdf). Note that this black-holing technique may actually fulfill the goal of the attacker if the goal was to instigate black-holing traffic that appeared to come from a certain site. On the other hand, this black hole technique can decrease the collateral damage caused by an overly large attack aimed at something other than critical services.
incoming interface. Loose mode uRPF is not as specific and the incoming packet is accepted if there is any route in the routing table for the source address. While BCP84 [RFC3704] and a study on uRPF experiences [BCP84-URPF] detail how asymmetry, i.e., multiple routes to the source of a packet, does not preclude applying feasible paths strict uRPF, it is generally not used on interfaces that are likely to have routing asymmetry. Usually for the larger ISPs, uRPF is placed at the customer edge of a network.
[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. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004. [BCP84-URPF] Savola, P., "Experiences from Using Unicast RPF", Work in Progress, November 2006. [ICMPv6] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", Work in Progress, July 2006. [RTGWG] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, July 2006.
http://www-src.lip6.fr/homepages/ Fabrice.Legond-Aubry/www.ouah.org/fragma.html. o IP ToS field (or the Differentiated Services (DSCP) field) can be used to reroute or reclassify traffic based on specified precedence. o IP checksum field has been used for scanning purposes, for example when some firewalls did not check the checksum and allowed an attacker to differentiate when the response came from an end- system, and when from a firewall. o IP TTL field can be used to bypass certain network-based intrusion detection systems and to map network behavior.
Full Copyright Statement 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, 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 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.