idnits 2.17.1 draft-ietf-opsec-current-practices-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1753. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 5, 2006) is 6498 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IRR' is mentioned on line 1118, but not defined == Unused Reference: 'I-D.lewis-infrastructure-security' is defined on line 1599, but no explicit reference was found in the text == Unused Reference: 'I-D.savola-bcp84-urpf-experiences' is defined on line 1604, but no explicit reference was found in the text == Unused Reference: 'I-D.savola-rtgwg-backbone-attacks' is defined on line 1609, 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-savola-bcp84-urpf-experiences-01 == Outdated reference: A later version (-03) exists of draft-savola-rtgwg-backbone-attacks-01 Summary: 6 errors (**), 0 flaws (~~), 9 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 Expires: January 6, 2007 July 5, 2006 6 Operational Security Current Practices 7 draft-ietf-opsec-current-practices-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 6, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document is a survey of the current practices used in today's 41 large ISP operational networks to secure layer 2 and layer 3 42 infrastructure devices. The information listed here is the result of 43 information gathered from people directly responsible for defining 44 and implementing secure infrastructures in Internet Service Provider 45 environments. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 53 1.4. Operational Security Impact from Threats . . . . . . . . . 5 54 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 55 1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 56 2. Protected Operational Functions . . . . . . . . . . . . . . . 9 57 2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9 58 2.2. Device In-Band Management . . . . . . . . . . . . . . . . 11 59 2.3. Device Out-of-Band Management . . . . . . . . . . . . . . 15 60 2.4. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 20 61 2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 22 62 2.6. Software Upgrades and Configuration Integrity / 63 Validation . . . . . . . . . . . . . . . . . . . . . . . . 26 64 2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 29 65 2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 32 66 2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 33 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 35 68 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 69 4.1. Normative References . . . . . . . . . . . . . . . . . . . 36 70 4.2. Informational References . . . . . . . . . . . . . . . . . 36 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 72 Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 38 73 B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 38 74 B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38 75 B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 39 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 77 Intellectual Property and Copyright Statements . . . . . . . . . . 42 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 is 110 subject to a multitude of threat actions, or attacks, i.e. an assault 111 on system security that derives from an intelligent act that is a 112 deliberate attempt to evade security services and violate the 113 security policy of a system [RFC2828]. All of the threats in any 114 network infrastructure is an instantiation or combination of the 115 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 deficiencies to cause inappropriate behavior. 129 Message Insertion: This can be a valid message (which could be a 130 reply attack, which is a scenario where a message is captured and 131 resent at later time). A message can also be inserted with any of 132 the fields in the message being OspoofedO, such as IP addresses, port 133 numbers, header fields or even packet content. Flooding is also part 134 of this threat instantiation. 136 Message Diversion/Deletion: An attack where legitimate messages are 137 removed before they can reach the desired recipient or are re- 138 directed to a network segment that is normally not part of the data 139 path. 141 Message Modification: This is a subset of a message insertion attack 142 where a previous message has been captured and modified before being 143 retransmitted. The message can be captured by using a man-in-the- 144 middle attack or message diversion. 146 Note that sometimes Denial of service attacks are listed as separate 147 categories. A denial of service is a consequence of an attack and 148 can be the result of too much traffic (i.e. flooding), or exploiting 149 protocol exploitation or inserting/deleting/diverting/modifying 150 messages. 152 1.3. Attack Sources 154 These attacks can be sourced in a variety of ways: 156 Active vs passive attacks 158 An active attack involves writing data to the network. It is 159 common practice in active attacks to disguise one's address and 160 conceal the identity of the traffic sender. A passive attack 161 involves only reading information off the network. This is 162 possible if the attacker has control of a host in the 163 communications path between two victim machines or has compromised 164 the routing infrastructure to specifically arrange that traffic 165 pass through a compromised machine. In general, the goal of a 166 passive attack is to obtain information that the sender and 167 receiver would prefer to remain private. [RFC3552] 169 On-path vs off-path attacks 170 In order for a datagram to be transmitted from one host to 171 another, it generally must traverse some set of intermediate links 172 and routers. Such routers are naturally able to read, modify, or 173 remove any datagram transmitted along that path. This makes it 174 much easier to mount a wide variety of attacks if you are on-path. 175 Off-path hosts can transmit arbitrary datagrams that appear to 176 come from any hosts but cannot necessarily receive datagrams 177 intended for other hosts. Thus, if an attack depends on being 178 able to receive data, off-path hosts must first subvert the 179 topology in order to place themselves on-path. This is by no 180 means impossible but is not necessarily trivial. [RFC3552] 182 Insider or outsider attacks 184 An "insider attack" is one which is initiated from inside a given 185 security perimeter, by an entity that is authorized to access 186 system resources but uses them in a way not approved by those who 187 granted the authorization. An "outside attack" is initiated from 188 outside the perimeter, by an unauthorized or illegitimate user of 189 the system. 191 Deliberate attacks vs unintentional events 193 A deliberate attack is one where a miscreant intentionally 194 performs an assault on system security. However, there are also 195 instances where unintentional events cause the same harm yet are 196 performed without malice in mind. Configuration errors and 197 software bugs can be as devastating to network availability as any 198 deliberate attack on the network infrastructure. 200 The attack source can be a combination of any of the above, all of 201 which need to be considered when trying to ascertain what impact any 202 attack can have on the availability and reliability of the network. 203 It is nearly impossible to stop insider attacks or unintentional 204 events. However, if appropriate monitoring mechanisms are in place, 205 these attacks can be as easily detected and mitigated as with any 206 other attack source. Any of the specific attacks discussed further 207 in this document will elaborate on attacks which are sourced by an 208 "outsider" and are deliberate attacks. Some further elaboration will 209 be given to the feasibility of passive vs active and on-path vs off- 210 path attacks to show the motivation behind deploying certain security 211 features. 213 1.4. Operational Security Impact from Threats 215 The main concern for any of the potential attack scenarios is the 216 impact and harm it can cause to the network infrastructure. The 217 threat consequences are the security violations which results from a 218 threat action, i.e. an attack. These are typically classified as 219 follows: 221 (Unauthorized) Disclosure 223 A circumstance or event whereby an entity gains access to data for 224 which the entity is not authorized. 226 Deception 228 A circumstance or event that may result in an authorized entity 229 receiving false data and believing it to be true. 231 Disruption 233 A circumstance or event that interrupts or prevents the correct 234 operation of system services and functions. A broad variety of 235 attacks, collectively called denial of service attacks, threaten 236 the availability of systems and bandwidth to legitimate users. 237 Many such attacks are designed to consume machine resources, 238 making it difficult or impossible to serve legitimate users. 239 Other attacks cause the target machine to crash, completely 240 denying service to users. 242 Usurpation 244 A circumstance or event that results in control of system services 245 or functions by an unauthorized entity. Most network 246 infrastructure systems are only intended to be completely 247 accessible to certain authorized individuals. Should an 248 unauthorized person gain access to critical layer 2 / layer 3 249 infrastructure devices or services, they could cause great harm to 250 the reliability and availability of the network. 252 A complete description of threat actions that can cause these threat 253 consequences can be found in [RFC2828]. Typically, a number of 254 different network attacks are used in combination to cause one or 255 more of the above mentioned threat consequences. An example would be 256 a malicious user who has the capability to eavesdrop on traffic. 257 First, he may listen in on traffic for a while to do some 258 reconnaissance work and ascertain which IP addresses belonged to 259 specific devices such as routers. Were this miscreant to obtain 260 information such as a router password sent in cleartext, he can then 261 proceed to compromise the actual router. From there, the miscreant 262 can launch various active attacks such as sending bogus routing 263 updates to redirect traffic or capture additional traffic to 264 compromise other network devices. 266 1.5. Document Layout 268 This document is a survey of current operational practices that 269 mitigate the risk of being susceptible to any threat actions. As 270 such, the main focus is on the currently deployed security practices 271 used to detect and/or mitigate attacks. The top-level categories in 272 this document are based on operational functions for ISPs and 273 generally relate to what is to be protected. This is followed by a 274 description of which attacks are possible and the security practices 275 currently deployed which will provide the necessary security services 276 to help mitigate these attacks. These security services are 277 classified as: 279 o User Authentication 281 o User Authorization 283 o Data Origin Authentication 285 o Access Control 287 o Data Integrity 289 o Data Confidentiality 291 o Auditing / Logging 293 o DoS Mitigation 295 In many instances, a specific protocol currently deployed will offer 296 a combination of these services. For example, AAA can offer user 297 authentication, user authorization and audit / logging services while 298 SSH can provide data origin authentication, data integrity and data 299 confidentiality. The services offered are more important than the 300 actual protocol used. Each section ends with an additional 301 considerations section which explains why specific protocols may or 302 may not be used and also gives some information regarding 303 capabilities which are not possible today due to bugs or lack of ease 304 of use. 306 1.6. Definitions 308 RFC 2119 Keywords 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 311 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 312 in this document are to be interpreted as described in [RFC2119]. 314 The use of the RFC 2119 keywords is an attempt, by the editor, to 315 assign the correct requirement levels ("MUST", "SHOULD", 316 "MAY"...). It must be noted that different organizations, 317 operational environments, policies and legal environments will 318 generate different requirement levels. 320 2. Protected Operational Functions 322 2.1. Device Physical Access 324 Device physical access pertains to protecting the physical location 325 and access of the layer 2 or layer 3 network infrastructure device. 326 Physical security is a large field of study/practice in and of 327 itself, arguably the largest. oldest and most well understood area of 328 security. Although it is important to have contingency plans for 329 natural disasters such as earthquakes and floods which can cause 330 damage to networking devices, this is out-of-scope for this document. 331 Here we concern ourselves with protecting access to the physical 332 location and how a device can be further protected from unauthorized 333 access if the physical location has been compromised, i.e protecting 334 the console access. This is aimed largely at stopping an intruder 335 with physical access from gaining operational control of the 336 device(s). Note that nothing will stop an attacker with physical 337 access from effecting a denial of service attack, which can be easily 338 accomplished by powering off the device or just unplugging some 339 cables. 341 2.1.1. Threats / Attacks 343 If any intruder gets physical access to a layer 2 or layer 3 device, 344 the entire network infrastructure can be under the control of the 345 intruder. At a minimum, the intruder can take the compromised device 346 out-of-service, causing network disruption, the extent of which 347 depends on the network topology. A worse scenario is where the 348 intruder can use this device to crack the console password and have 349 complete control of the device, perhaps without anyone detecting such 350 a compromise, or to attach another network device onto a port and 351 siphon off data with which the intruder can ascertain the network 352 topology and take control of the entire network. 354 The threat of gaining physical access can be realized in a variety of 355 ways even if critical devices are under high-security. There still 356 occur cases where attackers have impersonated maintenance workers to 357 gain physical access to critical devices that have caused major 358 outages and privacy compromises. Insider attacks from authorized 359 personnel also pose a real threat and must be adequately recognized 360 and dealt with. 362 2.1.2. Security Practices 364 For physical device security, equipment is kept in highly restrictive 365 environments. Only authorized users with card key badges have access 366 to any of the physical locations that contain critical network 367 infrastructure devices. These card-key systems keep track of who 368 accessed which location and at what time. 370 All console access is always password protected and the login time is 371 set to time out after a specified amount of inactivity - typically 372 between 3-10 minutes. Individual users are authentication to get 373 basic access. For privileged (i.e. enable) access, a second 374 authentication step needs to be completed. Typically all console 375 access is provided via an out-of-band (OOB) management infrastructure 376 which is discussed in the section on OOB management. 378 2.1.3. Security Services 380 The following security services are offered through the use of the 381 practices described in the previous section: 383 o User Authentication - All individuals who have access to the 384 physical facility are authenticated. Console access is 385 authenticated. 387 o User Authorization - An authenticated individual has implicit 388 authorization to perform commands on the device. Console access 389 is usually granted via at least two privilege levels: 390 authorization for performing a basic set of commands vs 391 authorization for performing all commands. 393 o Data Origin Authentication - Not applicable 395 o Access Control - Not applicable 397 o Data Integrity - Not applicable 399 o Data Confidentiality - Not applicable 401 o Auditing / Logging - All access to the physical locations of the 402 infrastructure equipment is logged via electronic card-key 403 systems. All console access is logged (refer to the OOB 404 management section for more details) 406 o DoS Mitigation - Not applicable 408 2.1.4. Additional Considerations 410 Physical security is relevant to operational security practices as 411 described in this document mostly from a console access perspective. 412 Most ISPs provide console access via an OOB management infrastructure 413 which is discussed in the OOB management section of this document. 415 The physical and logical authentication and logging systems should be 416 run independently of each other and reside in different physical 417 locations. These systems need to be secured to ensure that they 418 themselves will not be compromised which could give the intruder 419 valuable authentication and logging information. 421 Social engineering plays a big role in many physical access 422 compromises. Most ISPs have set up training classes and awareness 423 programs to educate company personnel to deny physical access to 424 people who are not properly authenticated or authorized to have 425 physical access to critical infrastructure devices. 427 2.2. Device In-Band Management 429 In-band management is generally considered to be device access where 430 the control traffic takes the same data path as the data which 431 traverses the network. In many environments, device management for 432 layer 2 and layer 3 infrastructure devices is deployed as part of an 433 out-of-band management infrastructure although there are some 434 instances where it is deployed in-band as well. Presently, the 435 mechanisms used for in-band management are via virtual terminal 436 access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISPs that 437 were interviewed, HTTP management is never used and is explicitly 438 disabled. Note that file transfer protocols (TFTP, FTP, SCP) will be 439 covered in the 'Software Upgrades and Configuration Integrity/ 440 Validation' section. 442 2.2.1. Threats / Attacks 444 For in-band device management, passive attacks are possible if 445 someone has the capability to intercept data between the management 446 device and the managed device. The threat is possible if a single 447 infrastructure device is somehow compromised and can act as a network 448 sniffer or if it is possible to insert a new device which acts as a 449 network sniffer. 451 Active attacks are possible for both on-path and off-path scenarios. 452 For on-path active attacks, the situation is the same as for a 453 passive attack, where either a device has to already be compromised 454 or a device can be inserted into the path. For off-path active 455 attacks, the attack is generally limited to message insertion or 456 modification. 458 2.2.1.1. Confidentiality Violations 460 Confidentiality violations can occur when a miscreant intercepts 461 confidential data that has been sent in cleartext. This includes 462 interception of usernames and passwords with which an intruder can 463 obtain unauthorized access to network devices. It can also include 464 other information such as logging or configuration information if an 465 administrator is remotely viewing local logfiles or configuration 466 information. 468 2.2.1.2. Offline Cryptographic Attacks 470 If username/password information was encrypted but the cryptographic 471 mechanism used made it easy to capture data and break the encryption 472 key, the device management traffic could be compromised. The traffic 473 would need to be captured either by eavesdropping on the network or 474 by being able to divert traffic to a malicious user. 476 2.2.1.3. Replay Attacks 478 For a replay attack to be successful, in-band management traffic 479 would need to first be captured either on-path or diverted to an 480 attacker to later be replayed to the intended recipient. 482 2.2.1.4. Message Insertion/Deletion/Modification 484 Data can be manipulated by someone in control of intermediary hosts. 485 Forging data is also possible with IP spoofing, where a remote host 486 sends out packets which appear to come from another, trusted host. 488 2.2.1.5. Man-In-The-Middle 490 A man-in-the-middle attack attacks the identity of a communicating 491 peer rather than the data stream itself. The attacker intercepts 492 traffic that is sent from an in-band management system to the 493 networking infrastructure device and traffic that is sent from the 494 network infrastructure device to the in-band management system. 496 2.2.2. Security Practices 498 All in-band management access to layer 2 and layer 3 devices is 499 authenticated. The user authentication and authorization is 500 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 501 Credentials used to determine the identity of the user vary from 502 static username/password to one-time username/password scheme such as 503 Secure-ID. Static username/passwords are expired after a specified 504 period of time, usually 30 days. Every authenticated entity via AAA 505 is an individual user for greater granularity of control. In some 506 deployments, the AAA servers used for in-band management 507 authentication/authorization/accounting are on separate out-of-band 508 networks to provide a demarcation for any other authentication 509 functions. 511 For backup purposes, there is often a single local database entry for 512 authentication which is known to a very limited set of key personnel. 513 It is usually the highest privilege level username/password 514 combination, which in most cases is the same across all devices. 515 This local device password is routinely regenerated once every 2-3 516 months and is also regenerated immediately after an employee who had 517 access to that password leaves the company or is no longer authorized 518 to have knowledge of that password. 520 Each individual user in the AAA database is configured with specific 521 authorization capability. Specific commands are either individually 522 denied or permitted depending on the capability of the device to be 523 accessed. Multiple privilege levels are deployed. Most individuals 524 are authorized with basic authorization to perform a minimal set of 525 commands while a subset of individuals are authorized to perform more 526 privileged commands. Securing the AAA server is imperative and 527 access to the AAA server itself is strictly controlled. When an 528 individual leaves the company, his/her AAA account is immediately 529 deleted and the TACACS/RADIUS shared secret is reset for all devices. 531 SSH is always used for virtual terminal access to provide for an 532 encrypted communication channel. There are exceptions due to 533 equipment limitations which are described in the additional 534 considerations section. 536 If SNMP is used for in-band management, it is for read queries only 537 and restricted to specific hosts. If possible, the view is also 538 restricted to only send the information that the management station 539 needs rather than expose the entire configuration file with the read- 540 only SNMP community. The community strings are carefully chosen to 541 be difficult to crack and there are procedures in place to change 542 these community strings between 30-90 days. If systems support two 543 SNMP community strings, the old string is replaced by first 544 configuring a second newer community string and then migrating over 545 from the currently used string to the newer one. Most large ISPs 546 have multiple SNMP systems accessing their routers so it takes more 547 then one maintenance period to get all the strings fixed in all the 548 right systems. SNMP RW is not used and disabled by configuration. 550 Access control is strictly enforced for infrastructure devices by 551 using stringent filtering rules. A limited set of IP addresses are 552 allowed to initiate connections to the infrastructure devices and are 553 specific to the services which they are to limited to (i.e. SSH and 554 SNMP). 556 All in-band device management access is audited and any violations 557 trigger alarms which initiate automated email, pager and/or telephone 558 notifications. AAA servers keeps track of the authenticated entity 559 as well as all the commands that were carried out on a specific 560 device. Additionally, the device itself logs any access control 561 violations (i.e. if an SSH request comes in from an IP address which 562 is not explicitly permitted, that event is logged so that the 563 offending IP address can be tracked down and investigations made as 564 to why it was trying to access a particular infrastructure device) 566 2.2.3. Security Services 568 The following security services are offered through the use of the 569 practices described in the previous section: 571 o User Authentication - All individuals are authenticated via AAA 572 services. 574 o User Authorization - All individuals are authorized via AAA 575 services to perform specific operations once successfully 576 authenticated. 578 o Data Origin Authentication - Management traffic is strictly 579 filtered to allow only specific IP addresses to have access to the 580 infrastructure devices. This does not alleviate risk from spoofed 581 traffic. Using SSH for device access ensures that noone can spoof 582 the traffic during the SSH session. 584 o Access Control - In-band management traffic is filtered to allow 585 only specific IP addresses to have access to the infrastructure 586 devices. 588 o Data Integrity - Using SSH provides data integrity and ensures 589 that no one has altered the management data in transit. 591 o Data Confidentiality - Using SSH provides data confidentiality. 593 o Auditing / Logging - Using AAA provides an audit trail for who 594 accessed which device and which operations were performed. 596 o DoS Mitigation - Using packet filters to allow only specific IP 597 addresses to have access to the infrastructure devices. This 598 limits but does not prevent spoofed DoS attacks directed at an 599 infrastructure device. Often OOB management is used to lower that 600 risk. 602 2.2.4. Additional Considerations 604 Password selection for any in-band device management protocol used is 605 critical to ensure that the passwords are hard to guess or break 606 using a brute-force attack. 608 IPsec is considered too difficult to deploy and the common protocol 609 to provide for confidential in-band management access is SSH. There 610 are exceptions for using SSH due to equipment limitations since SSH 611 may not be supported on legacy equipment. Also, in the case where 612 the SSH key is stored on a route processor card, a re-keying of SSH 613 would be required whenever the route processor card needs to be 614 swapped. Some providers feel that this operational impact exceeds 615 the security necessary and instead use Telnet from trusted inside 616 hosts (called 'jumphosts' or 'bastion hosts') to manage those 617 devices. An individual would first SSH to the jumphost and then 618 Telnet from the jumphost to the actual infrastructure device, fully 619 understanding that any passwords will be sent in the clear between 620 the jumphost and the device it is connecting to. All authentication 621 and authorization is still carried out using AAA servers. 623 In instances where Telnet access is used, the logs on the AAA servers 624 are more verbose and more attention is paid to them to detect any 625 abnormal behavior. The jumphosts themselves are carefully controlled 626 machines and usually have limited access. Note that Telent is NEVER 627 allowed to an infrastructure device except from specific jumphosts; 628 i.e. packet filters are used to ensure that Telnet is only allowed 629 from specific IP addresses. 631 With thousands of devices to manage, some ISPs have created automated 632 mechanisms to authenticate to devices. Kerberos is used to automate 633 the authentication process. An individual would first log in to a 634 Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. 635 This 'ticket' is generally set to have a lifespan of 10 hours and is 636 used to automatically authenticate the individual to the 637 infrastructure devices. 639 In instances where SNMP is used, some legacy devices only support 640 SNMPv1 which then requires the provider to mandate its use across all 641 infrastructure devices for operational simplicity. SNMPv2 is 642 primarily deployed since it is easier to set up than v3. 644 2.3. Device Out-of-Band Management 646 Out-of-band management is generally considered to be device access 647 where the control traffic takes a separate path as the data which 648 traverses the network. Console access is always architected via an 649 OOB network. SNMP management is also usually carried out via that 650 same OOB network infrastructure. Note that many of the security 651 concerns and practices are the same for OOB management and in-band 652 management. Most ISPs prefer an OOB management system since access 653 to the devices which make up this management network are more 654 vigilantly protected and considered to be less susceptible to 655 malicious activity. 657 2.3.1. Threats / Attacks 659 For OOB device management, passive attacks are possible if someone 660 has the capability to intercept data between the management device 661 and the managed device. The threat is possible if a single 662 infrastructure device is somehow compromised and can act as a network 663 sniffer or if it is possible to insert a new device which acts as a 664 network sniffer. 666 Active attacks are possible for both on-path and off-path scenarios. 667 For on-path active attacks, the situation is the same as for a 668 passive attack, where either a device has to already be compromised 669 or a device can be inserted into the path. For off-path active 670 attacks, the attack is generally limited to message insertion or 671 modification. 673 2.3.1.1. Confidentiality Violations 675 Confidentiality violations can occur when a miscreant intercepts any 676 of the OOB management data that has been sent in cleartext. This 677 includes interception of usernames and passwords with which an 678 intruder can obtain unauthorized access to network devices. It can 679 also include other information such as logging or configuration 680 information if an administrator is remotely viewing local logfiles or 681 configuration information. 683 2.3.1.2. Offline Cryptographic Attacks 685 If username/password information was encrypted but the cryptographic 686 mechanism used made it easy to capture data and break the encryption 687 key, the OOB management traffic could be compromised. The traffic 688 would need to be captured either by eavesdropping on the network or 689 by being able to divert traffic to a malicious user. 691 2.3.1.3. Replay Attacks 693 For a replay attack to be successful, the OOB management traffic 694 would need to first be captured either on-path or diverted to an 695 attacker to later be replayed to the intended recipient. 697 2.3.1.4. Message Insertion/Deletion/Modification 699 Data can be manipulated by someone in control of intermediary hosts. 700 Forging data is also possible with IP spoofing, where a remote host 701 sends out packets which appear to come from another, trusted host. 703 2.3.1.5. Man-In-The-Middle 705 A man-in-the-middle attack attacks the identity of a communicating 706 peer rather than the data stream itself. The attacker intercepts 707 traffic that is sent from an OOB management system to the networking 708 infrastructure device and traffic that is sent from the network 709 infrastructure device to the OOB management system. 711 2.3.2. Security Practices 713 OOB is done via a terminal server at each location. SSH access is 714 used to get to the terminal server from where sessions to the devices 715 are initiated. Dial-in access is deployed as a backup if the network 716 is not available however, it is common to use dial-back, encrypting 717 modems and/or one-time-password (OTP) modems to avoid the security 718 weaknesses of plain dial-in access. 720 All OOB management access to layer 2 and layer 3 devices is 721 authenticated. The user authentication and authorization is 722 typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). 723 Credentials used to determine the identity of the user vary from 724 static username/password to one-time username/password scheme such as 725 Secure-ID. Static username/passwords are expired after a specified 726 period of time, usually 30 days. Every authenticated entity via AAA 727 is an individual user for greater granularity of control. Note that 728 often the AAA server used for OOB management authentication is a 729 separate physical device from the AAA server used for in-band 730 management user authentication. 732 For backup purposes, there is often a single local database entry for 733 authentication which is known to a very limited set of key personnel. 734 It is usually the highest privilege level username/password 735 combination, which in most cases is the same across all devices. 736 This local device password is routinely regenerated once every 2-3 737 months and is also regenerated immediately after an employee who had 738 access to that password leaves the company or is no longer authorized 739 to have knowledge of that password. 741 Each individual user in the AAA database is configured with specific 742 authorization capability. Specific commands are either individually 743 denied or permitted depending on the capability of the device to be 744 accessed. Multiple privilege levels are deployed. Most individuals 745 are authorized with basic authorization to perform a minimal set of 746 commands while a subset of individuals are authorized to perform more 747 privileged commands. 749 Some OOB management functions are performed using command line 750 interface (CLI) scripting. In these scenarios, a dedicated user is 751 used for the identity in scripts that perform CLI scripting. Once 752 authenticated, these scripts control which commands are legitimate 753 depending on authorization rights of the authenticated individual. 755 SSH is always used for virtual terminal access to provide for an 756 encrypted communication channel. There are exceptions due to 757 equipment limitations which are described in the additional 758 considerations section. 760 If SNMP is used for OOB management, it is for read queries only and 761 restricted to specific hosts. The community strings are carefully 762 chosen to be difficult to crack and there are procedures in place to 763 change these community strings between 30-90 days. If systems 764 support two SNMP strings, a second new string is set and then migrate 765 over from the 1st to the 2nd. Most large ISPs have multiple SNMP 766 systems accessing their routers so it takes more then one maintenance 767 period to get all the strings fixed in all the right systems. SNMP 768 RW is not used and disabled by configuration. 770 Access control is strictly enforced for infrastructure devices by 771 using stringent filtering rules. A limited set of IP addresses are 772 allowed to initiate connections to the infrastructure devices and are 773 specific to the services which they are to limited to (i.e. SSH and 774 SNMP). 776 All OOB device management access is audited. The AAA server keeps 777 track of the authenticated entity as well as all the commands that 778 were carried out on a specific device. Additionally, the device 779 itself logs any access control violations (i.e. if an SSH request 780 comes in from an IP address which is not explicitly permitted, that 781 event is logged so that the offending IP address can be tracked down 782 and investigations made as to why it was trying to access a 783 particular infrastructure device) 785 2.3.3. Security Services 787 The security services offered for device OOB management are nearly 788 identical to those of device in-band management. Due to the critical 789 nature of controlling and limiting device access, many ISPs feel that 790 physically separating the management traffic from the normal customer 791 data traffic will provide an added level of risk mitigation and limit 792 the potential attack vectors. For OOB management, the security 793 services offered through the use of the practices described in the 794 previous section are: 796 o User Authentication - All individuals are authenticated via AAA 797 services. 799 o User Authorization - All individuals are authorized via AAA 800 services to perform specific operations once successfully 801 authenticated. 803 o Data Origin Authentication - Management traffic is strictly 804 filtered to allow only specific IP addresses to have access to the 805 infrastructure devices. This does not alleviate risk from spoofed 806 traffic. Using SSH for device access ensures that noone can spoof 807 the traffic during the SSH session. 809 o Access Control - In-band management traffic is filtered to allow 810 only specific IP addresses to have access to the infrastructure 811 devices. 813 o Data Integrity - Using SSH provides data integrity and ensures 814 that noone has altered the management data in transit. 816 o Data Confidentiality - Using SSH provides data confidentiality. 818 o Auditing / Logging - Using AAA provides an audit trail for who 819 accessed which device and which operations were performed. 821 o DoS Mitigation - Using packet filters to allow only specific IP 822 addresses to have access to the infrastructure devices. This 823 limits but does not prevent spoofed DoS attacks directed at an 824 infrastructure device. However, the risk is lowered by using a 825 separate physical network for management purposes. 827 2.3.4. Additional Considerations 829 Password selection for any OOB device management protocol used is 830 critical to ensure that the passwords are hard to guess or break 831 using a brute-force attack. 833 IPsec is considered too difficult to deploy and the common protocol 834 to provide for confidential OOB management access is SSH. There are 835 exceptions for using SSH due to equipment limitations since SSH may 836 not be supported on legacy equipment. In some cases changing the 837 hostname of a device requires an SSH rekey event since the key is 838 based on some combination of host name, MAC address and time. Also, 839 in the case where the SSH key is stored on a route processor card, a 840 re-keying of SSH would be required whenever the route processor card 841 needs to be swapped. Some providers feel that some of these 842 operational impacts exceed the security necessary and instead use 843 Telnet from trusted inside hosts (called 'jumphosts') to manage those 844 device. An individual would first SSH to the jumphost and then 845 Telnet from the jumphost to the terminal server before logging in to 846 the device console. All authentication and authorization is still 847 carried out using AAA servers. 849 In instances where Telnet access is used, the logs on the AAA servers 850 are more verbose and more attention is paid to them to detect any 851 abnormal behavior. The jumphosts themselves are carefully controlled 852 machines and usually have limited access. Note that Telent is NEVER 853 allowed to an infrastructure device except from specific jumphosts; 854 i.e. packet filters are used at the console server and/or 855 infrastructure device to ensure that Telnet is only allowed from 856 specific IP addresses. 858 In instances where SNMP is used, some legacy devices only support 859 SNMPv1 which then requires the provider to mandate its use across all 860 infrastructure devices for operational simplicity. SNMPv2 is 861 primarily deployed since it is easier to set up than v3. 863 2.4. Data Path 865 This section refers to how traffic is handled which traverses the 866 network infrastructure device. The primary goal of ISPs is to 867 forward customer traffic. However, due to the large amount of 868 malicious traffic that can cause DoS attacks and render the network 869 unavailable, specific measures are sometimes deployed to ensure the 870 availability to forward legitimate customer traffic. 872 2.4.1. Threats / Attacks 874 Any data traffic can potentially be attack traffic and the challenge 875 is to detect and potentially stop forwarding any of the malicious 876 traffic. The deliberately sourced attack traffic can consist of 877 packets with spoofed source and/or destination addresses or any other 878 malformed packet which mangle any portion of a header field to cause 879 protocol-related security issues (such as resetting connections, 880 causing unwelcome ICPM redirects, creating unwelcome IP options or 881 packet fragmentations). 883 2.4.2. Security Practices 885 Filtering and rate limiting are the primary mechanism to provide risk 886 mitigation of malicious traffic rendering the ISP services 887 unavailable. However, filtering and rate limiting of data path 888 traffic is deployed in a variety of ways depending on how automated 889 the process is and what the capabilities and performance limitations 890 of existing deployed hardware are. 892 The ISPs which do not have performance issues with their equipment 893 follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress 894 filtering. BCP38 recommends filtering ingress packets with obviously 895 spoofed and/or 'reserved' source addresses to limit the effects of 896 denial of service attacks while BCP84 extends the recommendation for 897 multi-homed environments. Null routes and black-hole triggered 898 routing are used to deter any detected malicious traffic streams. 899 These techniques are described in more detail in section 2.9 below. 901 Most ISPs consider layer 4 filtering useful but it is only 902 implemented if performance limitations allow for it. Layer 4 903 filtering is typically only when no other option exists since it does 904 pose a large administrative overhead and ISPs are very much opposed 905 to acting as the Internet firewall. Netflow is used for tracking 906 traffic flows but there is some concern whether sampling is good 907 enough to detect malicious behavior. 909 Unicast RPF is not consistently implemented. Some ISPs are in 910 process of doing so while other ISPs think that the perceived benefit 911 of knowing that spoofed traffic comes from legitimate addresses are 912 not worth the operational complexity. Some providers have a policy 913 of implementing uRPF at link speeds of DS3 and below. 915 2.4.3. Security Services 917 o User Authentication - Not applicable 919 o User Authorization - Not applicable 921 o Data Origin Authentication - When IP address filtering per BCP38 922 and uRPF are deployed at network edges it can ensure that any 923 spoofed traffic comes from at least a legitimate IP address and 924 can be tracked. 926 o Access Control - IP address filtering and layer 4 filtering is 927 used to deny forbidden protocols and limit traffic destined for 928 infrastructure device itself. 930 o Data Integrity - Not applicable 932 o Data Confidentiality - Not applicable 934 o Auditing / Logging - Filtering exceptions are logged for potential 935 attack traffic. 937 o DoS Mitigation - Black-hole triggered filtering and rate-limiting 938 are used to limit the risk of DoS attacks. 940 2.4.4. Additional Considerations 942 For layer 2 devices, MAC address filtering and authentication is not 943 used. This is due to the problems it can cause when troubleshooting 944 networking issues. Port security becomes unmanageable at a large 945 scale where 1000s of switches are deployed. 947 Rate limiting is used by some ISPs although other ISPs believe it is 948 not really useful since attackers are not well behaved and it doesn't 949 provide any operational benefit over the complexity. Some ISPs feel 950 that rate limiting can also make an attacker's job easier by 951 requiring the attacker to send less traffic to starve legitimate 952 traffic that is part of a rate limiting scheme. Rate limiting may be 953 improved by developing flow-based rate-limiting capabilities with 954 filtering hooks. This would improve the performance as well as the 955 granularity over current capabilities. 957 Lack of consistency regarding the ability to filter, especially with 958 respect to performance issues cause some ISPs to not implement BCP38 959 guidelines for ingress filtering. One such example is at edge boxes 960 where you have up to 1000 T1's connecting into a router with an OC-12 961 uplink. Some deployed devices experience a large performance impact 962 with filtering which is unacceptable for passing customer traffic 963 through. Where performance is not an issue, the ISPs make a tradeoff 964 between management versus risk. 966 2.5. Routing Control Plane 968 The routing control plane deals with all the traffic which is part of 969 establishing and maintaining routing protocol information. 971 2.5.1. Threats / Attacks 973 Attacks on the routing control plane can be both from passive or 974 active sources. Passive attacks are possible if someone has the 975 capability to intercept data between the communicating routing peers. 976 This can be accomplished if a single routing peer is somehow 977 compromised and can act as a network sniffer or if it is possible to 978 insert a new device which acts as a network sniffer. 980 Active attacks are possible for both on-path and off-path scenarios. 981 For on-path active attacks, the situation is the same as for a 982 passive attack, where either a device has to already be compromised 983 or a device can be inserted into the path. This may lead to an 984 attacker impersonating a legitimate routing peer and exchanging 985 routing information. Unintentional active attacks are more common 986 due to configuration errors, which cause legitimate routing peers to 987 feed invalid routing information to other neighboring peers. 989 For off-path active attacks, the attacks are generally limited to 990 message insertion or modification which can divert traffic to 991 illegitimate destinations and cause traffic to never reach its 992 intended destination. 994 2.5.2. Confidentiality Violations 996 Confidentiality violations can occur when a miscreant intercepts any 997 of the routing update traffic. This is becoming more of a concern 998 because many ISPs are classifying addressing schemes and network 999 topologies as private and proprietary information. It is also a 1000 concern because the routing protocol packets contain information that 1001 may show ways in which routing sessions could be spoofed or hijacked. 1002 This in turn could lead into a man-in-the-middle attack where the 1003 miscreants can insert themselves into the traffic path or divert the 1004 traffic path and violate the confidentiality of user data. 1006 2.5.3. Offline Cryptographic Attacks 1008 If any cryptographic mechanism was used to provide for data integrity 1009 and confidentiality, an offline cryptographic attack could 1010 potentially compromise the data. The traffic would need to be 1011 captured either by eavesdropping on the network or by being able to 1012 divert traffic to a malicious user. Note that by using 1013 cryptographically protected routing information, the latter would 1014 require the cryptographic key to already be compromised anyway so 1015 this attack is only feasible if a device was able eavesdrop and 1016 capture the cryptographically protected routing information. 1018 2.5.4. Replay Attacks 1020 For a replay attack to be successful, the routing control plane 1021 traffic would need to first be captured either on-path or diverted to 1022 an attacker to later be replayed to the intended recipient. 1024 2.5.5. Message Insertion/Deletion/Modification 1026 Routing control plane traffic can be manipulated by someone in 1027 control of intermediate hosts. In addition, traffic can be injected 1028 by forging IP addresses, where a remote router sends out packets 1029 which appear to come from another, trusted router. If enough traffic 1030 is injected to be processed by limited memory routers it can cause a 1031 DoS attack. 1033 2.5.6. Man-In-The-Middle 1035 A man-in-the-middle attack attacks the identity of a communicating 1036 peer rather than the data stream itself. The attacker intercepts 1037 traffic that is sent from one routing peer to the other and 1038 communicates on behalf of one of the peers. This can lead to 1039 diversion of the user traffic to either an unauthorized receiving 1040 party or cause legitimate traffic to never reach its intended 1041 destination. 1043 2.5.7. Security Practices 1045 Securing the routing control plane takes many features which are 1046 generally deployed as a system. MD5 authentication is used by some 1047 ISPs to validate the sending peer and to ensure that the data in 1048 transit has not been altered. Some ISPs only deploy MD5 1049 authentication at customer's request. Additional sanity checks to 1050 ensure with reasonable certainty that the received routing update was 1051 originated by a valid routing peer include route filters and the 1052 Generalized TTL Security Mechanism (GTSM) feature [RFC3682] 1053 (sometimes also referred to as the TTL-Hack). Note that validating 1054 whether a legitimate peer has the authority to send the contents of 1055 the routing update is a difficult problem that needs yet to be 1056 resolved. 1058 In the case of BGP routing, a variety of policies are deployed to 1059 limit the propagation of invalid routing information. These include: 1060 incoming and outgoing prefix filters for BGP customers, incoming and 1061 outgoing prefix filters for peers and upstream neighbors, incoming 1062 AS-PATH filter for BGP customers, outgoing AS-PATH filter towards 1063 peers and upstream neighbors, route dampening and rejecting selected 1064 attributes and communities. Consistency between these policies 1065 varies greatly although there is a trend to start depending on AS- 1066 PATH filters because they are much more manageable than the large 1067 numbers of prefix filters that would need to be maintained. Many 1068 ISPs also do not propagate interface IP addresses to further reduce 1069 attack vectors on routers and connected customers. 1071 2.5.8. Security Services 1073 o User Authentication - Not applicable 1075 o User Authorization - Not applicable 1077 o Data Origin Authentication - By using MD5 authentication and/or 1078 the TTL-hack a routing peer can be reasonably certain that traffic 1079 originated from a valid peer. 1081 o Access Control - Route filters, AS-PATH filters and prefix limits 1082 are used to control access to specific parts of the network. 1084 o Data Integrity - By using MD5 authentication a peer can be 1085 reasonably certain that the data has not been modified in transit 1086 but there is no mechanism to prove the validity of the routing 1087 information itself. 1089 o Data Confidentiality - Not implemented 1091 o Auditing / Logging - Filter exceptions are logged. 1093 o DoS Mitigation - Many DoS attacks are mitigated using a 1094 combination of techniques including: MD5 authentication, the GTSM 1095 feature, filtering routing advertisements to bogons and filtering 1096 routing advertisements to one's own network. 1098 2.5.9. Additional Considerations 1100 So far the primary concern to secure the routing control plane has 1101 been to validate the sending peer and to ensure that the data in 1102 transit has not been altered. Although MD5 routing protocol 1103 extensions have been implemented which can provide both services, 1104 they are not consistently deployed amongst ISPs. Two major 1105 deployment concerns have been implementation issues where both 1106 software bugs and the lack of graceful re-keying options have caused 1107 significant network down times. Also, some ISPs express concern that 1108 deploying MD5 authentication will itself be a worse DoS attack victim 1109 and prefer to use a combination of other risk mitigation mechanisms 1110 such as GTSM and route filters. 1112 Route filters are used to limit what routes are believed from a valid 1113 peer. Packet filters are used to limit which systems can appear as a 1114 valid peer. Due to the operational constraints of maintaining large 1115 prefix filter lists, many ISPs are starting to depend on BGP AS-PATH 1116 filters to/from their peers and upstream neighbors. Additionally, 1117 some large ISPs require that routes be registered in an Internet 1118 Routing Registry [IRR] which can then be part of the RADB - a public 1119 registry of routing information for networks in the Internet that can 1120 be used to generate filter lists. Some ISPs, especially in europe, 1121 require registered routes before agreeing to become an eBGP peer with 1122 someone. 1124 IPsec is not deployed since the operational management aspects of 1125 ensuring interoperability and reliable configurations is too complex 1126 and time consuming to be operationally viable. There is also limited 1127 concern to the confidentiality of the routing information. The 1128 integrity and validity of the updates are of much greater concern. 1130 There is concern for manual or automated actions which introduce new 1131 routes and can affect the entire routing domain. 1133 2.6. Software Upgrades and Configuration Integrity / Validation 1135 Software upgrades and configuration changes are usually performed as 1136 part of either in-band or OOB management functions. However, there 1137 are additional considerations to be taken into account which are 1138 enumerated in this section. 1140 2.6.1. Threats / Attacks 1142 Attacks performed on system software and configurations can be both 1143 from passive or active sources. Passive attacks are possible if 1144 someone has the capability to intercept data between the network 1145 infrastructure device and the system which is downloading or 1146 uploading the software or configuration information. This can be 1147 accomplished if a single infrastructure device is somehow compromised 1148 and can act as a network sniffer or if it is possible to insert a new 1149 device which acts as a network sniffer. 1151 Active attacks are possible for both on-path and off-path scenarios. 1152 For on-path active attacks, the situation is the same as for a 1153 passive attack, where either a device has to already be compromised 1154 or a device can be inserted into the path. For off-path active 1155 attacks, the attacks are generally limited to message insertion or 1156 modification where the attacker may wish to load illegal software or 1157 configuration files to an infrastructure device. 1159 2.6.2. Confidentiality Violations 1161 Confidentiality violations can occur when a miscreant intercepts any 1162 of the software image or configuration information. The software 1163 image may give an indication of exploits which the device is 1164 vulnerable to while the configuration information can inadvertently 1165 lead attackers to identify critical infrastructure IP addresses and 1166 passwords. 1168 2.6.3. Offline Cryptographic Attacks 1170 If any cryptographic mechanism was used to provide for data integrity 1171 and confidentiality, an offline cryptographic attack could 1172 potentially compromise the data. The traffic would need to be 1173 captured either by eavesdropping on the network or by being able to 1174 divert traffic to a malicious user. 1176 2.6.4. Replay Attacks 1178 For a replay attack to be successful, the software image or 1179 configuration file would need to first be captured either on-path or 1180 diverted to an attacker to later be replayed to the intended 1181 recipient. 1183 2.6.5. Message Insertion/Deletion/Modification 1185 Software images and configuration files can be manipulated by someone 1186 in control of intermediate hosts. By forging an IP address and 1187 impersonating a valid host which can download software images or 1188 configuration files, invalid files can be downloaded to an 1189 infrastructure device. An invalid software image or configuration 1190 file can cause a device to hang and become inoperable. Spoofed 1191 configuration files can be hard to detect, especially when the only 1192 added command is to allow a miscreant access to that device by 1193 entering a filter allowing a specific host access and configuring a 1194 local username/password database entry for authentication to that 1195 device. 1197 2.6.6. Man-In-The-Middle 1199 A man-in-the-middle attack attacks the identity of a communicating 1200 peer rather than the data stream itself. The attacker intercepts 1201 traffic that is sent between the infrastructure device and the host 1202 used to upload/download the system image or configuration file. He/ 1203 she can then act on behalf of one or both of these systems. 1205 If an attacker obtained a copy of the software image being deployed, 1206 he could potentially exploit a known vulnerability and gain access to 1207 the system. From a captured configuration file, he could obtain 1208 confidential network topology information or even more damaging 1209 information if any of the passwords in the configuration file were 1210 not encrypted. 1212 2.6.7. Security Practices 1214 Images and configurations are stored on specific hosts which have 1215 limited access. All access and activity relating to these hosts are 1216 authenticated and logged via AAA services. When uploaded/downloading 1217 any system software or configuration files, either TFTP, FTP or SCP 1218 can be used. Where possible, SCP is used to secure the data transfer 1219 and FTP is generally never used. All SCP access is username/password 1220 authenticated but since this requires an interactive shell, most ISPs 1221 will use shared key authentication to avoid the interactive shell. 1222 While TFTP access does not have any security measures, it is still 1223 widely used especially in OOB management scenarios. Some ISPs 1224 implement IP-based restriction on the TFTP server while some custom 1225 written TFTP servers will support MAC-based authentication. The MAC- 1226 based authentication is more common when using TFTP to bootstrap 1227 routers remotely using TFTP. 1229 In most environments scripts are used for maintaining the images and 1230 configurations of a large number of routers. To ensure the integrity 1231 of the configurations, every hour the configuration files are polled 1232 and compared to the previously polled version to find discrepancies. 1233 In at least one environment these tools are Kerberized to take 1234 advantage of automated authentication (not confidentiality). 1236 Filters are used to limit access to uploading/downloading 1237 configuration files and system images to specific IP addresses and 1238 protocols. 1240 The software images perform CRC-checks and the system binaries use 1241 the MD5 algorithm to validate integrity. Many ISPs expressed 1242 interest in having software image integrity validation based on the 1243 MD5 algorithm for enhanced security. 1245 In all configuration files, most passwords are stored in an 1246 obfuscated format. This includes passwords for user authentication, 1247 MD5 shared secrets, AAA server shared secrets, NTP shared secrets, 1248 etc. For older software which may not support this functionality, 1249 configuration files may contain some passwords in readable format. 1250 Most ISPs mitigate any risk of password compromise by either storing 1251 these configuration files without the password lines or by requiring 1252 authenticated and authorized access to the configuration files which 1253 are stored on protected OOB management devices. 1255 Automated security validation is performed on infrastructure devices 1256 using nmap and nessus to ensure valid configuration against many of 1257 the well-known attacks. 1259 2.6.8. Security Services 1261 o User Authentication - All users are authenticated before being 1262 able to download/upload any system images or configuration files. 1264 o User Authorization - All authenticated users are granted specific 1265 privileges to download or upload system images and/or 1266 configuration files. 1268 o Data Origin Authentication - Filters are used to limit access to 1269 uploading/downloading configuration files and system images to 1270 specific IP addresses. 1272 o Access Control - Filters are used to limit access to uploading/ 1273 downloading configuration files and system images to specific IP 1274 addresses and protocols. 1276 o Data Integrity - All systems use either a CRC-check or MD5 1277 authentication to ensure data integrity. 1279 o Data Confidentiality - If the SCP protocol is used then there is 1280 confidentiality of the downloaded/uploaded configuration files and 1281 system images. 1283 o Auditing / Logging - All access and activity relating to 1284 downloading/uploading system images and configuration files are 1285 logged via AAA services and filter exception rules. 1287 o DoS Mitigation - TBD 1289 2.6.9. Additional Considerations 1291 Where the MD5 algorithm is not used to perform data integrity 1292 checking of software images and configuration files, ISPs have 1293 expressed an interest in having this functionality. IPsec is 1294 considered too cumbersome and operationally difficult to use for data 1295 integrity and confidentiality. 1297 2.7. Logging Considerations 1299 Although logging is part of all the previous sections, it is 1300 important enough to be covered as a separate item. The main issues 1301 revolve around what gets logged, how long are logs kept and what 1302 mechanisms are used to secure the logged information while it is in 1303 transit and while it is stored. 1305 2.7.1. Threats / Attacks 1307 Attacks on the logged data can be both from passive or active 1308 sources. Passive attacks are possible if someone has the capability 1309 to intercept data between the recipient logging server and the device 1310 the logged data originated from. This can be accomplished if a 1311 single infrastructure device is somehow compromised and can act as a 1312 network sniffer or if it is possible to insert a new device which 1313 acts as a network sniffer. 1315 Active attacks are possible for both on-path and off-path scenarios. 1316 For on-path active attacks, the situation is the same as for a 1317 passive attack, where either a device has to already be compromised 1318 or a device can be inserted into the path. For off-path active 1319 attacks, the attacks are generally limited to message insertion or 1320 modification which can alter the logged data to keep any compromise 1321 from being detected or to destroy any evidence which could be used 1322 for criminal prosecution. 1324 2.7.1.1. Confidentiality Violations 1326 Confidentiality violations can occur when a miscreant intercepts any 1327 of the logging data which is in transit on the network. This could 1328 lead to privacy violations if some of the logged data has not been 1329 sanitized to disallow any data that could be a violation of privacy 1330 to be included in the logged data. 1332 2.7.1.2. Offline Cryptographic Attacks 1334 If any cryptographic mechanism was used to provide for data integrity 1335 and confidentiality, an offline cryptographic attack could 1336 potentially compromise the data. The traffic would need to be 1337 captured either by eavesdropping on the network or by being able to 1338 divert traffic to a malicious user. 1340 2.7.1.3. Replay Attacks 1342 For a replay attack to be successful, the logging data would need to 1343 first be captured either on-path or diverted to an attacker and later 1344 replayed to the recipient. [is reply handled by syslog protocol?] 1346 2.7.1.4. Message Insertion/Deletion/Modification 1348 Logging data could be injected, deleted or modified by someone in 1349 control of intermediate hosts. Logging data can also be injected by 1350 forging packets from either legitimate or illegitimate IP addresses. 1352 2.7.1.5. Man-In-The-Middle 1354 A man-in-the-middle attack attacks the identity of a communicating 1355 peer rather than the data stream itself. The attacker intercepts 1356 traffic that is sent between the infrastructure device and the 1357 logging server or traffic sent between the logging server and the 1358 database which is used to archive the logged data. Any unauthorized 1359 access to logging information could lead to knowledge of private and 1360 proprietary network topology information which could be used to 1361 compromise portions of the network. An additional concern is having 1362 access to logging information which could be deleted or modified so 1363 as to cover any traces of a security breach. 1365 2.7.2. Security Practices 1367 Logging is mostly performed on an exception auditing basis when it 1368 comes to filtering (i.e. traffic which is NOT allowed is logged). 1369 This is to assure that the logging servers are not overwhelmed with 1370 data which would render most logs unusable. Typically the data 1371 logged will contain the source and destination IP addresses and layer 1372 4 port numbers as well as a timestamp. The syslog protocol is used 1373 to transfer the logged data between the infrastructure device to the 1374 syslog server. Many ISPs use the OOB management network to transfer 1375 syslog data since there is virtually no security performed between 1376 the syslog server and the device. All ISPs have multiple syslog 1377 servers - some ISPs choose to use separate syslog servers for varying 1378 infrastructure devices (i.e. one syslog server for backbone routers, 1379 one syslog server for customer edge routers, etc.) 1381 The timestamp is derived from NTP which is generally configured as a 1382 flat hierarchy at stratum1 and stratum2 to have less configuration 1383 and less maintenance. Each router is configured with one stratum1 1384 peer both locally and remotely. 1386 In addition to logging filtering exceptions, the following is 1387 typically logged: Routing protocol state changes, all device access 1388 (regardless of authentication success or failure), all commands 1389 issued to a device, all configuration changes and all router events 1390 (boot-up/flaps). 1392 The main function of any of these log messages is to see what the 1393 device is doing as well as to try and ascertain what certain 1394 malicious attackers are trying to do. Some ISPs put in passive 1395 devices to see routing updates and withdrawals and not rely solely on 1396 the device for log files. This provides a backup mechanism to see 1397 what is going on in the network in the event that a device may 1398 'forget' to do syslog if the CPU is busy. 1400 The logs from the various syslog server devices are generally 1401 transferred into databases at a set interval which can be anywhere 1402 from every 10 minutes to every hour. One ISP uses Rsync to push the 1403 data into a database and then the information is sorted manually by 1404 someone SSH'ing to that database. 1406 2.7.3. Security Services 1408 o User Authentication - Not applicable 1410 o User Authorization - Not applicable 1412 o Data Origin Authentication - Not implemented 1414 o Access Control - Filtering on logging host and server IP address 1415 to ensure that syslog information only goes to specific syslog 1416 hosts. 1418 o Data Integrity - Not implemented 1420 o Data Confidentiality - Not implemented 1422 o Auditing / Logging - This entire section deals with logging. 1424 o DoS Mitigation - An OOB management system is used and sometimes 1425 different syslog servers are used for logging information from 1426 varying equipment. Exception logging tries to keep information to 1427 a minimum. 1429 2.7.4. Additional Considerations 1431 There is no security with syslog and ISPs are fully cognizant of 1432 this. IPsec is considered too operationally expensive and cumbersome 1433 to deploy. Syslog-ng and stunnel are being looked at for providing 1434 better authenticated and integrity protected solutions. Mechanisms 1435 to prevent unauthorized personnel from tampering with logs is 1436 constrained to auditing who has access to the logging servers and 1437 files. 1439 ISPs expressed requirements for more than just UDP syslog. 1440 Additionally, they would like more granular and flexible facilities 1441 and priorities, i.e. specific logs to specific servers. Also, a 1442 common format for reporting standard events so that they don't have 1443 to modify parsers after each upgrade of vendor device or software. 1445 2.8. Filtering Considerations 1447 Although filtering has been covered under many of the previous 1448 sections, this section will provide some more insights to the 1449 filtering considerations that are currently being taken into account. 1450 Filtering is now being categorized into three specific areas: data 1451 plane, management plane and routing control plane. 1453 2.8.1. Data Plane Filtering 1455 Data plane filters control the traffic that traverses through a 1456 device and affect transit traffic. Most ISPs deploy these kinds of 1457 filters at the customer facing edge devices to mitigate spoofing 1458 attacks using BCP38 and BCP84 guidelines. 1460 2.8.2. Management Plane Filtering 1462 Management filters control the traffic to and from a device. All of 1463 the protocols which are used for device management fall under this 1464 category and includes SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP, 1465 SCP and Syslog. This type of traffic is often filtered per interface 1466 and is based on any combination of protocol, source and destination 1467 IP address and source and destination port number. Some devices 1468 support functionality to apply management filters to the device 1469 rather than to the specific interfaces (e.g. receive ACL or loopback 1470 interface ACL) which is gaining wider acceptance. Note that logging 1471 the filtering rules can today place a burden on many systems and more 1472 granularity is often required to more specifically log the required 1473 exceptions. 1475 Any services that are not specifically used are turned off. 1477 IPv6 networks require the use of specific ICMP messages for proper 1478 protocol operation. Therefore, ICMP cannot be completely filtered to 1479 and from a device. Instead, granular ICMPv6 filtering is always 1480 deployed to allow for specific ICMPv6 types to be sourced or destined 1481 to a network device. A good guideline for IPv6 filtering is in the 1482 draft work in progress on Best Current Practices for Filtering ICMPv6 1483 Messages in Firewalls [I-D.ietf-v6ops-icmpv6-filtering-bcp]. 1485 2.8.3. Routing Control Plane Filtering 1487 Routing filters are used to control the flow of routing information. 1488 In IPv6 networks, some providers are liberal in accepting /48s due to 1489 the still unresolved multihoming issues. Any announcement received 1490 that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing 1491 is filtered out of eBGP. Note that this is for non-customer traffic. 1492 Most ISPs will accept any agreed upon prefix length from its 1493 customer(s). 1495 2.9. Denial of Service Tracking / Tracing 1497 Denial of Service attacks are an ever increasing problem and require 1498 vast amounts of resources to combat effectively. Some large ISPs do 1499 not concern themselves with attack streams that are less than 1G in 1500 bandwidth - this is on the larger pipes where 1G is essentially less 1501 than 5% of offered load. This is largely due to the large amounts of 1502 DDoS traffic which continually requires investigation and mitigation. 1503 At last count the number of hosts making up large distributed DoS 1504 botnets exceeded 1 million hosts. 1506 New techniques are continually evolving to automate the process of 1507 detecting DoS sources and mitigating any adverse effects as quickly 1508 as possible. At this time, ISPs are using a variety of mitigation 1509 techniques including: sink hole routing, black-hole triggered 1510 routing, uRPF and rate limiting. Each of these techniques will be 1511 detailed below. 1513 2.9.1. Sink Hole Routing 1515 Sink hole routing refers to injecting a more specific route for any 1516 known attack traffic which will ensure that the malicious traffic is 1517 redirected to a valid device or specific system where it can be 1518 analyzed. 1520 2.9.2. Black-Hole Triggered Routing 1522 Black-hole triggered routing (also referred to as Remote Triggered 1523 Black Hole Filtering) is a technique where the BGP routing protocol 1524 is used to propagate routes which in turn redirects attack traffic to 1525 the null interface where it is effectively dropped. This technique 1526 is often used in large routing infrastructures since BGP can 1527 propagate the information in a fast effective manner as opposed to 1528 using any packet-based filtering techniques on hundreds or thousands 1529 of routers. [refer to the following NANOG presentation for a more 1530 complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf] 1532 2.9.3. Unicast Reverse Path Forwarding 1534 Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating 1535 whether an incoming packet has a legitimate source address or not. 1536 It has two modes: strict mode and loose mode. In strict mode, uRPF 1537 checks whether the incoming packet has a source address that matches 1538 a prefix in the routing table, and whether the interface expects to 1539 receive a packet with this source address prefix. If the incoming 1540 packet fails the unicast RPF check, the packet is not accepted on the 1541 incoming interface. Loose mode uRPF is not as specific and the 1542 incoming packet is accepted if there is any route in the routing 1543 table for the source address. 1545 uRPF is not used on interfaces that are likely to have routing 1546 asymmetry, meaning multiple routes to the source of a packet. 1547 Usually for ISPs, uRPF is placed at the customer edge of a network. 1549 2.9.4. Rate Limiting 1551 Rate limiting refers to allocating a specific amount of bandwidth or 1552 packets per second to specific traffic types. This technique is 1553 widely used to mitigate well-known protocol attacks such as the TCP- 1554 SYN attack where a large number of resources get allocated for 1555 spoofed TCP traffic. Although this technique does not stop an 1556 attack, it can sometimes lessen the damage and impact on a specific 1557 service. However, it can also make the impact of a DDoS attack much 1558 worse if the rate limiting is impacting (i.e. discarding) more 1559 legitimate traffic. 1561 3. Security Considerations 1563 This entire document deals with current security practices in large 1564 ISP environments. It lists specific practices used in today's 1565 environments and as such does not in itself pose any security risk. 1567 4. References 1569 4.1. Normative References 1571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1572 Requirement Levels", BCP 14, RFC 2119, March 1997. 1574 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1575 Defeating Denial of Service Attacks which employ IP Source 1576 Address Spoofing", BCP 38, RFC 2827, May 2000. 1578 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 1579 May 2000. 1581 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1582 Text on Security Considerations", BCP 72, RFC 3552, 1583 July 2003. 1585 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 1586 Security Mechanism (GTSM)", RFC 3682, February 2004. 1588 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1589 Networks", BCP 84, RFC 3704, March 2004. 1591 4.2. Informational References 1593 [I-D.ietf-v6ops-icmpv6-filtering-bcp] 1594 Davies, E. and J. Mohacsi, "Best Current Practice for 1595 Filtering ICMPv6 Messages in Firewalls", 1596 draft-ietf-v6ops-icmpv6-filtering-bcp-01 (work in 1597 progress), March 2006. 1599 [I-D.lewis-infrastructure-security] 1600 Lewis, D., "Service Provider Infrastructure Security", 1601 draft-lewis-infrastructure-security-00 (work in progress), 1602 June 2006. 1604 [I-D.savola-bcp84-urpf-experiences] 1605 Savola, P., "Experiences from Using Unicast RPF", 1606 draft-savola-bcp84-urpf-experiences-01 (work in progress), 1607 June 2006. 1609 [I-D.savola-rtgwg-backbone-attacks] 1610 Savola, P., "Backbone Infrastructure Attacks and 1611 Protections", draft-savola-rtgwg-backbone-attacks-01 (work 1612 in progress), June 2006. 1614 Appendix A. Acknowledgments 1616 The editor gratefully acknowledges the contributions of: George 1617 Jones, who has been instrumental in providing guidance and direction 1618 for this document and the insighful comments from Ross Callon, Ron 1619 Bonica, Gaurab Upadhaya, Warren Kumari and the numerous ISP operators 1620 who supplied the information which is depicted in this document. 1622 Appendix B. Protocol Specific Attacks 1624 This section will list many of the traditional protocol based attacks 1625 which have been observed over the years to cause malformed packets 1626 and/or exploit protocol deficiencies. Note that they all exploit 1627 vulnerabilities in the actual protocol itself and often, additional 1628 authentication and auditing mechanisms are now used to detect and 1629 mitigate the impact of these attacks. The list is not exhaustive but 1630 is a fraction of the representation of what types of attacks are 1631 possible for varying protocols. 1633 B.1. Layer 2 Attacks 1635 o ARP Flooding 1637 B.2. IPv4 Attacks 1639 o IP Stream Option 1641 o IP Address Spoofing 1643 o IP Source Route Option 1645 o IP Short header 1647 o IP Malformed Packet 1649 o IP Bad Option 1651 o IP Address Session Limit 1653 o Fragments - too many 1655 o Fragments - large offset 1657 o Fragments - same offset 1659 o Fragments - reassembly with different offsets (TearDrop Attac) 1661 o Fragments - reassembly off by one IP header (Nestea Attack) 1663 o Fragment - flooding only initial fragment (Rose Attack) 1665 o IGMP oversized packet 1666 o ICMP Source Quench 1668 o ICMP Mask Request 1670 o ICMP Large Packet (> 1472) 1672 o ICMP Oversized packet (>65536) 1674 o ICMP Flood 1676 o ICMP Broadcast w/ Spoofed Source (Smurf Attack) 1678 o ICMP Error Packet Flood 1680 o ICMP Spoofed Unreachable 1682 o TCP Packet without Flag 1684 o TCP Oversized Packet 1686 o TCP FIN bit with no ACK bit 1688 o TCP Packet with URG/OOB flag (Nuke Attack) 1690 o SYN Fragments 1692 o SYN Flood 1694 o SYN with IP Spoofing (Land Attack) 1696 o SYN and FIN bits set 1698 o TCP port scan attack 1700 o UDP spoofed broadcast echo (Fraggle Attack) 1702 o UDP attack on diagnostic ports (Pepsi Attack) 1704 B.3. IPv6 Attacks 1706 Any of the above-mentioned IPv4 attacks could be used in IPv6 1707 networks with the exception of any fragmentation and broadcast 1708 traffic, which operate differently in IPv6. Note that all of these 1709 attacks are based on either spoofing or misusing any part of the 1710 protocol field(s). 1712 Today, IPv6 enabled hosts are starting to be used to create IPv6 1713 tunnels which can effectively hide botnet and other malicious traffic 1714 if firewalls and network flow collection tools are not capable of 1715 detecting this traffic. The security measures used for protecting 1716 IPv6 infrastructures should be the same as in IPv4 networks but with 1717 additional considerations for IPv6 network operations which may be 1718 different from IPv4. 1720 Author's Address 1722 Merike Kaeo 1723 Double Shot Security, Inc. 1724 3518 Fremont Avenue North #363 1725 Seattle, WA 98103 1726 U.S.A. 1728 Phone: +1 310 866 0165 1729 Email: merike@doubleshotsecurity.com 1731 Intellectual Property Statement 1733 The IETF takes no position regarding the validity or scope of any 1734 Intellectual Property Rights or other rights that might be claimed to 1735 pertain to the implementation or use of the technology described in 1736 this document or the extent to which any license under such rights 1737 might or might not be available; nor does it represent that it has 1738 made any independent effort to identify any such rights. Information 1739 on the procedures with respect to rights in RFC documents can be 1740 found in BCP 78 and BCP 79. 1742 Copies of IPR disclosures made to the IETF Secretariat and any 1743 assurances of licenses to be made available, or the result of an 1744 attempt made to obtain a general license or permission for the use of 1745 such proprietary rights by implementers or users of this 1746 specification can be obtained from the IETF on-line IPR repository at 1747 http://www.ietf.org/ipr. 1749 The IETF invites any interested party to bring to its attention any 1750 copyrights, patents or patent applications, or other proprietary 1751 rights that may cover technology that may be required to implement 1752 this standard. Please address the information to the IETF at 1753 ietf-ipr@ietf.org. 1755 Disclaimer of Validity 1757 This document and the information contained herein are provided on an 1758 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1759 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1760 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1761 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1762 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1763 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1765 Copyright Statement 1767 Copyright (C) The Internet Society (2006). This document is subject 1768 to the rights, licenses and restrictions contained in BCP 78, and 1769 except as set forth therein, the authors retain all their rights. 1771 Acknowledgment 1773 Funding for the RFC Editor function is currently provided by the 1774 Internet Society.