idnits 2.17.1 draft-ietf-opsec-current-practices-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1711. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2006) is 6450 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRR' is mentioned on line 948, but not defined == Unused Reference: 'RFC2119' is defined on line 1508, but no explicit reference was found in the text == Unused Reference: 'I-D.lewis-infrastructure-security' is defined on line 1539, but no explicit reference was found in the text == Unused Reference: 'I-D.savola-rtgwg-backbone-attacks' is defined on line 1549, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 3682 (Obsoleted by RFC 5082) == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-icmpv6-filtering-recs-02 == Outdated reference: A later version (-03) exists of draft-savola-bcp84-urpf-experiences-01 == Outdated reference: A later version (-03) exists of draft-savola-rtgwg-backbone-attacks-02 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC M. Kaeo 3 Internet-Draft Double Shot Security, Inc. 4 Intended status: Informational August 29, 2006 5 Expires: March 2, 2007 7 Operational Security Current Practices 8 draft-ietf-opsec-current-practices-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 2, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document is a survey of the current practices used in today's 42 large ISP operational networks to secure layer 2 and layer 3 43 infrastructure devices. The information listed here is the result of 44 information gathered from people directly responsible for defining 45 and implementing secure infrastructures in Internet Service Provider 46 environments. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 54 1.4. Operational Security Impact from Threats . . . . . . . . . 6 55 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 56 2. Protected Operational Functions . . . . . . . . . . . . . . . 9 57 2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9 58 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 11 59 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 17 60 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 19 61 2.5. Software Upgrades and Configuration Integrity / 62 Validation . . . . . . . . . . . . . . . . . . . . . . . . 23 63 2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 27 64 2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 30 65 2.8. Denial of Service Tracking / Tracing . . . . . . . . . . . 31 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 34 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 68 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 37 71 6.2. Informational References . . . . . . . . . . . . . . . . . 37 72 Appendix A. Protocol Specific Attacks . . . . . . . . . . . . . . 39 73 A.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 39 74 A.2. IPv4 Protocol Based Attacks . . . . . . . . . . . . . . . 39 75 A.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 41 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 77 Intellectual Property and Copyright Statements . . . . . . . . . . 43 79 1. Introduction 81 Security practices are well understood by the network operators who 82 have for many years gone through the growing pains of securing their 83 network infrastructures. However, there does not exist a written 84 document that enumerates these security practices. Network attacks 85 are continually increasing and although it is not necessarily the 86 role of an ISP to act as the Internet police, each ISP has to ensure 87 that certain security practices are followed to ensure that their 88 network is operationally available for their customers. This 89 document is the result of a survey conducted to find out what current 90 security practices are being deployed to secure network 91 infrastructures. 93 1.1. Scope 95 The scope for this survey is restricted to security practices that 96 mitigate exposure to risks with the potential to adversely impact 97 network availability and reliability. Securing the actual data 98 traffic is outside the scope of the conducted survey. This document 99 focuses solely on documenting currently deployed security mechanisms 100 for layer 2 and layer 3 network infrastructure devices. Although 101 primarily focused on IPv4, many of the same practices can (and 102 should) apply to IPv6 networks. Both IPv4 and IPv6 network 103 infrastructures are taken into account in this survey. 105 1.2. Threat Model 107 A threat is a potential for a security violation, which exists when 108 there is a circumstance, capability, action, or event that could 109 breach security and cause harm [RFC2828]. Every operational network 110 is subject to a multitude of threat actions, or attacks, i.e. an 111 assault on system security that derives from an intelligent act that 112 is a deliberate attempt to evade security services and violate the 113 security policy of a system [RFC2828]. Many of the threats to a 114 network infrastructure occur from an instantiation (or combination) 115 of the following: 117 Reconnaissance: An attack whereby information is gathered to 118 ascertain the network topology or specific device information which 119 can be further used to exploit known vulnerabilities 121 Man-In-The-Middle: An attack where a malicious user impersonates 122 either the sender or recipient of a communication stream while 123 inserting, modifying or dropping certain traffic. This type of 124 attack also covers phishing and session hijacks. 126 Protocol Vulnerability Exploitation: An attack which takes advantage 127 of known protocol vulnerabilities due to design or implementation 128 flaws to cause inappropriate behavior. 130 Message Insertion: This can be a valid message (which could be a 131 reply attack, which is a scenario where a message is captured and 132 resent at later time). A message can also be inserted with any of 133 the fields in the message being OspoofedO, such as IP addresses, port 134 numbers, header fields or even packet content. Flooding is also part 135 of this threat instantiation. 137 Message Diversion/Deletion: An attack where legitimate messages are 138 removed before they can reach the desired recipient or are re- 139 directed to a network segment that is normally not part of the data 140 path. 142 Message Modification: This is a subset of a message insertion attack 143 where a previous message has been captured and modified before being 144 retransmitted. The message can be captured by using a man-in-the- 145 middle attack or message diversion. 147 Note that sometimes Denial of service attacks are listed as separate 148 categories. A denial of service is a consequence of an attack and 149 can be the result of too much traffic (i.e. flooding), or exploiting 150 protocol exploitation or inserting/deleting/diverting/modifying 151 messages. 153 1.3. Attack Sources 155 These attacks can be sourced in a variety of ways: 157 Active vs passive attacks 159 An active attack involves writing data to the network. It is 160 common practice in active attacks to disguise one's address and 161 conceal the identity of the traffic sender. A passive attack 162 involves only reading information off the network. This is 163 possible if the attacker has control of a host in the 164 communications path between two victim machines or has compromised 165 the routing infrastructure to specifically arrange that traffic 166 pass through a compromised machine. There are also situations 167 where mirrored traffic (often used for debugging, performance 168 monitoring or accounting purposes) is diverted to a compromised 169 machine which would not necessarily subvert any existing topology 170 and could be harder to detect. In general, the goal of a passive 171 attack is to obtain information that the sender and receiver would 172 prefer to remain private. [RFC3552] 174 On-path vs off-path attacks 176 In order for a datagram to be transmitted from one host to 177 another, it generally must traverse some set of intermediate links 178 and routers. Such routers are naturally able to read, modify, or 179 remove any datagram transmitted along that path. This makes it 180 much easier to mount a wide variety of attacks if you are on-path. 181 Off-path hosts can transmit arbitrary datagrams that appear to 182 come from any hosts but cannot necessarily receive datagrams 183 intended for other hosts. Thus, if an attack depends on being 184 able to receive data, off-path hosts must first subvert the 185 topology in order to place themselves on-path. This is by no 186 means impossible but is not necessarily trivial. [RFC3552] A more 187 subtle attack is one where the traffic mirroring capability of a 188 device is hijacked and the traffic is diverted to a compromised 189 host since the network topology may not need to be subverted. 191 Insider or outsider attacks 193 An "insider attack" is one which is initiated from inside a given 194 security perimeter, by an entity that is authorized to access 195 system resources but uses them in a way not approved by those who 196 granted the authorization. An "outside attack" is initiated from 197 outside the perimeter, by an unauthorized or illegitimate user of 198 the system. 200 Deliberate attacks vs unintentional events 202 A deliberate attack is one where a miscreant intentionally 203 performs an assault on system security. However, there are also 204 instances where unintentional events cause the same harm yet are 205 performed without malice in mind. Configuration errors and 206 software bugs can be as devastating to network availability as any 207 deliberate attack on the network infrastructure. 209 The attack source can be a combination of any of the above, all of 210 which need to be considered when trying to ascertain what impact any 211 attack can have on the availability and reliability of the network. 212 It is nearly impossible to stop insider attacks or unintentional 213 events. However, if appropriate monitoring mechanisms are in place, 214 these attacks can also be detected and mitigated as with any other 215 attack source. The amount of effort it takes to identify and trace 216 an attack is of course dependent on the resourcefulness of the 217 attacker. Any of the specific attacks discussed further in this 218 document will elaborate on malicious behavior which are sourced by an 219 "outsider" and are deliberate attacks. Some further elaboration will 220 be given to the feasibility of passive vs active and on-path vs off- 221 path attacks to show the motivation behind deploying certain security 222 features. 224 1.4. Operational Security Impact from Threats 226 The main concern for any of the potential attack scenarios is the 227 impact and harm it can cause to the network infrastructure. The 228 threat consequences are the security violations which results from a 229 threat action, i.e. an attack. These are typically classified as 230 follows: 232 (Unauthorized) Disclosure 234 A circumstance or event whereby an entity gains access to data for 235 which the entity is not authorized. 237 Deception 239 A circumstance or event that may result in an authorized entity 240 receiving false data and believing it to be true. 242 Disruption 244 A circumstance or event that interrupts or prevents the correct 245 operation of system services and functions. A broad variety of 246 attacks, collectively called denial of service attacks, threaten 247 the availability of systems and bandwidth to legitimate users. 248 Many such attacks are designed to consume machine resources, 249 making it difficult or impossible to serve legitimate users. 250 Other attacks cause the target machine to crash, completely 251 denying service to users. 253 Usurpation 255 A circumstance or event that results in control of system services 256 or functions by an unauthorized entity. Most network 257 infrastructure systems are only intended to be completely 258 accessible to certain authorized individuals. Should an 259 unauthorized person gain access to critical layer 2 / layer 3 260 infrastructure devices or services, they could cause great harm to 261 the reliability and availability of the network. 263 A complete description of threat actions that can cause these threat 264 consequences can be found in [RFC2828]. Typically, a number of 265 different network attacks are used in combination to cause one or 266 more of the above mentioned threat consequences. An example would be 267 a malicious user who has the capability to eavesdrop on traffic. 268 First, he may listen in on traffic for a while to do some 269 reconnaissance work and ascertain which IP addresses belonged to 270 specific devices such as routers. Were this miscreant to obtain 271 information such as a router password sent in cleartext, he can then 272 proceed to compromise the actual router. From there, the miscreant 273 can launch various active attacks such as sending bogus routing 274 updates to redirect traffic or capture additional traffic to 275 compromise other network devices. 277 1.5. Document Layout 279 This document is a survey of current operational practices that 280 mitigate the risk of being susceptible to any threat actions. As 281 such, the main focus is on the currently deployed security practices 282 used to detect and/or mitigate attacks. The top-level categories in 283 this document are based on operational functions for ISPs and 284 generally relate to what is to be protected. This is followed by a 285 description of which attacks are possible and the security practices 286 currently deployed which will provide the necessary security services 287 to help mitigate these attacks. These security services are 288 classified as: 290 o User Authentication 292 o User Authorization 294 o Data Origin Authentication 296 o Access Control 298 o Data Integrity 300 o Data Confidentiality 302 o Auditing / Logging 304 o DoS Mitigation 306 In many instances, a specific protocol currently deployed will offer 307 a combination of these services. For example, AAA can offer user 308 authentication, user authorization and audit / logging services while 309 SSH can provide data origin authentication, data integrity and data 310 confidentiality. The services offered are more important than the 311 actual protocol used. Note that access control will refer basically 312 to logical access control, i.e. filtering. Each section ends with an 313 additional considerations section which explains why specific 314 protocols may or may not be used and also gives some information 315 regarding capabilities which are not possible today due to bugs or 316 lack of ease of use. 318 2. Protected Operational Functions 320 2.1. Device Physical Access 322 Device physical access pertains to protecting the physical location 323 and access of the layer 2 or layer 3 network infrastructure device. 324 Physical security is a large field of study/practice in and of 325 itself, arguably the largest, oldest and most well understood area of 326 security. Although it is important to have contingency plans for 327 natural disasters such as earthquakes and floods which can cause 328 damage to networking devices, this is out-of-scope for this document. 329 Here we concern ourselves with protecting access to the physical 330 location and how a device can be further protected from unauthorized 331 access if the physical location has been compromised, i.e protecting 332 the console access. This is aimed largely at stopping an intruder 333 with physical access from gaining operational control of the 334 device(s). Note that nothing will stop an attacker with physical 335 access from effecting a denial of service attack, which can be easily 336 accomplished by powering off the device or just unplugging some 337 cables. 339 2.1.1. Threats / Attacks 341 If any intruder gets physical access to a layer 2 or layer 3 device, 342 the entire network infrastructure can be under the control of the 343 intruder. At a minimum, the intruder can take the compromised device 344 out-of-service, causing network disruption, the extent of which 345 depends on the network topology. A worse scenario is where the 346 intruder can use this device to crack the console password and have 347 complete control of the device, perhaps without anyone detecting such 348 a compromise, or to attach another network device onto a port and 349 siphon off data with which the intruder can ascertain the network 350 topology and take control of the entire network. 352 The threat of gaining physical access can be realized in a variety of 353 ways even if critical devices are under high-security. There still 354 occur cases where attackers have impersonated maintenance workers to 355 gain physical access to critical devices that have caused major 356 outages and privacy compromises. Insider attacks from authorized 357 personnel also pose a real threat and must be adequately recognized 358 and dealt with. 360 2.1.2. Security Practices 362 For physical device security, equipment is kept in highly restrictive 363 environments. Only authorized users with cardkey badges have access 364 to any of the physical locations that contain critical network 365 infrastructure devices. These cardkey systems keep track of who 366 accessed which location and at what time. Most cardkey systems have 367 a fail back "master key" in case the card system is down. This 368 "master key" usually has limited access and its use is also carefully 369 logged (which should only happen if the cardkey system is NOT online/ 370 functional). 372 All console access is always password protected and the login time is 373 set to time out after a specified amount of inactivity - typically 374 between 3-10 minutes. The type of privileges that you obtain from a 375 console login varies between separate vendor devices. In some cases 376 you get initial basic access and need to perform a second 377 authentication step to get more privileged (i.e. enable or root) 378 access. In other vendors you get the more privileged access when you 379 log into the console as root, without requiring a second 380 authentication step. 382 How ISPs manage these logins vary greatly although many of the larger 383 ISPs employ some sort of AAA mechanism to help automate privilege 384 level authorization and can utilize the automation to bypass the need 385 for a second authentication step. Also, many ISPs define separate 386 classes of users to have different privileges while logged onto the 387 console. Typically all console access is provided via an out-of-band 388 (OOB) management infrastructure which is discussed in the section on 389 OOB management. 391 2.1.3. Security Services 393 The following security services are offered through the use of the 394 practices described in the previous section: 396 o User Authentication - All individuals who have access to the 397 physical facility are authenticated. Console access is 398 authenticated. 400 o User Authorization - An authenticated individual has implicit 401 authorization to perform commands on the device. In some cases 402 multiple authentication is required to differentiate between basic 403 and more privileged access. 405 o Data Origin Authentication - Not applicable 407 o Access Control - Not applicable 409 o Data Integrity - Not applicable 411 o Data Confidentiality - Not applicable 412 o Auditing / Logging - All access to the physical locations of the 413 infrastructure equipment is logged via electronic card-key 414 systems. All console access is logged (refer to the OOB 415 management section for more details) 417 o DoS Mitigation - Not applicable 419 2.1.4. Additional Considerations 421 Physical security is relevant to operational security practices as 422 described in this document mostly from a console access perspective. 423 Most ISPs provide console access via an OOB management infrastructure 424 which is discussed in the OOB management section of this document. 426 The physical and logical authentication and logging systems should be 427 run independently of each other and reside in different physical 428 locations. These systems need to be secured to ensure that they 429 themselves will not be compromised which could give the intruder 430 valuable authentication and logging information. 432 Social engineering plays a big role in many physical access 433 compromises. Most ISPs have set up training classes and awareness 434 programs to educate company personnel to deny physical access to 435 people who are not properly authenticated or authorized to have 436 physical access to critical infrastructure devices. 438 2.2. Device Management - In-Band and Out-of-Band (OOB) 440 In-band management is generally considered to be device access where 441 the control traffic takes the same data path as the data which 442 traverses the network. Out-of-band management is generally 443 considered to be device access where the control traffic takes a 444 separate path as the data which traverses the network. In many 445 environments, device management for layer 2 and layer 3 446 infrastructure devices is deployed as part of an out-of-band 447 management infrastructure although there are some instances where it 448 is deployed in-band as well. Note that while many of the security 449 concerns and practices are the same for OOB management and in-band 450 management, most ISPs prefer an OOB management system since access to 451 the devices which make up this management network are more vigilantly 452 protected and considered to be less susceptible to malicious 453 activity. 455 Console access is always architected via an OOB network. Presently, 456 the mechanisms used for either in-band management or OOB are via 457 virtual terminal access (i.e. Telnet or SSH), SNMP, or HTTP. In all 458 large ISPs that were interviewed, HTTP management is never used and 459 is explicitly disabled. Note that file transfer protocols (TFTP, 460 FTP, SCP) will be covered in the 'Software Upgrades and Configuration 461 Integrity/Validation' section. 463 2.2.1. Threats / Attacks 465 For device management, passive attacks are possible if someone has 466 the capability to intercept data between the management device and 467 the managed device. The threat is possible if a single 468 infrastructure device is somehow compromised and can act as a network 469 sniffer or if it is possible to insert a new device which acts as a 470 network sniffer. 472 Active attacks are possible for both on-path and off-path scenarios. 473 For on-path active attacks, the situation is the same as for a 474 passive attack, where either a device has to already be compromised 475 or a device can be inserted into the path. For off-path active 476 attacks, where a topology subversion is required to reroute traffic 477 and essentially bring the attacker on-path, the attack is generally 478 limited to message insertion or modification. 480 2.2.1.1. Confidentiality Violations 482 Confidentiality violations can occur when a miscreant intercepts any 483 management data that has been sent in cleartext or with weak 484 encryption. This includes interception of usernames and passwords 485 with which an intruder can obtain unauthorized access to network 486 devices. It can also include other information such as logging or 487 configuration information if an administrator is remotely viewing 488 local logfiles or configuration information. 490 2.2.1.2. Offline Cryptographic Attacks 492 If username/password information was encrypted but the cryptographic 493 mechanism used made it easy to capture data and break the encryption 494 key, the device management traffic could be compromised. The traffic 495 would need to be captured either by eavesdropping on the network or 496 by being able to divert traffic to a malicious user. 498 2.2.1.3. Replay Attacks 500 For a replay attack to be successful, the management traffic would 501 need to first be captured either on-path or diverted to an attacker 502 to later be replayed to the intended recipient. 504 2.2.1.4. Message Insertion/Deletion/Modification 506 Data can be manipulated by someone in control of intermediary hosts. 507 Forging data is also possible with IP spoofing, where a remote host 508 sends out packets which appear to come from another, trusted host. 510 2.2.1.5. Man-In-The-Middle 512 A man-in-the-middle attack attacks the identity of a communicating 513 peer rather than the data stream itself. The attacker intercepts 514 traffic that is sent from a management system to the networking 515 infrastructure device and traffic that is sent from the network 516 infrastructure device to the management system. 518 2.2.2. Security Practices 520 OOB management is done via a terminal server at each location. SSH 521 access is used to get to the terminal server from where sessions to 522 the devices are initiated. Dial-in access is deployed as a backup if 523 the network is not available however, it is common to use dial-back, 524 encrypting modems and/or one-time-password (OTP) modems to avoid the 525 security weaknesses of plain dial-in access. 527 All in-band management and OOB management access to layer 2 and layer 528 3 devices is authenticated. The user authentication and 529 authorization is typically controlled by a AAA server (i.e. RADIUS 530 and/or TACACS+). Credentials used to determine the identity of the 531 user vary from static username/password to one-time username/password 532 scheme such as Secure-ID. Static username/passwords are expired 533 after a specified period of time, usually 30 days. Every 534 authenticated entity via AAA is an individual user for greater 535 granularity of control. Note that often the AAA server used for OOB 536 management authentication is a separate physical device from the AAA 537 server used for in-band management user authentication. In some 538 deployments, the AAA servers used for device management 539 authentication/authorization/accounting are on separate networks to 540 provide a demarcation for any other authentication functions. 542 For backup purposes, there is often a single local database entry for 543 authentication which is known to a very limited set of key personnel. 544 It is usually the highest privilege level username/password 545 combination, which in most cases is the same across all devices. 546 This local device password is routinely regenerated once every 2-3 547 months and is also regenerated immediately after an employee who had 548 access to that password leaves the company or is no longer authorized 549 to have knowledge of that password. 551 Each individual user in the AAA database is configured with specific 552 authorization capability. Specific commands are either individually 553 denied or permitted depending on the capability of the device to be 554 accessed. Multiple privilege levels are deployed. Most individuals 555 are authorized with basic authorization to perform a minimal set of 556 commands while a subset of individuals are authorized to perform more 557 privileged commands. Securing the AAA server is imperative and 558 access to the AAA server itself is strictly controlled. When an 559 individual leaves the company, his/her AAA account is immediately 560 deleted and the TACACS/RADIUS shared secret is reset for all devices. 562 Some management functions are performed using command line interface 563 (CLI) scripting. In these scenarios, a dedicated user is used for 564 the identity in scripts that perform CLI scripting. Once 565 authenticated, these scripts control which commands are legitimate 566 depending on authorization rights of the authenticated individual. 568 SSH is always used for virtual terminal access to provide for an 569 encrypted communication channel. There are exceptions due to 570 equipment limitations which are described in the additional 571 considerations section. 573 If SNMP is used for management, it is for read queries only and 574 restricted to specific hosts. If possible, the view is also 575 restricted to only send the information that the management station 576 needs rather than expose the entire configuration file with the read- 577 only SNMP community. The community strings are carefully chosen to 578 be difficult to crack and there are procedures in place to change 579 these community strings between 30-90 days. If systems support two 580 SNMP community strings, the old string is replaced by first 581 configuring a second newer community string and then migrating over 582 from the currently used string to the newer one. Most large ISPs 583 have multiple SNMP systems accessing their routers so it takes more 584 then one maintenance period to get all the strings fixed in all the 585 right systems. SNMP RW is not used and is disabled by configuration. 587 Access control is strictly enforced for infrastructure devices by 588 using stringent filtering rules. A limited set of IP addresses are 589 allowed to initiate connections to the infrastructure devices and are 590 specific to the services which they are to limited to (i.e. SSH and 591 SNMP). 593 All device management access is audited and any violations trigger 594 alarms which initiate automated email, pager and/or telephone 595 notifications. AAA servers keeps track of the authenticated entity 596 as well as all the commands that were carried out on a specific 597 device. Additionally, the device itself logs any access control 598 violations (i.e. if an SSH request comes in from an IP address which 599 is not explicitly permitted, that event is logged so that the 600 offending IP address can be tracked down and investigations made as 601 to why it was trying to access a particular infrastructure device) 603 2.2.3. Security Services 605 The security services offered for device OOB management are nearly 606 identical to those of device in-band management. Due to the critical 607 nature of controlling and limiting device access, many ISPs feel that 608 physically separating the management traffic from the normal customer 609 data traffic will provide an added level of risk mitigation and limit 610 the potential attack vectors. The following security services are 611 offered through the use of the practices described in the previous 612 section: 614 o User Authentication - All individuals are authenticated via AAA 615 services. 617 o User Authorization - All individuals are authorized via AAA 618 services to perform specific operations once successfully 619 authenticated. 621 o Data Origin Authentication - Management traffic is strictly 622 filtered to allow only specific IP addresses to have access to the 623 infrastructure devices. This does not alleviate risk from spoofed 624 traffic, although when combined with edge filtering using BCP38 625 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in the section 626 2.5), then the risk of spoofing is mitigated barring a compromised 627 internal system. Also, using SSH for device access ensures that 628 noone can spoof the traffic during the SSH session. 630 o Access Control - Management traffic is filtered to allow only 631 specific IP addresses to have access to the infrastructure 632 devices. 634 o Data Integrity - Using SSH provides data integrity and ensures 635 that no one has altered the management data in transit. 637 o Data Confidentiality - Using SSH provides data confidentiality. 639 o Auditing / Logging - Using AAA provides an audit trail for who 640 accessed which device and which operations were performed. 642 o DoS Mitigation - Using packet filters to allow only specific IP 643 addresses to have access to the infrastructure devices. This 644 limits but does not prevent spoofed DoS attacks directed at an 645 infrastructure device. However, the risk is lowered by using a 646 separate physical network for management purposes. 648 2.2.4. Additional Considerations 650 Password selection for any device management protocol used is 651 critical to ensure that the passwords are hard to guess or break 652 using a brute-force attack. 654 IPsec is considered too difficult to deploy and the common protocol 655 to provide for confidential management access is SSH. There are 656 exceptions for using SSH due to equipment limitations since SSH may 657 not be supported on legacy equipment. In some cases changing the 658 hostname of a device requires an SSH rekey event since the key is 659 based on some combination of host name, MAC address and time. Also, 660 in the case where the SSH key is stored on a route processor card, a 661 re-keying of SSH would be required whenever the route processor card 662 needs to be swapped. Some providers feel that this operational 663 impact exceeds the security necessary and instead use Telnet from 664 trusted inside hosts (called 'jumphosts' or 'bastion hosts') to 665 manage those devices. An individual would first SSH to the jumphost 666 and then Telnet from the jumphost to the actual infrastructure 667 device, fully understanding that any passwords will be sent in the 668 clear between the jumphost and the device it is connecting to. All 669 authentication and authorization is still carried out using AAA 670 servers. 672 In instances where Telnet access is used, the logs on the AAA servers 673 are more verbose and more attention is paid to them to detect any 674 abnormal behavior. The jumphosts themselves are carefully controlled 675 machines and usually have limited access. Note that Telnet is NEVER 676 allowed to an infrastructure device except from specific jumphosts; 677 i.e. packet filters are used at the console server and/or 678 infrastructure device to ensure that Telnet is only allowed from 679 specific IP addresses. 681 With thousands of devices to manage, some ISPs have created automated 682 mechanisms to authenticate to devices. As an example, Kerberos has 683 been used to automate the authentication process for devices that 684 have support for Kerberos. An individual would first log in to a 685 Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. 686 This 'ticket' is generally set to have a lifespan of 10 hours and is 687 used to automatically authenticate the individual to the 688 infrastructure devices. 690 In instances where SNMP is used, some legacy devices only support 691 SNMPv1 which then requires the provider to mandate its use across all 692 infrastructure devices for operational simplicity. SNMPv2 is 693 primarily deployed since it is easier to set up than v3. 695 2.3. Data Path 697 This section refers to how traffic is handled which traverses the 698 network infrastructure device. The primary goal of ISPs is to 699 forward customer traffic. However, due to the large amount of 700 malicious traffic that can cause DoS attacks and render the network 701 unavailable, specific measures are sometimes deployed to ensure the 702 availability to forward legitimate customer traffic. 704 2.3.1. Threats / Attacks 706 Any data traffic can potentially be attack traffic and the challenge 707 is to detect and potentially stop forwarding any of the malicious 708 traffic. The deliberately sourced attack traffic can consist of 709 packets with spoofed source and/or destination addresses or any other 710 malformed packet which mangle any portion of a header field to cause 711 protocol-related security issues (such as resetting connections, 712 causing unwelcome ICMP redirects, creating unwelcome IP options or 713 packet fragmentations). 715 2.3.2. Security Practices 717 Filtering and rate limiting are the primary mechanism to provide risk 718 mitigation of malicious traffic rendering the ISP services 719 unavailable. However, filtering and rate limiting of data path 720 traffic is deployed in a variety of ways depending on how automated 721 the process is and what the capabilities and performance limitations 722 of existing deployed hardware are. 724 The ISPs which do not have performance issues with their equipment 725 follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress 726 filtering. BCP38 recommends filtering ingress packets with obviously 727 spoofed and/or 'reserved' source addresses to limit the effects of 728 denial of service attacks while BCP84 extends the recommendation for 729 multi-homed environments. Filters are also used to help alleviate 730 issues between service providers. Without any filtering, an inter- 731 exchange peer could steal transit just by using static routes and 732 essentially redirect data traffic. Therefore, some ISPs have 733 implemented ingress/egress filters which block unexpected source and 734 destination addresses not defined in the above-mentioned documents. 735 Null routes and black-hole triggered routing [RFC3882] are used to 736 deter any detected malicious traffic streams. These two techniques 737 are described in more detail in section 2.8 below. 739 Most ISPs consider layer 4 filtering useful but it is only 740 implemented if performance limitations allow for it. Layer 4 741 filtering is typically only when no other option exists since it does 742 pose a large administrative overhead and ISPs are very much opposed 743 to acting as the Internet firewall. Netflow is used for tracking 744 traffic flows but there is some concern whether sampling is good 745 enough to detect malicious behavior. 747 Unicast RPF is not consistently implemented. Some ISPs are in 748 process of doing so while other ISPs think that the perceived benefit 749 of knowing that spoofed traffic comes from legitimate addresses are 750 not worth the operational complexity. Some providers have a policy 751 of implementing uRPF at link speeds of DS3 and below which was due to 752 the fact that all hardware in the network supported uRPF for DS3 753 speeds and below. At higher speed links the uRPF support was 754 inconsistent and it was easier for operational people to implement a 755 consistent solution. 757 2.3.3. Security Services 759 o User Authentication - Not applicable 761 o User Authorization - Not applicable 763 o Data Origin Authentication - When IP address filtering per BCP38, 764 BCP84 and uRPF are deployed at network edges it can ensure that 765 any spoofed traffic comes from at least a legitimate IP address 766 and can be tracked. 768 o Access Control - IP address filtering and layer 4 filtering is 769 used to deny forbidden protocols and limit traffic destined for 770 infrastructure device itself. Filters are also used to block 771 unexpected source/destination addresses. 773 o Data Integrity - Not applicable 775 o Data Confidentiality - Not applicable 777 o Auditing / Logging - Filtering exceptions are logged for potential 778 attack traffic. 780 o DoS Mitigation - Black-hole triggered filtering and rate-limiting 781 are used to limit the risk of DoS attacks. 783 2.3.4. Additional Considerations 785 For layer 2 devices, MAC address filtering and authentication is not 786 used in large-scale deployments. This is due to the problems it can 787 cause when troubleshooting networking issues. Port security becomes 788 unmanageable at a large scale where 1000s of switches are deployed. 790 Rate limiting is used by some ISPs although other ISPs believe it is 791 not really useful since attackers are not well behaved and it doesn't 792 provide any operational benefit over the complexity. Some ISPs feel 793 that rate limiting can also make an attacker's job easier by 794 requiring the attacker to send less traffic to starve legitimate 795 traffic that is part of a rate limiting scheme. Rate limiting may be 796 improved by developing flow-based rate-limiting capabilities with 797 filtering hooks. This would improve the performance as well as the 798 granularity over current capabilities. 800 Lack of consistency regarding the ability to filter, especially with 801 respect to performance issues cause some ISPs to not implement BCP38 802 and BCP84 guidelines for ingress filtering. One such example is at 803 edge boxes where you have up to 1000 T1's connecting into a router 804 with an OC-12 uplink. Some deployed devices experience a large 805 performance impact with filtering which is unacceptable for passing 806 customer traffic through, though ingress filtering (uRPF) might be 807 applicable at the devices connecting these aggregation routers. 808 Where performance is not an issue, the ISPs make a tradeoff between 809 management versus risk. 811 2.4. Routing Control Plane 813 The routing control plane deals with all the traffic which is part of 814 establishing and maintaining routing protocol information. 816 2.4.1. Threats / Attacks 818 Attacks on the routing control plane can be both from passive or 819 active sources. Passive attacks are possible if someone has the 820 capability to intercept data between the communicating routing peers. 821 This can be accomplished if a single routing peer is somehow 822 compromised and can act as a network sniffer or if it is possible to 823 insert a new device which acts as a network sniffer. 825 Active attacks are possible for both on-path and off-path scenarios. 826 For on-path active attacks, the situation is the same as for a 827 passive attack, where either a device has to already be compromised 828 or a device can be inserted into the path. This may lead to an 829 attacker impersonating a legitimate routing peer and exchanging 830 routing information. Unintentional active attacks are more common 831 due to configuration errors, which cause legitimate routing peers to 832 feed invalid routing information to other neighboring peers. 834 For off-path active attacks, the attacks are generally limited to 835 message insertion or modification which can divert traffic to 836 illegitimate destinations and cause traffic to never reach its 837 intended destination. 839 2.4.1.1. Confidentiality Violations 841 Confidentiality violations can occur when a miscreant intercepts any 842 of the routing update traffic. This is becoming more of a concern 843 because many ISPs are classifying addressing schemes and network 844 topologies as private and proprietary information. It is also a 845 concern because the routing protocol packets contain information that 846 may show ways in which routing sessions could be spoofed or hijacked. 847 This in turn could lead into a man-in-the-middle attack where the 848 miscreants can insert themselves into the traffic path or divert the 849 traffic path and violate the confidentiality of user data. 851 2.4.1.2. Offline Cryptographic Attacks 853 If any cryptographic mechanism was used to provide for data integrity 854 and confidentiality, an offline cryptographic attack could 855 potentially compromise the data. The traffic would need to be 856 captured either by eavesdropping on the network or by being able to 857 divert traffic to a malicious user. Note that by using 858 cryptographically protected routing information, the latter would 859 require the cryptographic key to already be compromised anyway so 860 this attack is only feasible if a device was able eavesdrop and 861 capture the cryptographically protected routing information. 863 2.4.1.3. Replay Attacks 865 For a replay attack to be successful, the routing control plane 866 traffic would need to first be captured either on-path or diverted to 867 an attacker to later be replayed to the intended recipient. 868 Additionally, since many of these protocols include replay protection 869 mechanisms, these would also need to be subverted if applicable. 871 2.4.1.4. Message Insertion/Deletion/Modification 873 Routing control plane traffic can be manipulated by someone in 874 control of intermediate hosts. In addition, traffic can be injected 875 by forging IP addresses, where a remote router sends out packets 876 which appear to come from another, trusted router. If enough traffic 877 is injected to be processed by limited memory routers it can cause a 878 DoS attack. 880 2.4.1.5. Man-In-The-Middle 882 A man-in-the-middle attack attacks the identity of a communicating 883 peer rather than the data stream itself. The attacker intercepts 884 traffic that is sent from one routing peer to the other and 885 communicates on behalf of one of the peers. This can lead to 886 diversion of the user traffic to either an unauthorized receiving 887 party or cause legitimate traffic to never reach its intended 888 destination. 890 2.4.2. Security Practices 892 Securing the routing control plane takes many features which are 893 generally deployed as a system. MD5 authentication is used by some 894 ISPs to validate the sending peer and to ensure that the data in 895 transit has not been altered. Some ISPs only deploy MD5 896 authentication at customer's request. Additional sanity checks to 897 ensure with reasonable certainty that the received routing update was 898 originated by a valid routing peer include route filters and the 899 Generalized TTL Security Mechanism (GTSM) feature [RFC3682] 900 (sometimes also referred to as the TTL-Hack). The GTSM feature is 901 used for protocols such as BGP and makes use of a packet's Time To 902 Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating 903 peers. If GTSM is used, it is typically only deployed in limited 904 scenarios between internal BGP peers due to lack of consistent 905 support between vendor products and operating system versions. 907 Packet filters are used to limit which systems can appear as a valid 908 peer while route filters are used to limit which routes are believed 909 from a valid peer. In the case of BGP routing, a variety of policies 910 are deployed to limit the propagation of invalid routing information. 911 These include: incoming and outgoing prefix filters for BGP 912 customers, incoming and outgoing prefix filters for peers and 913 upstream neighbors, incoming AS-PATH filter for BGP customers, 914 outgoing AS-PATH filter towards peers and upstream neighbors, route 915 dampening and rejecting selected attributes and communities. 916 Consistency between these policies varies greatly and there is a 917 definite distinction whether the other end is an end-site vs an 918 internal peer vs another big ISP or customer. Mostly ISPs do prefix- 919 filter their end-site customers but due to the operational 920 constraints of maintaining large prefix filter lists, many ISPs are 921 starting to depend on BGP AS-PATH filters to/from their peers and 922 upstream neighbors. 924 In cases where prefix lists are not used, operators often define a 925 maximum prefix limit per peer to prevent misconfiguration (e.g., 926 unintentional de-aggregation or neighbor routing policy mis- 927 configuration) or overload attacks. ISPs need to coordinate between 928 each other what the expected prefix exchange is, and increase this 929 number by some sane amount. It is important for ISPs to pad the max- 930 prefix number enough to allow for valid swings in routing 931 announcements to prevent an unintentional shutting down of the BGP 932 session. Individual implementation amongst ISPs are unique, and 933 depending on equipment supplier(s) different implementation options 934 are available. Most equipment vendors offer implementation options 935 ranging from just logging excessive prefixes being received to 936 automatically shutting down the session. If the option of 937 reestablishing a session after some pre-configured idle timeout has 938 been reached is available, it should be understood that automatically 939 reestablishing the session may potentially introduce instability 940 continuously into the overall routing table if a policy mis- 941 configuration on the adjacent neighbor is causing the condition. If 942 a serious mis-configuration on a peering neighbor has occurred then 943 automatically shutting down the session and leaving it shut down 944 until being manually cleared is sometimes best and allows for 945 operator intervention to correct as needed. 947 Some large ISPs require that routes be registered in an Internet 948 Routing Registry [IRR] which can then be part of the RADB - a public 949 registry of routing information for networks in the Internet that can 950 be used to generate filter lists. Some ISPs, especially in europe, 951 require registered routes before agreeing to become an eBGP peer with 952 someone. 954 Many ISPs also do not propagate interface IP addresses to further 955 reduce attack vectors on routers and connected customers. 957 2.4.3. Security Services 959 o User Authentication - Not applicable 961 o User Authorization - Not applicable 963 o Data Origin Authentication - By using MD5 authentication and/or 964 the TTL-hack a routing peer can be reasonably certain that traffic 965 originated from a valid peer. 967 o Access Control - Route filters, AS-PATH filters and prefix limits 968 are used to control access to specific parts of the network. 970 o Data Integrity - By using MD5 authentication a peer can be 971 reasonably certain that the data has not been modified in transit 972 but there is no mechanism to prove the validity of the routing 973 information itself. 975 o Data Confidentiality - Not implemented 977 o Auditing / Logging - Filter exceptions are logged. 979 o DoS Mitigation - Many DoS attacks are mitigated using a 980 combination of techniques including: MD5 authentication, the GTSM 981 feature, filtering routing advertisements to bogons and filtering 982 routing advertisements to one's own network. 984 2.4.4. Additional Considerations 986 So far the primary concern to secure the routing control plane has 987 been to validate the sending peer and to ensure that the data in 988 transit has not been altered. Although MD5 routing protocol 989 extensions have been implemented which can provide both services, 990 they are not consistently deployed amongst ISPs. Two major 991 deployment concerns have been implementation issues where both 992 software bugs and the lack of graceful re-keying options have caused 993 significant network down times. Also, some ISPs express concern that 994 deploying MD5 authentication will itself be a worse DoS attack victim 995 and prefer to use a combination of other risk mitigation mechanisms 996 such as GTSM (for BGP) and route filters. An issue with GTSM is that 997 it is not supported on all devices across different vendors 998 products'. 1000 IPsec is not deployed since the operational management aspects of 1001 ensuring interoperability and reliable configurations is too complex 1002 and time consuming to be operationally viable. There is also limited 1003 concern to the confidentiality of the routing information. The 1004 integrity and validity of the updates are of much greater concern. 1006 There is concern for manual or automated actions which introduce new 1007 routes and can affect the entire routing domain. 1009 2.5. Software Upgrades and Configuration Integrity / Validation 1011 Software upgrades and configuration changes are usually performed as 1012 part of either in-band or OOB management functions. However, there 1013 are additional considerations to be taken into account which are 1014 enumerated in this section. 1016 2.5.1. Threats / Attacks 1018 Attacks performed on system software and configurations can be both 1019 from passive or active sources. Passive attacks are possible if 1020 someone has the capability to intercept data between the network 1021 infrastructure device and the system which is downloading or 1022 uploading the software or configuration information. This can be 1023 accomplished if a single infrastructure device is somehow compromised 1024 and can act as a network sniffer or if it is possible to insert a new 1025 device which acts as a network sniffer. 1027 Active attacks are possible for both on-path and off-path scenarios. 1028 For on-path active attacks, the situation is the same as for a 1029 passive attack, where either a device has to already be compromised 1030 or a device can be inserted into the path. For off-path active 1031 attacks, the attacks are generally limited to message insertion or 1032 modification where the attacker may wish to load illegal software or 1033 configuration files to an infrastructure device. 1035 Note that similar issues are relevant when software updates are 1036 downloaded from a vendor site to an ISPs network management system 1037 that is responsible for software updates and/or configuration 1038 information. 1040 2.5.1.1. Confidentiality Violations 1042 Confidentiality violations can occur when a miscreant intercepts any 1043 of the software image or configuration information. The software 1044 image may give an indication of exploits which the device is 1045 vulnerable to while the configuration information can inadvertently 1046 lead attackers to identify critical infrastructure IP addresses and 1047 passwords. 1049 2.5.1.2. Offline Cryptographic Attacks 1051 If any cryptographic mechanism was used to provide for data integrity 1052 and confidentiality, an offline cryptographic attack could 1053 potentially compromise the data. The traffic would need to be 1054 captured either by eavesdropping on the communication path or by 1055 being able to divert traffic to a malicious user. 1057 2.5.1.3. Replay Attacks 1059 For a replay attack to be successful, the software image or 1060 configuration file would need to first be captured either on-path or 1061 diverted to an attacker to later be replayed to the intended 1062 recipient. Additionally, since many protocols do have replay 1063 protection capabilities, these would have to be subverted as well in 1064 applicable situations. 1066 2.5.1.4. Message Insertion/Deletion/Modification 1068 Software images and configuration files can be manipulated by someone 1069 in control of intermediate hosts. By forging an IP address and 1070 impersonating a valid host which can download software images or 1071 configuration files, invalid files can be downloaded to an 1072 infrastructure device. This can also be the case from trusted 1073 vendors who may unbeknownst to them have compromised trusted hosts. 1074 An invalid software image or configuration file can cause a device to 1075 hang and become inoperable. Spoofed configuration files can be hard 1076 to detect, especially when the only added command is to allow a 1077 miscreant access to that device by entering a filter allowing a 1078 specific host access and configuring a local username/password 1079 database entry for authentication to that device. 1081 2.5.1.5. Man-In-The-Middle 1083 A man-in-the-middle attack attacks the identity of a communicating 1084 peer rather than the data stream itself. The attacker intercepts 1085 traffic that is sent between the infrastructure device and the host 1086 used to upload/download the system image or configuration file. He/ 1087 she can then act on behalf of one or both of these systems. 1089 If an attacker obtained a copy of the software image being deployed, 1090 he could potentially exploit a known vulnerability and gain access to 1091 the system. From a captured configuration file, he could obtain 1092 confidential network topology information or even more damaging 1093 information if any of the passwords in the configuration file were 1094 not encrypted. 1096 2.5.2. Security Practices 1098 Images and configurations are stored on specific hosts which have 1099 limited access. All access and activity relating to these hosts are 1100 authenticated and logged via AAA services. When uploaded/downloading 1101 any system software or configuration files, either TFTP, FTP or SCP 1102 can be used. Where possible, SCP is used to secure the data transfer 1103 and FTP is generally never used. All SCP access is username/password 1104 authenticated but since this requires an interactive shell, most ISPs 1105 will use shared key authentication to avoid the interactive shell. 1106 While TFTP access does not have any security measures, it is still 1107 widely used especially in OOB management scenarios. Some ISPs 1108 implement IP-based restriction on the TFTP server while some custom 1109 written TFTP servers will support MAC-based authentication. The MAC- 1110 based authentication is more common when using TFTP to bootstrap 1111 routers remotely. 1113 In most environments scripts are used for maintaining the images and 1114 configurations of a large number of routers. To ensure the integrity 1115 of the configurations, every hour the configuration files are polled 1116 and compared to the previously polled version to find discrepancies. 1117 In at least one environment these tools are Kerberized to take 1118 advantage of automated authentication (not confidentiality). 1119 'Rancid' is one popular publicly available tool for detecting 1120 configuration and system changes. 1122 Filters are used to limit access to uploading/downloading 1123 configuration files and system images to specific IP addresses and 1124 protocols. 1126 The software images perform CRC-checks and the system binaries use 1127 the MD5 algorithm to validate integrity. Many ISPs expressed 1128 interest in having software image integrity validation based on the 1129 MD5 algorithm for enhanced security. 1131 In all configuration files, most passwords are stored in an encrypted 1132 format. Note that the encryption techniques used in varying products 1133 can vary and that some weaker encryption schemes may be subject to 1134 off-line dictionary attacks. This includes passwords for user 1135 authentication, MD5-authentication shared secrets, AAA server shared 1136 secrets, NTP shared secrets, etc. For older software which may not 1137 support this functionality, configuration files may contain some 1138 passwords in readable format. Most ISPs mitigate any risk of 1139 password compromise by either storing these configuration files 1140 without the password lines or by requiring authenticated and 1141 authorized access to the configuration files which are stored on 1142 protected OOB management devices. 1144 Automated security validation is performed on infrastructure devices 1145 using nmap and nessus to ensure valid configuration against many of 1146 the well-known attacks. 1148 2.5.3. Security Services 1150 o User Authentication - All users are authenticated before being 1151 able to download/upload any system images or configuration files. 1153 o User Authorization - All authenticated users are granted specific 1154 privileges to download or upload system images and/or 1155 configuration files. 1157 o Data Origin Authentication - Filters are used to limit access to 1158 uploading/downloading configuration files and system images to 1159 specific IP addresses. 1161 o Access Control - Filters are used to limit access to uploading/ 1162 downloading configuration files and system images to specific IP 1163 addresses and protocols. 1165 o Data Integrity - All systems use either a CRC-check or MD5 1166 authentication to ensure data integrity. Also tools such as 1167 rancid are used to automatically detect configuration changes. 1169 o Data Confidentiality - If the SCP protocol is used then there is 1170 confidentiality of the downloaded/uploaded configuration files and 1171 system images. 1173 o Auditing / Logging - All access and activity relating to 1174 downloading/uploading system images and configuration files are 1175 logged via AAA services and filter exception rules. 1177 o DoS Mitigation - A combination of filtering and CRC-check / MD5- 1178 based integrity checks are used to mitigate the risks of DoS 1179 attacks. If the software updates and configuration changes are 1180 performed via an OOB management system, this is also added 1181 protection. 1183 2.5.4. Additional Considerations 1185 Where the MD5 algorithm is not used to perform data integrity 1186 checking of software images and configuration files, ISPs have 1187 expressed an interest in having this functionality. IPsec is 1188 considered too cumbersome and operationally difficult to use for data 1189 integrity and confidentiality. 1191 2.6. Logging Considerations 1193 Although logging is part of all the previous sections, it is 1194 important enough to be covered as a separate item. The main issues 1195 revolve around what gets logged, how long are logs kept and what 1196 mechanisms are used to secure the logged information while it is in 1197 transit and while it is stored. 1199 2.6.1. Threats / Attacks 1201 Attacks on the logged data can be both from passive or active 1202 sources. Passive attacks are possible if someone has the capability 1203 to intercept data between the recipient logging server and the device 1204 the logged data originated from. This can be accomplished if a 1205 single infrastructure device is somehow compromised and can act as a 1206 network sniffer or if it is possible to insert a new device which 1207 acts as a network sniffer. 1209 Active attacks are possible for both on-path and off-path scenarios. 1210 For on-path active attacks, the situation is the same as for a 1211 passive attack, where either a device has to already be compromised 1212 or a device can be inserted into the path. For off-path active 1213 attacks, the attacks are generally limited to message insertion or 1214 modification which can alter the logged data to keep any compromise 1215 from being detected or to destroy any evidence which could be used 1216 for criminal prosecution. 1218 2.6.1.1. Confidentiality Violations 1220 Confidentiality violations can occur when a miscreant intercepts any 1221 of the logging data which is in transit on the network. This could 1222 lead to privacy violations if some of the logged data has not been 1223 sanitized to disallow any data that could be a violation of privacy 1224 to be included in the logged data. 1226 2.6.1.2. Offline Cryptographic Attacks 1228 If any cryptographic mechanism was used to provide for data integrity 1229 and confidentiality, an offline cryptographic attack could 1230 potentially compromise the data. The traffic would need to be 1231 captured either by eavesdropping on the network or by being able to 1232 divert traffic to a malicious user. 1234 2.6.1.3. Replay Attacks 1236 For a replay attack to be successful, the logging data would need to 1237 first be captured either on-path or diverted to an attacker and later 1238 replayed to the recipient. 1240 2.6.1.4. Message Insertion/Deletion/Modification 1242 Logging data could be injected, deleted or modified by someone in 1243 control of intermediate hosts. Logging data can also be injected by 1244 forging packets from either legitimate or illegitimate IP addresses. 1246 2.6.1.5. Man-In-The-Middle 1248 A man-in-the-middle attack attacks the identity of a communicating 1249 peer rather than the data stream itself. The attacker intercepts 1250 traffic that is sent between the infrastructure device and the 1251 logging server or traffic sent between the logging server and the 1252 database which is used to archive the logged data. Any unauthorized 1253 access to logging information could lead to knowledge of private and 1254 proprietary network topology information which could be used to 1255 compromise portions of the network. An additional concern is having 1256 access to logging information which could be deleted or modified so 1257 as to cover any traces of a security breach. 1259 2.6.2. Security Practices 1261 Logging is mostly performed on an exception auditing basis when it 1262 comes to filtering (i.e. traffic which is NOT allowed is logged). 1263 This is to assure that the logging servers are not overwhelmed with 1264 data which would render most logs unusable. Typically the data 1265 logged will contain the source and destination IP addresses and layer 1266 4 port numbers as well as a timestamp. The syslog protocol is used 1267 to transfer the logged data between the infrastructure device to the 1268 syslog server. Many ISPs use the OOB management network to transfer 1269 syslog data since there is virtually no security performed between 1270 the syslog server and the device. All ISPs have multiple syslog 1271 servers - some ISPs choose to use separate syslog servers for varying 1272 infrastructure devices (i.e. one syslog server for backbone routers, 1273 one syslog server for customer edge routers, etc.) 1275 The timestamp is derived from NTP which is generally configured as a 1276 flat hierarchy at stratum1 and stratum2 to have less configuration 1277 and less maintenance. Consistency of configuration and redundancy is 1278 the primary goal. Each router is configured with several stratum1 1279 server sources, which are chosen to ensure that proper NTP time is 1280 available even in the event of varying network outages. 1282 In addition to logging filtering exceptions, the following is 1283 typically logged: Routing protocol state changes, all device access 1284 (regardless of authentication success or failure), all commands 1285 issued to a device, all configuration changes and all router events 1286 (boot-up/flaps). 1288 The main function of any of these log messages is to see what the 1289 device is doing as well as to try and ascertain what certain 1290 malicious attackers are trying to do. Since syslog is an unreliable 1291 protocol, when routers boot or lose adjacencies, not all messages 1292 will get delivered to the remote syslog server. Some vendors may 1293 implement syslog buffering (e.g., buffer the messages until you have 1294 a route to the syslog destination) but this is not standard. 1295 Therefore, operators often have to look at local syslog information 1296 on a device (which typically has very little memory allocated to it) 1297 to make up for the fact that the server-based syslog files can be 1298 incomplete. Some ISPs also put in passive devices to see routing 1299 updates and withdrawals and do not rely solely on the device for log 1300 files. This provides a backup mechanism to see what is going on in 1301 the network in the event that a device may 'forget' to do syslog if 1302 the CPU is busy. 1304 The logs from the various syslog server devices are generally 1305 transferred into databases at a set interval which can be anywhere 1306 from every 10 minutes to every hour. One ISP uses Rsync to push the 1307 data into a database and then the information is sorted manually by 1308 someone SSH'ing to that database. 1310 2.6.3. Security Services 1311 o User Authentication - Not applicable 1313 o User Authorization - Not applicable 1315 o Data Origin Authentication - Not implemented 1317 o Access Control - Filtering on logging host and server IP address 1318 to ensure that syslog information only goes to specific syslog 1319 hosts. 1321 o Data Integrity - Not implemented 1323 o Data Confidentiality - Not implemented 1325 o Auditing / Logging - This entire section deals with logging. 1327 o DoS Mitigation - An OOB management system is used and sometimes 1328 different syslog servers are used for logging information from 1329 varying equipment. Exception logging tries to keep information to 1330 a minimum. 1332 2.6.4. Additional Considerations 1334 There is no security with syslog and ISPs are fully cognizant of 1335 this. IPsec is considered too operationally expensive and cumbersome 1336 to deploy. Syslog-ng and stunnel are being looked at for providing 1337 better authenticated and integrity protected solutions. Mechanisms 1338 to prevent unauthorized personnel from tampering with logs is 1339 constrained to auditing who has access to the logging servers and 1340 files. 1342 ISPs expressed requirements for more than just UDP syslog. 1343 Additionally, they would like more granular and flexible facilities 1344 and priorities, i.e. specific logs to specific servers. Also, a 1345 common format for reporting standard events so that they don't have 1346 to modify parsers after each upgrade of vendor device or software. 1348 2.7. Filtering Considerations 1350 Although filtering has been covered under many of the previous 1351 sections, this section will provide some more insights to the 1352 filtering considerations that are currently being taken into account. 1353 Filtering is now being categorized into three specific areas: data 1354 plane, management plane and routing control plane. 1356 2.7.1. Data Plane Filtering 1358 Data plane filters control the traffic that traverses through a 1359 device and affect transit traffic. Most ISPs deploy these kinds of 1360 filters at the customer facing edge devices to mitigate spoofing 1361 attacks using BCP38 and BCP84 guidelines. 1363 2.7.2. Management Plane Filtering 1365 Management filters control the traffic to and from a device. All of 1366 the protocols which are used for device management fall under this 1367 category and includes SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP, 1368 SCP and Syslog. This type of traffic is often filtered per interface 1369 and is based on any combination of protocol, source and destination 1370 IP address and source and destination port number. Some devices 1371 support functionality to apply management filters to the device 1372 rather than to the specific interfaces (e.g. receive ACL or loopback 1373 interface ACL) which is gaining wider acceptance. Note that logging 1374 the filtering rules can today place a burden on many systems and more 1375 granularity is often required to more specifically log the required 1376 exceptions. 1378 Any services that are not specifically used are turned off. 1380 IPv6 networks require the use of specific ICMP messages for proper 1381 protocol operation. Therefore, ICMP cannot be completely filtered to 1382 and from a device. Instead, granular ICMPv6 filtering is always 1383 deployed to allow for specific ICMPv6 types to be sourced or destined 1384 to a network device. A good guideline for IPv6 filtering is in the 1385 draft work in progress on Recommendations for Filtering ICMPv6 1386 Messages in Firewalls [I-D.ietf-v6ops-icmpv6-filtering-recs]. 1388 2.7.3. Routing Control Plane Filtering 1390 Routing filters are used to control the flow of routing information. 1391 In IPv6 networks, some providers are liberal in accepting /48s due to 1392 the still unresolved multihoming issues while others filter at 1393 allocation boundaries which are typically at /32. Any announcement 1394 received that is longer than a /48 for IPv6 routing and a /24 for 1395 IPv4 routing is filtered out of eBGP. Note that this is for non- 1396 customer traffic. Most ISPs will accept any agreed upon prefix 1397 length from its customer(s). 1399 2.8. Denial of Service Tracking / Tracing 1401 Denial of Service attacks are an ever increasing problem and require 1402 vast amounts of resources to combat effectively. Some large ISPs do 1403 not concern themselves with attack streams that are less than 1G in 1404 bandwidth - this is on the larger pipes where 1G is essentially less 1405 than 5% of offered load. This is largely due to the large amounts of 1406 DDoS traffic which continually requires investigation and mitigation. 1407 At last count the number of hosts making up large distributed DoS 1408 botnets exceeded 1 million hosts. 1410 New techniques are continually evolving to automate the process of 1411 detecting DoS sources and mitigating any adverse effects as quickly 1412 as possible. At this time, ISPs are using a variety of mitigation 1413 techniques including: sink hole routing, black-hole triggered 1414 routing, uRPF, rate limiting and specific control plane traffic 1415 enhancements. Each of these techniques will be detailed below. 1417 2.8.1. Sink Hole Routing 1419 Sink hole routing refers to injecting a more specific route for any 1420 known attack traffic which will ensure that the malicious traffic is 1421 redirected to a valid device or specific system where it can be 1422 analyzed. 1424 2.8.2. Black-Hole Triggered Routing 1426 Black-hole triggered routing (also referred to as Remote Triggered 1427 Black Hole Filtering) is a technique where the BGP routing protocol 1428 is used to propagate routes which in turn redirects attack traffic to 1429 the null interface where it is effectively dropped. This technique 1430 is often used in large routing infrastructures since BGP can 1431 propagate the information in a fast effective manner as opposed to 1432 using any packet-based filtering techniques on hundreds or thousands 1433 of routers. [refer to the following NANOG presentation for a more 1434 complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf] 1436 Note that this black-holing technique may actually fulfill the goal 1437 of the attacker if the goal was to instigate blackholing traffic 1438 which appeared to come from a certain site. On the other hand, this 1439 blackhole technique can decrease the collateral damage caused by an 1440 overly large attack aimed at something other than critical services. 1442 2.8.3. Unicast Reverse Path Forwarding 1444 Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating 1445 whether an incoming packet has a legitimate source address or not. 1446 It has two modes: strict mode and loose mode. In strict mode, uRPF 1447 checks whether the incoming packet has a source address that matches 1448 a prefix in the routing table, and whether the interface expects to 1449 receive a packet with this source address prefix. If the incoming 1450 packet fails the unicast RPF check, the packet is not accepted on the 1451 incoming interface. Loose mode uRPF is not as specific and the 1452 incoming packet is accepted if there is any route in the routing 1453 table for the source address. 1455 While BCP84 [RFC3704] and a study on uRPF experiences 1456 [I-D.savola-bcp84-urpf-experiences] detail how asymmetry, i.e. 1457 multiple routes to the source of a packet, does not preclude applying 1458 feasible paths strict uRPF, it is generally not used on interfaces 1459 that are likely to have routing asymmetry. Usually for the larger 1460 ISPs, uRPF is placed at the customer edge of a network. 1462 2.8.4. Rate Limiting 1464 Rate limiting refers to allocating a specific amount of bandwidth or 1465 packets per second to specific traffic types. This technique is 1466 widely used to mitigate well-known protocol attacks such as the TCP- 1467 SYN attack where a large number of resources get allocated for 1468 spoofed TCP traffic. Although this technique does not stop an 1469 attack, it can sometimes lessen the damage and impact on a specific 1470 service. However, it can also make the impact of a DDoS attack much 1471 worse if the rate limiting is impacting (i.e. discarding) more 1472 legitimate traffic. 1474 2.8.5. Specific Control Plane Traffic Enhancements 1476 Some ISPs are starting to use capabilities which are available from 1477 some vendors to simplify the filtering and rate-limiting of control 1478 traffic. Control traffic here refers to the routing control plane 1479 and management plane traffic that requires CPU cycles. A DoS attack 1480 against any control plane traffic can therefore be much more damaging 1481 to a critical device than other types of traffic. No consistent 1482 deployment of this capability was found at the time of this writing. 1484 3. Security Considerations 1486 This entire document deals with current security practices in large 1487 ISP environments. It lists specific practices used in today's 1488 environments and as such does not in itself pose any security risk. 1490 4. IANA Considerations 1492 This document has no actions for IANA. 1494 5. Acknowledgments 1496 The editor gratefully acknowledges the contributions of: George 1497 Jones, who has been instrumental in providing guidance and direction 1498 for this document and the insighful comments from Ross Callon, Ron 1499 Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola, 1500 Fernando Gont, Chris Morrow, Ted Seely, Donald Smith and the numerous 1501 ISP operators who supplied the information which is depicted in this 1502 document. 1504 6. References 1506 6.1. Normative References 1508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1509 Requirement Levels", BCP 14, RFC 2119, March 1997. 1511 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1512 Defeating Denial of Service Attacks which employ IP Source 1513 Address Spoofing", BCP 38, RFC 2827, May 2000. 1515 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 1516 May 2000. 1518 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1519 Text on Security Considerations", BCP 72, RFC 3552, 1520 July 2003. 1522 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 1523 Security Mechanism (GTSM)", RFC 3682, February 2004. 1525 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1526 Networks", BCP 84, RFC 3704, March 2004. 1528 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 1529 Attacks", RFC 3882, September 2004. 1531 6.2. Informational References 1533 [I-D.ietf-v6ops-icmpv6-filtering-recs] 1534 Davies, E. and J. Mohacsi, "Recommendations for Filtering 1535 ICMPv6 Messages in Firewalls", 1536 draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in 1537 progress), July 2006. 1539 [I-D.lewis-infrastructure-security] 1540 Lewis, D., "Service Provider Infrastructure Security", 1541 draft-lewis-infrastructure-security-00 (work in progress), 1542 June 2006. 1544 [I-D.savola-bcp84-urpf-experiences] 1545 Savola, P., "Experiences from Using Unicast RPF", 1546 draft-savola-bcp84-urpf-experiences-01 (work in progress), 1547 June 2006. 1549 [I-D.savola-rtgwg-backbone-attacks] 1550 Savola, P., "Backbone Infrastructure Attacks and 1551 Protections", draft-savola-rtgwg-backbone-attacks-02 (work 1552 in progress), July 2006. 1554 Appendix A. Protocol Specific Attacks 1556 This section will list many of the traditional protocol based attacks 1557 which have been observed over the years to cause malformed packets 1558 and/or exploit protocol deficiencies. Note that they all exploit 1559 vulnerabilities in the actual protocol itself and often, additional 1560 authentication and auditing mechanisms are now used to detect and 1561 mitigate the impact of these attacks. The list is not exhaustive but 1562 is a fraction of the representation of what types of attacks are 1563 possible for varying protocols. 1565 A.1. Layer 2 Attacks 1567 o ARP Flooding 1569 A.2. IPv4 Protocol Based Attacks 1571 o IP Addresses, either source or destination, can be spoofed which 1572 in turn can circumvent established filtering rules. 1574 o IP Source Route Option can allows attackers to establish stealth 1575 TCP connections 1577 o IP Record Route Option can discloses information about the 1578 topology of the network. 1580 o IP header that is too long or too short can cause DoS attacks to 1581 devices. 1583 o IP Timestamp Option can leak information which can be used to 1584 discern network behavior. 1586 o Fragmentation attacks which can vary widely - more detailed 1587 information can be found at http://www-src.lip6.fr/homepages/ 1588 Fabrice.Legond-Aubry/www.ouah.org/fragma.html 1590 o IP ToS field (or the Differentiated Services (DSCP) field) can be 1591 used to reroute or reclassify traffic based on specified 1592 precedence. 1594 o IP checksum field has been used for scanning purposes, for example 1595 when some firewalls did not check the checksum and allowed an 1596 attacker to differentiate when the response came from an end- 1597 system, and when from a firewall 1599 o IP TTL field can be used to bypass certain network based intrusion 1600 detection systems and to map network behavior. 1602 A.2.1. Higher Layer Protocol Attacks 1604 The following lists additional attacks but does not explicitly 1605 numerate them in detail. It is for informational purposes only. 1607 o IGMP oversized packet 1609 o ICMP Source Quench 1611 o ICMP Mask Request 1613 o ICMP Large Packet (> 1472) 1615 o ICMP Oversized packet (>65536) 1617 o ICMP Flood 1619 o ICMP Broadcast w/ Spoofed Source (Smurf Attack) 1621 o ICMP Error Packet Flood 1623 o ICMP Spoofed Unreachable 1625 o TCP Packet without Flag 1627 o TCP Oversized Packet 1629 o TCP FIN bit with no ACK bit 1631 o TCP Packet with URG/OOB flag (Nuke Attack) 1633 o SYN Fragments 1635 o SYN Flood 1637 o SYN with IP Spoofing (Land Attack) 1639 o SYN and FIN bits set 1641 o TCP port scan attack 1643 o UDP spoofed broadcast echo (Fraggle Attack) 1644 o UDP attack on diagnostic ports (Pepsi Attack) 1646 A.3. IPv6 Attacks 1648 Any of the above-mentioned IPv4 attacks could be used in IPv6 1649 networks with the exception of any fragmentation and broadcast 1650 traffic, which operate differently in IPv6. Note that all of these 1651 attacks are based on either spoofing or misusing any part of the 1652 protocol field(s). 1654 Today, IPv6 enabled hosts are starting to be used to create IPv6 1655 tunnels which can effectively hide botnet and other malicious traffic 1656 if firewalls and network flow collection tools are not capable of 1657 detecting this traffic. The security measures used for protecting 1658 IPv6 infrastructures should be the same as in IPv4 networks but with 1659 additional considerations for IPv6 network operations which may be 1660 different from IPv4. 1662 Author's Address 1664 Merike Kaeo 1665 Double Shot Security, Inc. 1666 3518 Fremont Avenue North #363 1667 Seattle, WA 98103 1668 U.S.A. 1670 Phone: +1 310 866 0165 1671 Email: merike@doubleshotsecurity.com 1673 Full Copyright Statement 1675 Copyright (C) The Internet Society (2006). 1677 This document is subject to the rights, licenses and restrictions 1678 contained in BCP 78, and except as set forth therein, the authors 1679 retain all their rights. 1681 This document and the information contained herein are provided on an 1682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1684 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1685 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1686 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1689 Intellectual Property 1691 The IETF takes no position regarding the validity or scope of any 1692 Intellectual Property Rights or other rights that might be claimed to 1693 pertain to the implementation or use of the technology described in 1694 this document or the extent to which any license under such rights 1695 might or might not be available; nor does it represent that it has 1696 made any independent effort to identify any such rights. Information 1697 on the procedures with respect to rights in RFC documents can be 1698 found in BCP 78 and BCP 79. 1700 Copies of IPR disclosures made to the IETF Secretariat and any 1701 assurances of licenses to be made available, or the result of an 1702 attempt made to obtain a general license or permission for the use of 1703 such proprietary rights by implementers or users of this 1704 specification can be obtained from the IETF on-line IPR repository at 1705 http://www.ietf.org/ipr. 1707 The IETF invites any interested party to bring to its attention any 1708 copyrights, patents or patent applications, or other proprietary 1709 rights that may cover technology that may be required to implement 1710 this standard. Please address the information to the IETF at 1711 ietf-ipr@ietf.org. 1713 Acknowledgment 1715 Funding for the RFC Editor function is provided by the IETF 1716 Administrative Support Activity (IASA).