OPSECNetwork Working Group M. KaeoInternet-DraftRequest for Comments: 4778 Double Shot Security, Inc.Intended status:Category: InformationalAugust 29, 2006 Expires: March 2,January 2007 Current Operational SecurityCurrentPracticesdraft-ietf-opsec-current-practices-07in Internet Service Provider Environments Status ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2, 2007.this memo is unlimited. Copyright Notice Copyright (C) TheInternet Society (2006).IETF Trust (2007). Abstract This 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .32 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .32 1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Operational Security Impact from Threats . . . . . . . . .65 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 2. Protected Operational Functions . . . . . . . . . . . . . . .98 2.1. Device Physical Access . . . . . . . . . . . . . . . . . .98 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . .1110 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . .1716 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . .1918 2.5. Software Upgrades and ConfigurationIntegrity / Validation . .Integrity/Validation . . . . . . . . . . . . . . . . . . .. . . 2322 2.6. Logging Considerations . . . . . . . . . . . . . . . . . .2726 2.7. Filtering Considerations . . . . . . . . . . . . . . . . .3029 2.8.Denial of Service Tracking / TracingDenial-of-Service Tracking/Tracing . . . . . . . . . . . .3130 3. Security Considerations . . . . . . . . . . . . . . . . . . .3432 4.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 5.Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .36 6.32 5. References . . . . . . . . . . . . . . . . . . . . . . . . . .37 6.1.33 5.1. Normative References . . . . . . . . . . . . . . . . . . .37 6.2.33 5.2. Informational References . . . . . . . . . . . . . . . . .3733 Appendix A. Protocol Specific Attacks . . . . . . . . . . . . . .3934 A.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . .3934 A.2. IPv4Protocol BasedProtocol-Based Attacks . . . . . . . . . . . . . . .3934 A.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . .41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 4336 1. Introduction Security practices are well understood by the network operators whohavehave, for manyyearsyears, gone through the growing pains of securing their network infrastructures. However, there does not exist a written document that enumerates these security practices. Network attacks are continually increasing and although it is not necessarily the role of an ISP to act as the Internet police, each ISP has to ensure that certain security practices are followed to ensure that their network is operationally available for their customers. This document is the result of a survey conducted to find out what current security practices are being deployed to secure network infrastructures. 1.1. Scope The scope for this survey is restricted to security practices that mitigate exposure to risks with the potential to adversely impact network availability and reliability. Securing the actual data traffic is outside the scope of the conducted survey. This document 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. 1.2. Threat Model A threat is a potential for a security violation, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm [RFC2828]. Every operational network is subject to a multitude of threat actions, or attacks,i.e.i.e., an assault on system security that derives from an intelligent act that is a deliberate attempt to evade securityservicesservices, 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 deviceinformationinformation, 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,modifyingmodifying, or dropping certain traffic. This type of attack also covers phishing and session hijacks. Protocol Vulnerability Exploitation: An attackwhichthat takes advantage of known protocol vulnerabilities due to design or implementation flaws to cause inappropriate behavior. Message Insertion: This can be a valid message(which(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 beingOspoofedO,spoofed, such as IP addresses, port numbers, headerfieldsfields, 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 desiredrecipientrecipient, or arere- directedre-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 capturedbyusing aman-in-the- middleman-in-the-middle attack or message diversion. Note that sometimesDenial of servicedenial-of-service attacks are listed as separate categories. Adenial of servicedenial-of-service is a consequence of an attack and can be the result of too much traffic(i.e.(i.e., flooding),orexploiting protocolexploitationexploitation, or inserting/deleting/diverting/modifying messages. 1.3. Attack Sources These attacks can be sourced in a variety of ways: Active vspassive attacksPassive Attacks An active attack involves writing data to the network. It is common practice in active attacks to disguise one's address and conceal the identity of the traffic sender. A passive attack involves only reading information off the network. This is possible if the attacker has control of a host in the communications path between two victimmachinesmachines, or has compromised the routing infrastructure to specifically arrange that traffic pass through a compromised machine. There are also situations where mirrored traffic (often used for debugging, performancemonitoringmonitoring, or accounting purposes) is diverted to a compromisedmachinemachine, which would not necessarily subvert any existingtopologytopology, and could be harder to detect. In general, the goal of a passive attack is to obtain information that the sender and receiver would prefer to remainprivate. [RFC3552]private [RFC3552]. On-path vsoff-path attacksOff-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 anyhostshost 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 meansimpossibleimpossible, but is not necessarilytrivial. [RFC3552]trivial [RFC3552]. A more subtle attack is one where thetraffic mirroringtraffic-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. Insideror outsider attacksvs Outsider Attacks An "insider attack" isone which isinitiated from inside a given securityperimeter,perimeter by an entity that is authorized to access systemresourcesresources, but uses them in a way not approved by those who granted the authorization. An "outside attack" is initiated from outside theperimeter,perimeter by an unauthorized or illegitimate user of the system. DeliberateattacksAttacks vsunintentional eventsUnintentional Events A deliberate attack isonewhere a miscreant intentionally performs an assault on system security. However, there are also instances where unintentional events cause the sameharmharm, yet are performed withoutmalice in mind.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 ascertainwhatthe 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 attackisis, ofcoursecourse, dependent on the resourcefulness of the attacker. Any of the specific attacks discussed further in this document will elaborate on maliciousbehaviorbehavior, 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 vsoff- pathoff-path attacks to show the motivation behind deploying certain security features. 1.4. Operational Security Impact from Threats The main concern for any of the potential attack scenarios is the impact and harm it can cause to the network infrastructure. The threat consequences are the security violationswhichthat results from a threat action,i.e.i.e., an attack. These are typically classified as follows: (Unauthorized) Disclosure A circumstance or event whereby an entity gains access to data for which the entity is not authorized. 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 layer2 / layer2/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 theabove mentionedabove-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 awhile to do somewhile, doing reconnaissance work andascertainascertaining which IP addressesbelongedbelong to specificdevicesdevices, such as routers. Were this miscreant to obtaininformationinformation, such as a router password sent in cleartext, he can then proceed to compromise the actual router. From there, the miscreant can launch various activeattacksattacks, 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]. 1.5. Document Layout This document is a survey of current operational practices that mitigate the risk of being susceptible to any threat actions. As such, the main focus is on the currently deployed security practices used to detect and/or mitigate attacks. The top-level categories in this document are based on operational functions for ISPs and generally relate to what is to be protected. This is followed by a description of which attacks are possible and the security practices currentlydeployed whichdeployed. This will provide the necessary security services to help mitigate these attacks. These security services are classifiedas:as follows: o User Authentication o User Authorization o Data Origin Authentication o Access Control o Data Integrity o Data Confidentiality oAuditing / LoggingAuditing/Logging o DoS Mitigation In many instances, a specific protocol currently deployed will offer a combination of these services. For example,AAAAuthentication, Authorization, and Accounting (AAA) can offer user authentication, userauthorizationauthorization, andaudit / logging servicesaudit/logging services, whileSSHthe Secure SHell (SSH) Protocol can provide data origin authentication, dataintegrityintegrity, and data confidentiality. The services offered are more important than the actual protocol used. Note that access control will refer basically to logical access control,i.e.i.e., filtering. Each section ends with an additional considerations sectionwhichthat explains why specific protocols may or may not beusedused, and also gives some information regardingcapabilitiescapabilities, which are not possible today due to bugs or lack ofease of use.usability. 2. Protected Operational Functions 2.1. Device Physical Access Device physical access pertains to protecting the physical location and access of the layer 2 or layer 3 network infrastructure device. Physical security is a large field of study/practice in and of itself, arguably the largest,oldestoldest, and mostwell understoodwell-understood area of security. Although it is important to have contingency plans for naturaldisastersdisasters, such as earthquakes andfloodsfloods, which can cause damage to networking devices, this isout-of-scope forout of the scope of this document.HereHere, we concern ourselves with protecting access to the physical location and how a device can be further protected from unauthorized access if the physical location has been compromised,i.ei.e., protecting the console access. This is aimed largely at stopping an intruder with physical access from gaining operational control of the device(s). Note that nothing will stop an attacker with physical access from effecting adenial of servicedenial-of-service attack, which can be easily accomplished by powering off the device or just unplugging some cables. 2.1.1.Threats / AttacksThreats/Attacks If any intruder gets physical access to a layer 2 or layer 3 device, the entire network infrastructure can be under the control of the intruder. At a minimum, the intruder can take the compromised deviceout-of-service,out of service, causing network disruption, the extent of which depends on the network topology. A worse scenario is where the intrudercan useuses this device to crack the consolepassword and havepassword, gaining complete control of thedevice, perhapsdevice (perhaps without anyone detecting such a compromise, or to attach another network device onto a port and siphon off data with which the intruder can ascertain the networktopologytopology) andtake control ofthe entire network. The threat of gaining physical access can be realized in a variety ofwaysways, even if critical devices are underhigh-security. Therehigh security. Cases still occurcaseswhere attackers have impersonated maintenance workers to gain physical access to critical devices that have caused major outages and privacy compromises. Insider attacks from authorized personnel also pose a real threat and must be adequately recognized anddealt with.addressed. 2.1.2. Security Practices For physical device security, equipment is kept in highly restrictive environments. Only authorized users withcardkeycard-key badges have access to any of the physical locations that contain critical network infrastructure devices. Thesecardkeycard-key systems keep track of who accessed which location and at what time. Most cardkey systems have afail backfail-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 thecardkeycard-key system is NOTonline/ functional).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(i.e.access (i.e., enable orroot) access.root). In othervendorsvendors, 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 varygreatlygreatly, although many of the larger ISPs employ some sort of AAA mechanism to help automateprivilege levelprivilege-level authorization andcanutilize 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.TypicallyTypically, all console access is provided via an out-of-band (OOB) managementinfrastructureinfrastructure, which is discussed inthe section on OOB management.Section 2.2 of this document. 2.1.3. Security Services The following security services are offered through the use of the practices described in the previous section: o User Authentication - All individuals who have access to the physical facility are authenticated. Console access is authenticated. o User Authorization - An authenticated individual has implicit authorization to perform commands on the device. In somecasescases, multiple authentication is required to differentiate between basic and more privileged access. o Data Origin Authentication - Notapplicableapplicable. o Access Control - Notapplicableapplicable. o Data Integrity - Notapplicableapplicable. o Data Confidentiality - Notapplicableapplicable. oAuditing / LoggingAuditing/Logging - All access to the physical locations of the infrastructure equipment is logged via electronic card-key systems. All console access is logged (refer tothe OOB management sectionSection 2.2 of this document for moredetails)details). o DoS Mitigation - Notapplicableapplicable. 2.1.4. Additional Considerations Physical security is relevant to operational security practices as described in thisdocumentdocument, mostly from aconsole accessconsole-access perspective. Most ISPs provide console access via an OOB managementinfrastructureinfrastructure, which is discussed inthe OOB management sectionSection 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 becompromisedcompromised, 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. 2.2. Device Management - In-Band and Out-of-Band (OOB) In-band management is generally considered to be deviceaccessaccess, where the control traffic takes the same data path as the datawhichthat traverses the network. Out-of-band management is generally considered to be deviceaccessaccess, where the control traffic takes a separate path as the datawhichthat traverses the network. In many environments, device management for layer 2 and layer 3 infrastructure devices is deployed as part of an out-of-band managementinfrastructureinfrastructure, although there are some instances where it is deployed in-band as well. Note that while many of the security concerns and practices are the same for OOB management and in-band management, most ISPs prefer an OOB managementsystemsystem, since access to the deviceswhichthat make up this management network are more vigilantly protected and considered to be less susceptible to malicious activity. Console access is always architected via an OOB network. Presently, the mechanisms used for either in-band management or OOB are via virtual terminal access(i.e.(i.e., Telnet or SSH),SNMP,Simple Network Management Protocol (SNMP), or HTTP. In all large ISPs that were interviewed, HTTP managementiswas never used andiswas explicitly disabled. Note that file transfer protocols (TFTP, FTP, and SCP) will be covered inthe 'Software Upgrades and Configuration Integrity/Validation' section.Section 2.5 of this document. 2.2.1.Threats / AttacksThreats/Attacks For device management, passive attacks are possible if someone has the capability to intercept data between the management device and the managed device. The threat is possible if a single infrastructure device is somehow compromised and can act as a networksniffersniffer, or if it is possible to insert a new devicewhichthat acts as a network sniffer. 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, where a topology subversion is required to reroute traffic and essentially bring the attacker on-path, the attack is generally limited to message insertion or modification. 2.2.1.1. Confidentiality Violations Confidentiality violations can occur when a miscreant intercepts any management data that has been sent in cleartext or with weak encryption. This includes interception of usernames and passwords with which an intruder can obtain unauthorized access to network devices. It can also include otherinformationinformation, such as logging or configurationinformationinformation, if an administrator is remotely viewing local logfiles or configuration information. 2.2.1.2. Offline Cryptographic Attacks If username/password information was encrypted but the cryptographic mechanism used made it easy to capture data and break the encryption key, the device management traffic could be compromised. The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user. 2.2.1.3. Replay Attacks For a replay attack to be successful, the management traffic would need to first be captured either on-path or diverted to an attacker to later be replayed to the intended recipient. 2.2.1.4. Message Insertion/Deletion/Modification Data can be manipulated by someone in control of intermediary hosts. Forging data is also possible with IP spoofing, where a remote host sends out packetswhichthat appear to come from another, trusted host. 2.2.1.5. Man-In-The-Middle A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent from a management system to the networking infrastructure device and traffic that is sent from the network infrastructure device to the management system. 2.2.2. Security Practices OOB management is done via a terminal server at each location. SSH access is used to get to the terminal server from where sessions to the devices are initiated. Dial-in access is deployed as a backup if the network is notavailable however,available. However, it is common to usedial-back,dial- back, encryptingmodemsmodems, and/or one-time-password (OTP) modems to avoid the security weaknesses of plain dial-in access. All in-band management and OOB management access to layer 2 and layer 3 devices is authenticated. The user authentication and authorization is typically controlled byaan AAA server(i.e. RADIUS(i.e., Remote Authentication Dial-in User Service (RADIUS) and/orTACACS+).Terminal Access Controller Access-Control System (TACACS+)). Credentials used to determine the identity of the user vary from static username/password to one-time username/passwordschemeschemes such as Secure-ID. Static username/passwords are expired after a specified period of time, usually 30 days. Every authenticated entity via AAA is an individual user for greater granularity of control. Note that often the AAA server used for OOB management authentication is a separate physical device from the AAA server used for in-band management user authentication. In some deployments, the AAA servers used for device management authentication/authorization/accounting are on separate networks to provide a demarcation for any other authentication functions. For backup purposes, there is often a single local database entry for authenticationwhichthat is known to a very limited set of key personnel. It is usually the highestprivilege levelprivilege-level username/password combination, which in most cases is the same across all devices. This local device password is routinely regenerated once every 2-3monthsmonths, and is also regenerated immediately after an employee who had access to that password leaves the company or is no longer authorized to have knowledge of that password. Each individual user in the AAA database is configured with specific authorization capability. Specific commands are either individually denied orpermittedpermitted, 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 ofcommandscommands, 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 arelegitimatelegitimate, 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 stationneedsneeds, rather than expose the entire configuration file with theread- onlyread-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 asecondsecond, 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 limitedto (i.e.(i.e., SSH and SNMP). All device management access is audited and any violations trigger alarmswhichthat initiate automated email,pagerpager, and/or telephone notifications. AAA serverskeepskeep 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.(i.e., if an SSH request comes in from an IP addresswhichthat 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) 2.2.3. Security Services The security services offered for device OOB management are nearly identical to those of device in-band management. Due to the critical nature of controlling and limiting device access, many ISPs feel that physically separating the management traffic from the normal customer data traffic will provide an added level of risk mitigation and limit the potential attack vectors. The following security services are offered through the use of the practices described in the previous section: o User Authentication - All individuals are authenticated via AAA services. o User Authorization - All individuals are authorized via AAA services to perform specific operations once successfully authenticated. o Data Origin Authentication - Management traffic is strictly filtered to allow only specific IP addresses to have access to the infrastructure devices. This does not alleviate risk the from spoofed traffic, although when combined with edge filtering using BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed inthe sectionSection 2.5), then the risk of spoofing ismitigatedmitigated, barring a compromised internal system. Also, using SSH for device access ensures thatnooneno 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. oAuditing / LoggingAuditing/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. 2.2.4. Additional Considerations Password selection for any device management protocol used is critical to ensure that the passwords are hard to guess or break using a brute-force attack.IPsecIP security (IPsec) is considered too difficult todeploydeploy, and the common protocol to provide for confidential management access is SSH. There are exceptions for using SSH due to equipment limitations since SSH may not be supported on legacy equipment. In somecasescases, changing thehostnamehost name of a device requires an SSH rekey event since the key is based on some combination of host name,MAC addressMessage Authentication Code (MAC) address, and time. Also, in the case where the SSH key is stored on a route processor card, a re-keying of SSH would be required whenever the route processor card needs to be swapped. Some providers feel that this operational impact exceeds the security necessary and instead use Telnet from trusted inside hosts (called 'jumphosts' or 'bastion hosts') to manage those devices. An individual would first SSH to the jumphost and then Telnet from the jumphost to the actual infrastructure device, fully understanding that any passwords will be sent in the clear between the jumphost and the device to which it isconnecting to.connecting. All authentication and authorization is still carried out using AAA servers. In instances where Telnet access is used, the logs on the AAA servers are more verbose and more attention is paid to them to detect any abnormal behavior. The jumphosts themselves are carefully controlled machines and usually have limited access. Note that Telnet is NEVER allowed to an infrastructure device except from specific jumphosts;i.e.i.e., packet filters are used at the console server and/or infrastructure device to ensure that Telnet is only allowed from specific IP addresses. With thousands of devices to manage, some ISPs have created automated mechanisms to authenticate to devices. As an example, Kerberos has been used to automate the authentication process for devices that have support for Kerberos. An individual would first log in to a Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. This 'ticket' is generally set to have a lifespan of 10 hours and is used to automatically authenticate the individual to the infrastructure devices. In instances where SNMP is used, some legacy devices only supportSNMPv1SNMPv1, which then requires the provider to mandate its use across all infrastructure devices for operational simplicity. SNMPv2 is primarily deployed since it is easier to set up than v3. 2.3. Data Path This section refers to how traffic is handledwhichthat traverses the network infrastructure device. The primary goal of ISPs is to forward customer traffic. However, due to the large amount of malicious traffic that can cause DoS attacks and render the network unavailable, specific measures are sometimes deployed to ensure the availability to forward legitimate customer traffic. 2.3.1.Threats / AttacksThreats/Attacks Any data traffic can potentially be attack traffic and the challenge is to detect and potentially stop forwarding any of the malicious traffic. The deliberately sourced attack traffic can consist of packets with spoofed source and/or destination addresses or any other malformed packetwhichthat mangle any portion of a header field to cause protocol-related security issues (such as resetting connections, causing unwelcome ICMP redirects, creating unwelcome IPoptionsoptions, or packet fragmentations). 2.3.2. Security Practices Filtering and rate limiting are the primary mechanism to provide risk mitigation of malicious traffic rendering the ISP services unavailable. However, filtering and rate limiting of data path traffic is deployed in a variety ofwaysways, depending on how automated the process is and what the capabilities and performance limitations of the existing deployed hardware are. The ISPswhichthat do not have performance issues with their equipment follow BCP38 [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 ofdenial of service attacksdenial-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, aninter- exchangeinter-exchange peer could steal transit just by using staticroutesroutes, and essentially redirect data traffic. Therefore, some ISPs have implemented ingress/egress filterswhichthat 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 insectionSection 2.8 below. Most ISPs consider layer 4 filteringusefuluseful, but it is only implemented if performance limitations allow for it.Layer 4 filtering is typically only when no other option exists sinceSince itdoes poseposes a large administrative overhead and ISPs are very much opposed to acting as the Internetfirewall.firewall, Layer 4 filtering is typically implemented as a last option. Netflow is used for tracking trafficflowsflows, but there is some concern whether sampling is good enough to detect malicious behavior. UnicastRPFReverse Path Forwarding (RPF) is not consistently implemented. Some ISPs are in the process of doingsoso, 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 ofDS3Digital Signal 3 (DS3) andbelowbelow, which was due to the fact that all hardware in the network supported uRPF for DS3 speeds and below. Athigher speed linkshigher-speed links, the uRPF support was inconsistent and it was easier for operational people to implement a consistent solution. 2.3.3. Security Services o User Authentication - Notapplicableapplicable. o User Authorization - Notapplicableapplicable. o Data Origin Authentication - When IP address filtering per BCP38,BCP84BCP84, 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 - Notapplicableapplicable. o Data Confidentiality - Notapplicableapplicable. oAuditing / LoggingAuditing/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. 2.3.4. Additional Considerations For layer 2 devices, MAC address filtering and authentication is not used in large-scale deployments. This is due to the problems it can cause when troubleshooting networking issues. Port security becomes unmanageable at a large scale where1000sthousands of switches are deployed. Rate limiting is used by someISPsISPs, although other ISPs believe it is not reallyusefuluseful, since attackers are notwell behavedwell-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 performanceissuesissues, cause some ISPstonot to implement BCP38 and BCP84 guidelines for ingress filtering. One such example is at edgeboxesboxes, whereyou haveup to 1000T1'sT1s connecting into a router with an OC-12 (Optical Carrier) uplink. Some deployed devices experience a large performance impact withfilteringfiltering, 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. 2.4. Routing Control Plane The routing control plane deals with all the trafficwhichthat is part of establishing and maintaining routing protocol information. 2.4.1.Threats / AttacksThreats/Attacks Attacks on the routing control plane can bebothfrom both passive or active sources. Passive attacks are possible if someone has the capability to intercept data between the communicating routing peers. This can be accomplished if a single routing peer is somehow compromised and can act as a networksniffersniffer, or if it is possible to insert a new devicewhichthat acts as a network sniffer. 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. This may lead to an attacker impersonating a legitimate routing peer and exchanging routing information. Unintentional active attacks are more common due to configuration errors, which cause legitimate routing peers to feed invalid routing information to other neighboring peers. For off-path active attacks, the attacks are generally limited to message insertion ormodificationmodification, which can divert traffic to illegitimatedestinations and causedestinations, causing traffic to never reach its intended destination. 2.4.1.1. Confidentiality Violations Confidentiality violations can occur when a miscreant intercepts any of the routing update traffic. This is becoming more of a concern because many ISPs are classifying addressing schemes and network topologies as private and proprietary information. It is also a concern because the routing protocol packets contain information that may show ways in which routing sessions could be spoofed or hijacked. This in turn could lead into a man-in-the-middleattackattack, where the miscreants can insert themselves into the traffic path or divert the traffic path and violate the confidentiality of user data. 2.4.1.2. Offline Cryptographic Attacks If any cryptographic mechanism was used to provide for data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data. The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user. Note that by using cryptographically protected routing information, the latter would require the cryptographic key to already be compromisedanywayanyway, so this attack is only feasible if a device was able to eavesdrop and capture the cryptographically protected routing information. 2.4.1.3. Replay Attacks For a replay attack to be successful, the routing control plane traffic would need to first be captured either on-path or diverted to an attacker to later be replayed to the intended recipient. Additionally, since many of these protocols include replay protection mechanisms, these would also need to besubvertedsubverted, if applicable. 2.4.1.4. Message Insertion/Deletion/Modification Routing control plane traffic can be manipulated by someone in control of intermediate hosts. In addition, traffic can be injected by forging IP addresses, where a remote router sends out packetswhichthat appear to come from another, trusted router. If enough traffic is injected to be processed by limited memoryroutersrouters, it can cause a DoS attack. 2.4.1.5. Man-In-The-Middle A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent from one routing peer to the other and communicates on behalf of one of the peers. This can lead to a diversion of the user traffic to either an unauthorized receiving party or cause legitimate traffic to never reach its intended destination. 2.4.2. Security Practices Securing the routing control plane takes manyfeaturesfeatures, which are generally deployed as a system.MD5Message Digest 5 (MD5) authentication is used by some ISPs to validate the sending peer and to ensure that the data in transit has not been altered. Some ISPs only deploy MD5 authentication atcustomer'sthe customers' request. Additional sanity checks to ensure with reasonable certainty that the received routing update was originated by a valid routing peer include route filters and the Generalized TTL Security Mechanism (GTSM) feature [RFC3682] (sometimes also referred to as the TTL-Hack). The GTSM feature is used for protocols such asBGPthe 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 typicallyonlydeployed 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 validpeerpeer, 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 doprefix- filterprefix-filter their end-sitecustomerscustomers, 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 policymis- configuration)mis-configuration) or overload attacks. ISPs need to coordinatebetweenwith each other what the expected prefix exchange is, and increase this number by some sane amount. It is important for ISPs to pad themax- prefixmax-prefix number enough to allow for valid swings in routingannouncements to preventannouncements, preventing an unintentionalshuttingshut down of the BGP session. Individual implementation amongst ISPs are unique, and depending on equipmentsupplier(s)supplier(s), different implementation options are available. Most equipment vendors offer implementation options ranging from just logging excessive prefixes beingreceivedreceived, 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 policymis- configurationmis-configuration on the adjacent neighbor is causing the condition. If a serious mis-configuration on a peering neighbor hasoccurredoccurred, then automatically shutting down the session and leaving it shut down until being manuallyclearedcleared, 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](IRR), which can then be part of theRADBRouting 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 ineurope,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. 2.4.3. Security Services o User Authentication - Notapplicableapplicable. o User Authorization - Notapplicableapplicable. o Data Origin Authentication - By using MD5 authentication and/or theTTL-hackTTL-hack, a routing peer can be reasonably certain that traffic originated from a valid peer. o Access Control - Route filters, AS-PATHfiltersfilters, and prefix limits are used to control access to specific parts of the network. o Data Integrity - By using MD5authenticationauthentication, a peer can be reasonably certain that the data has not been modified intransittransit, but there is no mechanism to prove the validity of the routing information itself. o Data Confidentiality - Notimplementedimplemented. o Auditing / Logging - Filter exceptions are logged. o DoS Mitigation - Many DoS attacks are mitigated using a combination of techniques including: MD5 authentication, the GTSM feature, filtering routing advertisements tobogonsbogons, and filtering routing advertisements to one's own network. 2.4.4. Additional Considerations So far the primary concern to secure the routing control plane has been to validate the sending peer and to ensure that the data in transit has not been altered. Although MD5 routing protocol extensions have beenimplementedimplemented, which can provide both services, they are not consistently deployed amongst ISPs. Two major deployment concerns have been implementationissuesissues, where both software bugs and the lack of graceful re-keying options have caused significant network down times. Also, some ISPs express concern that deploying MD5 authentication will itself be a worse DoS attack victim and prefer to use a combination of other risk mitigation mechanisms such as GTSM (for BGP) and route filters. An issue with GTSM is that it is not supported on all devices across differentvendors products'.vendors' products. IPsec is not deployed since the operational management aspects of ensuring interoperability and reliable configurations is too complex and time consuming to be operationally viable. There is also limited concern to the confidentiality of the routing information. The integrity and validity of the updates are of much greater concern. There is concern for manual or automatedactionsactions, which introduce new routes and can affect the entire routing domain. 2.5. Software Upgrades and ConfigurationIntegrity / ValidationIntegrity/Validation Software upgrades and configuration changes are usually performed as part of either in-band or OOB management functions. However, there are additional considerations to be taken intoaccountaccount, which are enumerated in this section. 2.5.1.Threats / AttacksThreats/Attacks Attacks performed on system software and configurations can be both from passive or active sources. Passive attacks are possible if someone has the capability to intercept data between the network infrastructure device and the system which is downloading or uploading the software or configuration information. This can be accomplished if a single infrastructure device is somehow compromised and can act as a networksniffersniffer, or if it is possible to insert a new devicewhichthat acts as a network sniffer. 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. 2.5.1.1. Confidentiality Violations Confidentiality violations can occur when a miscreant intercepts any of the software image or configuration information. The software image may give an indication of exploits which the device is vulnerable to while the configuration information can inadvertently lead attackers to identify critical infrastructure IP addresses and passwords. 2.5.1.2. Offline Cryptographic Attacks If any cryptographic mechanism was used to provide for data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data. The traffic would need to be captured either by eavesdropping on the communication path or by being able to divert traffic to a malicious user. 2.5.1.3. Replay Attacks For a replay attack to be successful, the software image or configuration file would need to first be captured either on-path or diverted to an attacker to later be replayed to the intended recipient. Additionally, since many protocols do have replay protection capabilities, these would have to be subverted as well in applicable situations. 2.5.1.4. Message Insertion/Deletion/Modification Software images and configuration files can be manipulated by someone in control of intermediate hosts. By forging an IP address and impersonating a valid host which can download software images or configuration files, invalid files can be downloaded to an infrastructure device. This can also be the case from trusted vendors who may unbeknownst to them have compromised trusted hosts. An invalid software image or configuration file can cause a device to 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. 2.5.1.5. Man-In-The-Middle A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent between the infrastructure device and the host used to upload/download the system image or configuration file.He/ sheHe/she can then act on behalf of one or both of these systems. If an attacker obtained a copy of the software image being deployed, he could potentially exploit a known vulnerability and gain access to the system. From a captured configuration file, he could obtain confidential network topologyinformationinformation, or even more damaginginformationinformation, if any of the passwords in the configuration file were not encrypted. 2.5.2. Security Practices Images and configurations are stored on specific hostswhichthat have limited access. All access and activity relating to these hosts are authenticated and logged via AAA services. When uploaded/downloading any system software or configuration files, either TFTP,FTPFTP, or SCP can be used. Where possible, SCP is used to secure the data transfer and FTP is generally never used. All SCP access is username/password authenticated but since this requires an interactive shell, most ISPs will use shared key authentication to avoid the interactive shell. While TFTP access does not have any security measures, it is still widelyusedused, especially in OOB management scenarios. Some ISPs implement IP-based restriction on the TFTPserverserver, while some custom written TFTP servers will support MAC-based authentication. TheMAC- basedMAC-based authentication is more common when using TFTP to bootstrap routers remotely. In mostenvironmentsenvironments, scripts are used for maintaining the images and configurations of a large number of routers. To ensure the integrity of the configurations, every hour the configuration files are polled and compared to the previously polled version to find discrepancies. In at least one environmentthesethese, tools are Kerberized to take advantage of automated authentication (not confidentiality). 'Rancid' is one popular publicly available tool for detecting configuration and system changes. Filters are used to limit access to uploading/downloading configuration files and system images to specific IP addresses and protocols. The software images performCRC-checksCyclic 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 softwarewhichthat 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 fileswhichthat are stored on protected OOB management devices. Automated security validation is performed on infrastructure devices usingnmapNetwork Mapping (Nmap) andnessusNessus to ensure valid configuration against many of the well-known attacks. 2.5.3. Security Services o User Authentication - All users are authenticated before being able to download/upload any system images or configuration files. o User Authorization - All authenticated users are granted specific privileges to download or upload system images and/or configuration files. o Data Origin Authentication - Filters are used to limit access to uploading/downloading configuration files and system images to specific IP addresses. o Access Control - Filters are used to limit access to uploading/ downloading configuration files and system images to specific IP addresses and protocols. o Data Integrity - All systems use either a CRC-check or MD5 authentication to ensure data integrity.AlsoAlso, tools such as rancid are used to automatically detect configuration changes. o Data Confidentiality - If the SCP protocol is used then there is confidentiality of the downloaded/uploaded configuration files and system images. oAuditing / LoggingAuditing/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 andCRC-check / MD5- basedCRC-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. 2.5.4. Additional Considerations Where the MD5 algorithm is not used to performdata integritydata-integrity checking of software images and configuration files, ISPs have expressed an interest in having this functionality. IPsec is considered too cumbersome and operationally difficult to use for data integrity and confidentiality. 2.6. Logging Considerations Although logging is part of all the previous sections, it is important enough to be covered as a separate item. The main issues revolve around what gets logged, how long are logskeptkept, and what mechanisms are used to secure the logged information while it is in transit and while it is stored. 2.6.1.Threats / AttacksThreats/Attacks Attacks on the logged data can be both from passive or active sources. Passive attacks are possible if someone has the capability to intercept data between the recipient logging server and the device from which the logged dataoriginated from.originated. This can be accomplished if a single infrastructure device is somehow compromised and can act as a networksniffersniffer, or if it is possible to insert a new devicewhichthat acts as a network sniffer. 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 becompromisedcompromised, or a device can be inserted into the path. For off-path active attacks, the attacks are generally limited to message insertion or modificationwhichthat can alter the logged data to keep any compromise from beingdetecteddetected, or to destroy any evidencewhichthat could be used for criminal prosecution. 2.6.1.1. Confidentiality Violations Confidentiality violations can occur when a miscreant intercepts any of the logging datawhichthat is in transit on the network. This could lead to privacy violations if some of the logged data has not been sanitized to disallow any data that could be a violation of privacy to be included in the logged data. 2.6.1.2. Offline Cryptographic Attacks If any cryptographic mechanism was used to provide for data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data. The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user. 2.6.1.3. Replay Attacks For a replay attack to be successful, the logging data would need to first be captured either on-path or diverted to an attacker and later replayed to the recipient. 2.6.1.4. Message Insertion/Deletion/Modification Logging data could be injected,deleteddeleted, or modified by someone in control of intermediate hosts. Logging data can also be injected by forging packets from either legitimate or illegitimate IP addresses. 2.6.1.5. Man-In-The-Middle A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent between the infrastructure device and the logging server or traffic sent between the logging server and the databasewhichthat is used to archive the logged data. Any unauthorized access to logging information could lead to the knowledge of private and proprietary network topologyinformationinformation, which could be used to compromise portions of the network. An additional concern is having access to logginginformationinformation, which could be deleted or modified so as to cover any traces of a security breach. 2.6.2. Security PracticesLoggingWhen it comes to filtering, logging is mostly performed on an exception auditing basiswhen it comes to filtering (i.e.(i.e., trafficwhichthat is NOT allowed is logged). This is to assure that the logging servers are not overwhelmed withdatadata, which would render most logs unusable. Typically the data logged will contain the source and destination IP 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.(i.e., one syslog server for backbone routers, one syslog server for customer edge routers, etc.) The timestamp is derived fromNTPNTP, 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 isavailableavailable, even in the event of varying network outages. In addition to logging filtering exceptions, the following is typically logged:Routingrouting protocol state changes, all device access (regardless of authentication success or failure), all commands issued to a device, all configurationchangeschanges, 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 syslogdestination)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 intervalwhichthat can be anywhere from every 10 minutes to every hour. One ISP uses Rsync to push the data into adatabasedatabase, and then the information is sorted manually by someone SSH'ing to that database. 2.6.3. Security Services o User Authentication - Notapplicableapplicable. o User Authorization - Notapplicableapplicable. o Data Origin Authentication - Notimplementedimplemented. o Access Control - Filtering on logging host and server IP address to ensure that syslog information only goes to specific syslog hosts. o Data Integrity - Notimplementedimplemented. o Data Confidentiality - Notimplementedimplemented. oAuditing / LoggingAuditing/Logging - This entire section deals with logging. o DoS Mitigation - An OOB management system is used and sometimes different syslog servers are used for logging information from varying equipment. Exception logging tries to keep information to a minimum. 2.6.4. Additional Considerations There is no security with syslog and ISPs are fully cognizant of this. IPsec is considered too operationally expensive and cumbersome to deploy. Syslog-ng and stunnel are being looked at for providing better authenticated andintegrity protectedintegrity-protected solutions. Mechanisms to prevent unauthorized personnel from tampering with logs is constrained to auditing who has access to the logging servers and files. ISPs expressed requirements for more than just UDP syslog. Additionally, they would like more granular and flexible facilities and priorities,i.e.i.e., specific logs to specific servers. Also, a common format for reporting standard events so thatthey don't have to modifymodifying parsers after each upgrade of a vendor device orsoftware.software is not necessary. 2.7. Filtering Considerations Although filtering has been covered under many of the previous sections, this section will provide some more insights to the filtering considerations that are currently being taken into account. Filtering is now being categorized into three specific areas: data plane, managementplaneplane, and routing control plane. 2.7.1. Data Plane Filtering Data plane filters control the traffic that traverses through a device andaffectaffects transit traffic. Most ISPs deploy these kinds of filters atthecustomer facing edge devices to mitigate spoofing attacks using BCP38 and BCP84 guidelines. 2.7.2. Management Plane Filtering Management filters control the traffic to and from a device. All of the protocolswhichthat are used for device management fall under this category andincludesinclude: SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP,SCPSCP, and Syslog. This type of traffic is often filtered per interface and is based on any combination of protocol, source and destination IPaddressaddress, and source and destination port number. Some devices support functionality to apply management filters to the device rather than to the specific interfaces(e.g.(e.g., receive ACL or loopback interfaceACL)ACL), which is gaining wider acceptance. Note that logging the filtering rules can today place a burden on many systems and more granularity is often required to more specifically log the required exceptions. Any services that are not specifically used are turned off. IPv6 networks require the use of specific ICMP messages for proper protocol operation. Therefore, ICMP cannot be completely filtered to and from a device. Instead, granular ICMPv6 filtering is always deployed to allow for specific ICMPv6 types to be sourced or destined to a network device. A good guideline for IPv6 filtering is in thedraft work in progress onRecommendations for Filtering ICMPv6 Messages in Firewalls[I-D.ietf-v6ops-icmpv6-filtering-recs].[ICMPv6]. 2.7.3. Routing Control Plane Filtering Routing filters are used to control the flow of routing information. In IPv6 networks, some providers are liberal in accepting /48s due to the still unresolved multihomingissuesissues, while others filter at allocationboundariesboundaries, which are typically at /32. Any announcement received that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing is filtered out of eBGP. Note that this is fornon- customernon-customer traffic. Most ISPs will accept any agreed upon prefix length from its customer(s). 2.8.Denial of Service Tracking / Tracing Denial of ServiceDenial-of-Service Tracking/Tracing Denial-of-Service attacks are anever increasingever-increasing problem and require vast amounts of resources to combat effectively. Some large ISPs do not concern themselves with attack streams that are less than 1G in bandwidth - this is on the larger pipes where 1G is essentially less than 5% of an offered load. This is largely due to the large amounts ofDDoS trafficDoS traffic, which continually requires investigation and mitigation. At lastcountcount, 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:sink holesinkhole routing,black-holeblack hole triggered routing, uRPF, ratelimitinglimiting, and specific control plane traffic enhancements. Each of these techniques will be detailed below. 2.8.1.Sink HoleSinkhole RoutingSink holeSinkhole routing refers to injecting a more specific route for any known attacktraffictraffic, which will ensure that the malicious traffic is redirected to a valid device or specific system where it can be analyzed. 2.8.2.Black-HoleBlack Hole Triggered RoutingBlack-holeBlack hole triggered routing (also referred to as Remote Triggered Black Hole Filtering) is a technique where the BGP routing protocol is used to propagate routes which in turn redirects attack traffic to the null interface where it is effectively dropped. This technique is often used in large routing infrastructures since BGP can propagate the information in afastfast, effectivemannermanner, as opposed to using any packet-based filtering techniques on hundreds or thousands ofrouters. [referrouters (refer to the following NANOG presentation for a more complete descriptionhttp://www.nanog.org/mtg-0402/pdf/morrow.pdf]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 instigateblackholingblack-holing trafficwhichthat appeared to come from a certain site. On the other hand, thisblackholeblack hole technique can decrease the collateral damage caused by an overly large attack aimed at something other than critical services. 2.8.3. Unicast Reverse Path Forwarding Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating whether or not an incoming packet has a legitimate sourceaddress or not.address. It has two modes: strict mode and loose mode. In strict mode, uRPF checks whether the incoming packet has a source address that matches a prefix in the routing table, and whether the interface expects to receive a packet with this source address prefix. If the incoming packet fails the unicast RPF check, the packet is not accepted on the 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[I-D.savola-bcp84-urpf-experiences][BCP84-URPF] detail how asymmetry,i.e.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. 2.8.4. Rate Limiting Rate limiting refers to allocating a specific amount of bandwidth or packets per second to specific traffic types. This technique is widely used to mitigate well-known protocol attacks such as theTCP- SYN attackTCP-SYN attack, where a large number of resources get allocated for spoofed TCP traffic. Although this technique does not stop an attack, it can sometimes lessen the damage and impact on a specific service. However, it can also make the impact of aDDoSDoS attack much worse if the rate limiting is impacting(i.e.(i.e., discarding) more legitimate traffic. 2.8.5. Specific Control Plane Traffic Enhancements Some ISPs are starting to use capabilitieswhichthat are available from some vendors to simplify the filtering andrate-limitingrate limiting of control traffic. Control traffic here refers to the routing control plane and management plane traffic that requires CPU cycles. A DoS attack against any control plane traffic can therefore be much more damaging to a critical device than other types of traffic. No consistent deployment of this capability was found at the time of this writing. 3. Security Considerations This entire document deals with current security practices in large ISP environments. It lists specific practices used in today's environments and assuchsuch, does not in itself pose any security risk. 4.IANA Considerations This document has no actions for IANA. 5.Acknowledgments The editor gratefully acknowledges the contributions of: George Jones, who has been instrumental in providing guidance and direction for thisdocumentdocument, and theinsighfulinsightful comments from Ross Callon, Ron Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont, Chris Morrow, Ted Seely, DonaldSmithSmith, and the numerous ISP operators who supplied the informationwhichthat is depicted in this document.6.5. References6.1.5.1. Normative References[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[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.6.2.5.2. Informational References[I-D.ietf-v6ops-icmpv6-filtering-recs][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",draft-ietf-v6ops-icmpv6-filtering-recs-02 (workWork inprogress),Progress, July 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-bcp84-urpf-experiences] Savola, P., "Experiences from Using Unicast RPF", draft-savola-bcp84-urpf-experiences-01 (work in progress), June 2006. [I-D.savola-rtgwg-backbone-attacks][RTGWG] Savola, P., "Backbone Infrastructure Attacks and Protections",draft-savola-rtgwg-backbone-attacks-02 (workWork inprogress),Progress, July 2006. Appendix A. Protocol Specific Attacks This section will list many of the traditionalprotocol basedprotocol-based attackswhichthat have been observed over the years to cause malformed packets and/or exploit protocol deficiencies. Note that they all exploit vulnerabilities in the actual protocol itself and often, additional authentication and auditing mechanisms are now used to detect and mitigate the impact of these attacks. The list is notexhaustiveexhaustive, but is a fraction of the representation of what types of attacks are possible for varying protocols. A.1. Layer 2 Attacks o ARP Flooding A.2. IPv4Protocol BasedProtocol-Based Attacks o IP Addresses, either source or destination, can be spoofed which in turn can circumvent established filtering rules. o IP Source Route Option can allows attackers to establish stealth TCPconnectionsconnections. o IP Record Route Option candisclosesdisclose information about the topology of the network. o IP header that is too long or too short can cause DoS attacks to devices. o IP Timestamp Option can leak informationwhichthat can be used to discern network behavior. o Fragmentation attacks which can vary widely - more detailed information can be found at http://www-src.lip6.fr/homepages/Fabrice.Legond-Aubry/www.ouah.org/fragma.htmlFabrice.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 afirewallfirewall. o IP TTL field can be used to bypass certainnetwork basednetwork-based intrusion detection systems and to map network behavior. A.2.1. Higher Layer Protocol Attacks The following lists additionalattacksattacks, but does not explicitly numerate them in detail. It is for informational purposes only. o IGMP oversized packet o ICMP Source Quench o ICMP Mask Request o ICMP Large Packet (> 1472) o ICMP Oversized packet (>65536) o ICMP Flood o ICMP Broadcast w/ Spoofed Source (Smurf Attack) o ICMP Error Packet Flood o ICMP Spoofed Unreachable o TCP Packet without Flag o TCP Oversized Packet o TCP FIN bit with no ACK bit o TCP Packet with URG/OOB flag (Nuke Attack) o SYN Fragments o SYN Flood o SYN with IP Spoofing (Land Attack) o SYN and FIN bits set o TCP port scan attack o UDP spoofed broadcast echo (Fraggle Attack) o UDP attack on diagnostic ports (Pepsi Attack) A.3. IPv6 Attacks Any of the above-mentioned IPv4 attacks could be used in IPv6 networks with the exception of any fragmentation and broadcast traffic, which operate differently in IPv6. Note that all of these attacks are based on either spoofing or misusing any part of the protocol field(s). Today,IPv6 enabledIPv6-enabled hosts are starting to be used to create IPv6tunnelstunnels, which can effectively hide botnet and other malicious traffic if firewalls and network flow collection tools are not capable of detecting this traffic. The security measures used for protecting IPv6 infrastructures should be the same as in IPv4networksnetworks, but with additional considerations for IPv6 networkoperationsoperations, which may be different from IPv4. Author's Address Merike Kaeo Double Shot Security, Inc. 3518 Fremont Avenue North #363 Seattle, WA 98103 U.S.A. Phone: +1 310 866 0165Email:EMail: merike@doubleshotsecurity.com Full Copyright Statement Copyright (C) TheInternet Society (2006).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 INTERNETSOCIETYSOCIETY, 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 ietf-ipr@ietf.org.AcknowledgmentAcknowledgement Funding for the RFC Editor function is currently provided by theIETF Administrative Support Activity (IASA).Internet Society.